Comment by triska | Hacker News Reader

Comment by triska | Hacker News Reader

Parent Full thread

As a contributor to Scryer Prolog (I designed the logo!), I find this project to be one of the most exciting current developments in the logic programming community, and one of the most promising new Prolog systems in many years.

Notably, Scryer Prolog is currently the only free Prolog system that aims for full conformance to the Prolog ISO standard, supports constraints such as dif/2, CLP(B) and CLP(ℤ), includes the most recent declarative features such as if_/3 and and the ..._si/1 family of predicates, provides support for sound unification and an alternative execution strategy called SLG resolution, and also implements a very efficient internal representation of lists of characters and partial strings, thus making it the first Prolog system in decades with the potential to efficiently support the use case Prolog was developed for: efficient and convenient text processing. On top of this, it is the first Prolog system ever implemented in Rust, making it especially exciting for fans of this language while also benefiting from many of its innovations.

Here are a few interesting applications of Scryer Prolog:

The precautionary package by David C. Norris, using Scryer Prolog for safety analysis of phase 1 dose-escalation trials in clinical oncology:

https://github.com/dcnorris/precautionary

A Prolog library to connect to PostgreSQL databases by Adrián Arroyo Calle:

https://github.com/aarroyoc/postgresql-prolog

The Retina chainer, targeting EYE Reasoning via Scryer and Trealla by Jos de Roo:

https://josd.github.io/retina/

Thank you Mark and everyone who contributed for all your work on Scryer Prolog, keep up the great work! Some of these innovations have already spread to other Prolog systems, such as Trealla and Tau Prolog, and I hope that Scryer serves as an inspiration for many more systems. Exciting times ahead!

Regarding the name of the project: "Scrying" is the practice of looking into a suitable medium in the hope of detecting significant messages or visions:

https://en.wikipedia.org/wiki/Scrying

What a fitting name for a Prolog system!

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.

Reply on news.ycombinator.com