It would be nice to see a comparison to other Prolog implementations. Last time I used Prolog, I used SWI, which is BSDL and seemed to work. Why would I use this instead (and, conversely, why would I not use it)?
In terms of features and performance, SWI would win :) That is expected as IIRC SWI’s codebase comes from the late 80s while Scryer is much newer and hasn’t reached 1.0 yet. Also, SWI nowadays has a full-time person working on it.
However, there’s a point to be made about “being a Prolog”. SWI doesn’t comply with ISO Prolog and doesn’t want to. Some people even refer to SWI as Prolog-based rather than Prolog. This mostly happened in version 7 with the addition of “opaque” strings and dictionaries. Also, Scryer has had a big focus on finding the declarative, pure, monotonic abstractions to advance Prolog with the original philosophy. For example, Scryer rather than use an “opaque” type for strings, it uses a compact representation internally but externally it behaves as a list of characters (and you gain all the benefits of using lists in Prolog).
Scryer also borrows things from SICStus, the most important commercial implementation of Prolog, which is also the fastest one and with lots of features too. Some libraries are closer to the SICStus ones than to the SWI ones.
SWI’s deviations from ISO Prolog are mostly extensions and behaviors that are unlikely to offend most Prolog users. I’m think improper lists and strings-as-lists-of-integer-codepoints are more confusing to modern programmers than SWI’s behavior. I have heard this argument (that SWI isn’t ISO) on Reddit as well and I just don’t think it is very salient. SWI is the flagship open source Prolog. If someone doesn’t know which to use, it’s the one they should try.
ISO Prolog is also quite small and every Prolog implementation winds up bringing along a ton of extra functionality. You say so yourself: “finding abstractions to advance Prolog with the original philosophy” is of course adding new stuff to Scryer that isn’t ISO.
This sounds more negative than I intend to be. I think I’m just trying to say, throwing the “it isn’t ISO” at SWI is a little disingenuous when most programmers who are curious about Prolog are unlikely to need what is unavailable in SWI and unlikely to care deeply about portability to other implementations when SWI has so much more on offer.
That said I am getting interested in Scryer and I appreciate the work you’ve put into it. Having some competition in this area is a good thing, and GNU Prolog seems to be kind of in stasis.
I agree with a lot of your points. SWI is indeed the Prolog I used myself for learning. However, the string handling of Scryer was one of the reasons I started to contribute to Scryer. String processing in SWI requires new predicates written from scratch to handling them or lots of conversions. This might seem a minor annoyance but when you start using DCGs, it becomes more tedious. BTW Scryer doesn’t have “strings-as-lists-of-integer-codepoints” either by default.
Adding things to Prolog is totally fine and necessary in my opinion but it should respect the backward compatibility of already written standard code.
GNU Prolog is a very cool project. It is the fastest open-source Prolog. That’s because it actually compiles down to native code. We want to do something like that in Scryer using Cranelift but it’s a big task!
For example, Scryer rather than use an “opaque” type for strings, it uses a compact representation internally but externally it behaves as a list of characters (and you gain all the benefits of using lists in Prolog).
This makes me somewhat nostalgic for some Lisp machines, which used an array representation in memory and expanded into a list representation in the cache.
Scryer also borrows things from SICStus, the most important commercial implementation of Prolog, which is also the fastest one and with lots of features too. Some libraries are closer to the SICStus ones than to the SWI ones.
SICStus was the Prolog that I originally learned, but I never used sufficiently advanced features to encounter differences between it and SWI.
They’re provided as extensions. ISO Prolog itself is small (for reference, ISO Prolog predicates are only the ones listed in builtins library). Other systems have tabling and/or constraint solvers with different syntaxes.
Really appreciate the ‘Where can I learn Prolog?’ section on your page with a link to Triska’s web book! Thanks!
I have to thank Triska for his work on this new website too. He has written and supervised some sections!
It would be nice to see a comparison to other Prolog implementations. Last time I used Prolog, I used SWI, which is BSDL and seemed to work. Why would I use this instead (and, conversely, why would I not use it)?
In terms of features and performance, SWI would win :) That is expected as IIRC SWI’s codebase comes from the late 80s while Scryer is much newer and hasn’t reached 1.0 yet. Also, SWI nowadays has a full-time person working on it.
However, there’s a point to be made about “being a Prolog”. SWI doesn’t comply with ISO Prolog and doesn’t want to. Some people even refer to SWI as Prolog-based rather than Prolog. This mostly happened in version 7 with the addition of “opaque” strings and dictionaries. Also, Scryer has had a big focus on finding the declarative, pure, monotonic abstractions to advance Prolog with the original philosophy. For example, Scryer rather than use an “opaque” type for strings, it uses a compact representation internally but externally it behaves as a list of characters (and you gain all the benefits of using lists in Prolog).
Scryer also borrows things from SICStus, the most important commercial implementation of Prolog, which is also the fastest one and with lots of features too. Some libraries are closer to the SICStus ones than to the SWI ones.
SWI’s deviations from ISO Prolog are mostly extensions and behaviors that are unlikely to offend most Prolog users. I’m think improper lists and strings-as-lists-of-integer-codepoints are more confusing to modern programmers than SWI’s behavior. I have heard this argument (that SWI isn’t ISO) on Reddit as well and I just don’t think it is very salient. SWI is the flagship open source Prolog. If someone doesn’t know which to use, it’s the one they should try.
ISO Prolog is also quite small and every Prolog implementation winds up bringing along a ton of extra functionality. You say so yourself: “finding abstractions to advance Prolog with the original philosophy” is of course adding new stuff to Scryer that isn’t ISO.
This sounds more negative than I intend to be. I think I’m just trying to say, throwing the “it isn’t ISO” at SWI is a little disingenuous when most programmers who are curious about Prolog are unlikely to need what is unavailable in SWI and unlikely to care deeply about portability to other implementations when SWI has so much more on offer.
That said I am getting interested in Scryer and I appreciate the work you’ve put into it. Having some competition in this area is a good thing, and GNU Prolog seems to be kind of in stasis.
I agree with a lot of your points. SWI is indeed the Prolog I used myself for learning. However, the string handling of Scryer was one of the reasons I started to contribute to Scryer. String processing in SWI requires new predicates written from scratch to handling them or lots of conversions. This might seem a minor annoyance but when you start using DCGs, it becomes more tedious. BTW Scryer doesn’t have “strings-as-lists-of-integer-codepoints” either by default.
Adding things to Prolog is totally fine and necessary in my opinion but it should respect the backward compatibility of already written standard code.
GNU Prolog is a very cool project. It is the fastest open-source Prolog. That’s because it actually compiles down to native code. We want to do something like that in Scryer using Cranelift but it’s a big task!
Thanks, sounds like a great project.
This makes me somewhat nostalgic for some Lisp machines, which used an array representation in memory and expanded into a list representation in the cache.
SICStus was the Prolog that I originally learned, but I never used sufficiently advanced features to encounter differences between it and SWI.
exciting. I have had my eye on this for a while. having constraint solvers and tabling makes this an extremely powerful tool.
Does Scryer Prolog provide them as extensions on top of ISO Prolog? Or are constraint solvers and tabling part of ISO Prolog? Prolog newbie here.
They’re provided as extensions. ISO Prolog itself is small (for reference, ISO Prolog predicates are only the ones listed in
builtinslibrary). Other systems have tabling and/or constraint solvers with different syntaxes.