He finds Scryer performs worse, which he does comment on, he also explains some tradeoffs and historic choices in SWI's design which affects its performance. I think I have seen the author of Scryer saying that's not surprising and Scryer is still building up core functionality where SWI has had 30+ years to optimise, but I don't remember where I read that.
So SWI appears to be more performant, it has an open license, so as per the GGP's claim regarding Scryer in the post above, it must not be ISO-compliant?
That's right; comedian Emo Phillips had a bit about it:
"Once I saw this guy on a bridge about to jump. I said, "Don't do it!" He said, "Nobody understand me." I said, "What's so special about you?"
He said, "I'm a computer guy." I said, "Me too! Desktop, tablet, console, smartphone?" He said "Desktop, mostly", I said "Me, too! Mac, Linux or Windows?" He said, "Any, I'm a programmer." I said, "Me, too! which style? OOP, Imperative, Functional, Logic, Array, Stack" He said, "Logic." I said, "Me, too! What subset? Answer Set Programming, Abductive Programming, Prolog, Datalog?" He said, "Prolog." I said, "Me, too! Conformant with the ISO/IEC 13211-1:1995 (core) standard term syntax for the period character or non-conformant extention decried by members of the ISO/IEC JTC1 SC22 WG17 working group?"
He said, "SWI Prolog 7" I said, "Die, heretic!" And I pushed him over."
A key performance attraction of Scryer Prolog is its space efficiency for representing lists of characters, yielding a 24 times (!) more compact representation than a naive implementation would.
With Scryer Prolog and other recent systems that implement this representation, such as Trealla Prolog, we can easily process many GBs of text with DCGs, arguably realizing the full potential of the originally intended use case of Prolog for the first time. Trealla Prolog goes even further already, and allows overhead-free processing of files, using the system-call mmap(2) to virtually map files to memory, delegating the mapping to the operating system instead of the Prolog system.
The linked benchmarks do not test these aspects at all, and in addition use a version of Scryer Prolog that was completely outdated already at the time the benchmarks were made: The benchmarks use Scryer Prolog v0.8.127, which was tagged in August 2020, more than 3 years (!) before the benchmarks were posted. The linked benchmarks thus ignore more than 3 years of development of a system that was at that time 7 years old. Newer versions of Scryer Prolog perform much better due to many improvements that have since been applied. More than 1700 commits were applied between these dates.
In the face of the 24-fold reduction of memory use that the above-mentioned efficient string representation enables, small factors of difference in speed between different systems are in my opinion barely worth mentioning at all in any direction.
And yes, in addition to this great space efficiency, the strong ISO conformance of Scryer Prolog is also a major attraction especially when using it in highly regulated areas. For example, here is a recently envisaged application of Scryer Prolog in the context of machine protection systems (MPS) of giant particle accelerators, where adherence to industry standards is of great importance for warranty reasons among others:
>> The linked benchmarks do not test these aspects at all, and in addition use a version of Scryer Prolog that was completely outdated already at the time the benchmarks were made: The benchmarks use Scryer Prolog v0.8.127, which was tagged in August 2020, more than 3 years (!) before the benchmarks were posted. The linked benchmarks thus ignore more than 3 years of development of a system that was at that time 7 years old. Newer versions of Scryer Prolog perform much better due to many improvements that have since been applied. More than 1700 commits were applied between these dates.
In the SWI-Prolog discourse thread linked above this is pointed out to Jan Wielemaker who clarifies it was a mistake. He then repeats the benchmark comparing a newer version of Scryer to SWI and finds that Scryer has improved significantly:
Updated Scryer Prolog to 0.9.3. They made serious progress. Congrats! The queens_clpfd.pl and the sieve.pl benchmarks have been added. The ISO predicates number/1 and retractall/1 have been added. I had to made more changes to to get the code loaded. Creating a module with the programs and some support predicates somehow did not work anymore (predicates became invisible). Loading a file programs.pl from directory holding a subdirectory programs silently loaded nothing until I added the .pl suffix. The sieve bar is cut at 20, but the actual value is 359.
> adherence to industry standards is of great importance for warranty reasons among others
This is mostly a nice talking point rather than an actual thing, right? Scryer's license contains the usual all-caps NO WARRANTY and NO FITNESS FOR A PARTICULAR PURPOSE wording. Also, the links you provided describe these applications without references to warranties and standards and regulation. The users in these super-sensitive domains don't seem as sensitive about them as you claim.
> the links you provided describe these applications without references to warranties and standards and regulation.
This is not true. For example, quoting from page 2 of the paper that is linked to in a discussion I posted, An Executable Specification of Oncology Dose-Escalation Protocols with Prolog, available from https://arxiv.org/abs/2402.08334:
"Standards are of great importance in the medical sector and play a significant role in procurement decisions, resolution of legal disputes, warranty questions, and the preparation of teaching material. It is to be expected that the use of an ISO-standardized programming language will enable the broadest possible adoption of our approach in such a safety-critical application area. For these reasons, we are using Scryer Prolog for our application. Scryer Prolog is a modern Prolog system written in Rust that aims for strict conformance to the Prolog ISO standard and satisfies all syntactic conformity tests given in https://www.complang.tuwien.ac.at/ulrich/iso-prolog/conformi...."
Regarding warranty guarantees of Scryer Prolog, may I suggest you contact its author if you need to negotiate arrangements that are not catered for by the only licence terms you currently have access to?
One important advantage you get from the strict syntactic conformance of Scryer Prolog is that it reliably tells you what is Prolog syntax and what is not. In this way, you can use it as a free reference system to learn what Prolog is. The conformance makes it easier to switch to other conforming systems, such as SICStus Prolog which also offers different licences and commercial support, when you need to.
> The users in these super-sensitive domains don't seem as sensitive about them as you claim.
I am at a loss at this phrasing and also about the content of this text. Apart from the facts that I did not use the wording "super-sensitive", and that the importance of standards is explicitly stated in the paper I quoted above, is there even the slightest doubt about the great importance of standards when building and operating giant particle accelerators or devising dose escalation trials in clinical oncology?
I acknowledge that you also included your nice talking point in a paper you published on arXiv. Citing yourself doesn't convince me any more of the credibility of this argument.
> is there even the slightest doubt about the importance of standards when building and operating giant particle accelerators
The particle accelerator application is a checker for existing JSON config files. The accelerator is already running with those files. The proposed project is in an early stage. The checker will add more assurance, which is nice. The checker's author does not talk about the importance of warranties or standards. The checker could just as well be implemented in some non-ISO dialect as long as that dialect has a reliable specification and implementation.
So yes, there is the slightest doubt.
Edit: BTW, your oncology paper heavily uses CLP(Z), which does not have an ISO standard, so your argument is... The base language must be standardized, but arbitrary nonstandard extensions are OK? Please clarify as I've probably misunderstood.
Some default settings in SWI are not ISO-compliant (for example, it uses a string type that does not exist in ISO). But these are minor things that won't usually trip you up when feeding it ISO code. You can set flags to get it to conform in the way you want. And you should set flags whenever you want your ISO Prolog programs to be portable, because the standard is very lax and leaves a lot of things implementation-defined. But it specifies the flags to get implementations into the state you want.
https://swi-prolog.discourse.group/t/porting-the-swi-prolog-...
He finds Scryer performs worse, which he does comment on, he also explains some tradeoffs and historic choices in SWI's design which affects its performance. I think I have seen the author of Scryer saying that's not surprising and Scryer is still building up core functionality where SWI has had 30+ years to optimise, but I don't remember where I read that.
SWI has a document explaining some strengths and weaknesses regarding performance: https://www.swi-prolog.org/pldoc/man?section=swiorother
Edit: some discussion on Scryer previously on HN: https://news.ycombinator.com/item?id=28966133