3 ms·

Thanks for your contributions to popularizing Prolog. I have seen many of your videos. The language on the videos is simple, precise and the content mind blowin

Thanks for your contributions to popularizing Prolog. I have seen many of your videos. The language on the videos is simple, precise and the content mind blowing. A bit like Prolog :-) You mention you are a contributor to Scryer Prolog. I am curious about the choice of Rust as the implementation language. There are lots of advantages to using Rust but it does not lend itself easily to self referential data structures, linked lists, recursion (tail and non tail recursion) and other things that are found abundantly in Prolog. I'm wondering if Rust is the easiest language to implement Scryer Prolog in. I would have much preferred using something OCaml (or similar). You would get garbage collection and tail recursion "for free". What is your opinion on Rust as Scryer's implementation language?

triska 5y ago
Wow, thank you a lot! I am very glad you find this material useful! Scryer Prolog compiles Prolog code to abstract machine code, and executes that. Like SICStus Prolog, GNU Prolog etc., Scryer uses the Warren Abstract Machine (WAM) as the target architecture. Therefore, self referential data structures, linked lists, tail calls etc. are not directly mapped as such to Rust data structures and concepts, but occur in a sense only "indirectly" when Rust interprets the virtual machine instructions, where references to data structures appear as pointers to cells in the virtual machine. Similarly, tail calls correspond to certain abstract machine instructions that allow reuse of portions of the virtual local stack. Currently, Scryer uses a Rust enum to represent heap cells, here is the definition: https://github.com/mthom/scryer-prolog/blob/ca62e54652ace8374225e9f43f28aac508819255/src/machine/machine_indices.rs#L310 https://github.com/mthom/scryer-prolog/blob/ca62e54652ace837... A more compact representation will use tagged cells that point directly into memory, using for example the modular-bitfield crate: https://github.com/Robbepop/modular-bitfield https://github.com/Robbepop/modular-bitfield It is my hope that such an improved representation will soon become available in Scryer Prolog, it will likely speed up the system considerably. On the use of Rust: I contributed only a few hundred lines of Rust code to Scryer Prolog. My feeling when using Rust was that this is a suitable final form of the implementation: Rust seemed so suitable and natural to implement the low-level facilities of Scryer Prolog that I consider it unlikely that any other language will ever warrant a change in this basic layer of the implementation. It is this feeling that I strive for when using programming languages, and I get it also for example when using Emacs Lisp, PostScript and Prolog. OCaml and possibly other languages would definitely also be a good choice, and likely candidates that satisfy this specific criterion! Rust's package manager, the availability of ready-made crates and the easy compilation were also extremely helpful during development. It is my hope that Rust will be especially useful when adding support for multiple threads to Scryer Prolog.
- fspeech 5y ago
  What about FFIs? Does the ISO standard say anything about this? Is interfacing with Rust packages easier when the implementation is also in Rust?
  - mthom 5y ago
    The ISO standard does not yet say anything about FFIs. I've heard that SWI's FFI is hampered by its garbage collection somehow. Since I'm working on a GC for Scryer now, it's probably a good idea to consider FFI concurrently. "A beginning is such a delicate time." I remember reading that somewhere.

triska 5y ago

Wow, thank you a lot! I am very glad you find this material useful! Scryer Prolog compiles Prolog code to abstract machine code, and executes that. Like SICStus Prolog, GNU Prolog etc., Scryer uses the Warren Abstract Machine (WAM) as the target architecture. Therefore, self referential data structures, linked lists, tail calls etc. are not directly mapped as such to Rust data structures and concepts, but occur in a sense only "indirectly" when Rust interprets the virtual machine instructions, where references to data structures appear as pointers to cells in the virtual machine. Similarly, tail calls correspond to certain abstract machine instructions that allow reuse of portions of the virtual local stack. Currently, Scryer uses a Rust enum to represent heap cells, here is the definition: https://github.com/mthom/scryer-prolog/blob/ca62e54652ace8374225e9f43f28aac508819255/src/machine/machine_indices.rs#L310 https://github.com/mthom/scryer-prolog/blob/ca62e54652ace837... A more compact representation will use tagged cells that point directly into memory, using for example the modular-bitfield crate: https://github.com/Robbepop/modular-bitfield https://github.com/Robbepop/modular-bitfield It is my hope that such an improved representation will soon become available in Scryer Prolog, it will likely speed up the system considerably. On the use of Rust: I contributed only a few hundred lines of Rust code to Scryer Prolog. My feeling when using Rust was that this is a suitable final form of the implementation: Rust seemed so suitable and natural to implement the low-level facilities of Scryer Prolog that I consider it unlikely that any other language will ever warrant a change in this basic layer of the implementation. It is this feeling that I strive for when using programming languages, and I get it also for example when using Emacs Lisp, PostScript and Prolog. OCaml and possibly other languages would definitely also be a good choice, and likely candidates that satisfy this specific criterion! Rust's package manager, the availability of ready-made crates and the easy compilation were also extremely helpful during development. It is my hope that Rust will be especially useful when adding support for multiple threads to Scryer Prolog.

fspeech 5y ago
What about FFIs? Does the ISO standard say anything about this? Is interfacing with Rust packages easier when the implementation is also in Rust?
- mthom 5y ago
  The ISO standard does not yet say anything about FFIs. I've heard that SWI's FFI is hampered by its garbage collection somehow. Since I'm working on a GC for Scryer now, it's probably a good idea to consider FFI concurrently. "A beginning is such a delicate time." I remember reading that somewhere.