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?

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/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

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.

What about FFIs? Does the ISO standard say anything about this? Is interfacing with Rust packages easier when the implementation is also in Rust?

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.

I ask this as a completely outsider to Prolog who has found some of the design choices in SWI-Prolog to be very arbitrary while I was trying to learn it. Some predicates were rather unsafe/error prone/not pure and didn't sit quite right with me.

Is that a result of the Standard and will Scryer follow those footsteps or are we going to see something closer to Mercury?

I really enjoy your channel and indirectly heard a lot of positive things about Scryer, so of course I'm super interested and would prefer if they don't get too stuck on trying to meet the "status quo". The "status quo" has a lot of room for improvement.

Thank you a lot for your kind words, and for your interest!

The Prolog ISO standard currently prescribes less than 200 predicates (less than 150 if we discount variants that only differ in the number of arguments), here is a nice overview of all predicates that a conforming system must provide:

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/prologue

The ISO standard also allows conforming extensions that any Prolog system may add as implementation specific features. Notably, we have:

    5 Compliance

    5.1 Prolog processor

    A conforming Prolog processor shall:

      a) Correctly prepare for execution Prolog text which
      conforms to:

        1) the requirements of this part of ISO/IEC 13211,
        and

        2) the implementation defined and implementation
        specific features of the Prolog processor,

    etc.

The general trend and intention of modern Prolog systems is clear: A major goal is to add, as conforming extensions, declarative constructs that facilitate more general and readable Prolog code that is also amenable to logical reasoning and automated debugging. However, the extensions that SWI-Prolog provides are not conforming extensions, because they change the meaning of existing, conforming Prolog code in a way that deviates from the ISO standard. The following document provides a good overview of resulting consequences:

https://www.complang.tuwien.ac.at/ulrich/iso-prolog/SWI7_and...

Note that it is possible to add infix dot syntax, efficient strings, constraints etc. all while conforming to ISO Prolog! This is the route taken by GNU Prolog, Scryer Prolog, SICStus Prolog, Tau Prolog, Trealla Prolog etc.

How does SWI compare in this regard. For new work using Prolog is recommended to use this over SWI?

The point of using Prolog for logic programming is that's an ISO standard in the first place. So unless you need SWI's (or SICSTUS' or yap's) special libs and features, I'd stick to ISO Prolog and choose your Prolog system late or deploy on multiple ones. Depending on your project, there might be other choices available, such as mini-Kanren or other LP/CLP system for embedding into a host language, Mercury or GNU Prolog for static compilation and linking, etc.

Is ISO standardisation a big deal with Prolog? I remember that SQL is also standardized, but in practice one works with the dialect ones DB vendor is offering.

ISO Prolog and SQL matter for me a lot: I sometimes write both, but overall not much. Sticking to the standard makes revisiting code years much easier and code can survive a few major version bumps of compiler/database without problems.

The situation isn't comparable with SQL. Pure Prolog code tends to be pretty portable, with the major non-portable stuff being CLP apps (not Prolog) and SWI-specific code/libs.