Not specifically aimed at this comment, but it looks like in most Prolog threads here, many commenters seems to plugging in Scryer Prolog, but perhaps, SWI is the most 'batteries included' and mature Prolog implementation for people not familiar with Prolog to try out .
There is a bit of... let's say friction between Markus Triska (Scryer) and Jan Wielemaker (SWI), I seem to remember. The SWI people are much less attached to ISO Prolog (i.e. prone to experiment with non-ISO syntax), and some things that are fixed in the SWI implementation impeded the realization of M. Triska's projects. Generally, people tend to like the new and shiny but there's also a significant philosophical gap between Scryer and SWI.
Now why would syntax be that important? It's because it directly enables homoiconicity, which is central to Prolog metaprogramming features: executing Prolog code returns a Prolog term, that can be read (just like Lisp). This is the distinctive characteristic of Prolog compared to more mainstream solvers, and what makes it 'a good programming language because it's a very dumb theorem prover'.
Wot. SLD Resolution is a "very dumb" theorem prover?
SLD Resolution is sound and refutation-complete and it is the basis not only of Prolog but also the most successful bunch of SAT solving algorithms in the last, dunno, several decades.
SLD-Resolution is sound and refutation-complete (and also complete with subsumption). If you think that O'Keefe is right to say that it's a "very dumb theorem prover" then explain to me why _you_ think so, not who said it.
Because I, too, can quote you authorities- and probably bigger than O'Keefe.
Not an appeal to authority. Just showing that quote wasn't of my invention. I don't really get why you're so riled up. I'm not saying SLD resolution is dumb, just that Prolog stays simple by not including all the clever heuristics and circumstantial techniques of other solvers. Which is a big part of what makes Prolog a nice programming language. It's more a compliment than a critic, really!
I'm not riled up, I even upvoted your OP, but it's uncouth to drop a quote without any context as a reply to a comment. Of course there's going to be misunderstandings.
I didn't remember that quote from O'Keefe. Prolog is indeed not trying to be smart and SLD-Resolution is dead simple - it's a sound and complete deductive inference system with a single rule. The reason Prolog is in turn so simple is because, thanks to the refutation-completeness of SLD-Resolution, you can implement it as a Depth-First Search for resolvents and then spam it until you get a result (or until you hit an infinite branch... oops). That's certainly orders of magnitude more simple than every other solver or automated theorem prover out there, like you say.
If that's what O'Keefe means, that Proolog is not trying to be smart, then OK, but that's not dumb. Every other solver tries to be smart and ends up having to solve an unsolvable problem. Who's dumb now then?
But maybe that's the compliment, I don't remember the context of O'Keefe's comment. Was it in the Craft of Prolog?
TBH, I don't remember where I first read it, but it's all over the web xD. This is all just a misunderstanding: since I knew you were a Prolog expert, I assumed you would recognize my (botched) quote and the context. Yeah, I understand it as: 'better to keep it simple and understandable'
SWI Prolog 7 added "X = Dict.key" syntax and that use of "." makes it fundamentally incompatible, ISO standard breaking, backwards incompatible to previous Prologs, sideways incompatible to other Prologs.
This is a worse sin in Prolog than it seems at a glance, because one of the strengths Prolog has is code-is-data / data-is-code metaprogramming. That includes exporting code as Prolog terms (use cases you might use CSV or JSON for in other languages), reading them back in as Prolog data (perhaps in a different Prolog system or different version) and executing the data as Prolog code. With that "." syntax change no other Prolog system can guarantee to read all SWI Prolog code, SWI 7 can't guarantee to read all SWI 6 code, and SWI 6 can't guarantee to read all SWI 7 code.
Code might say "connect_to_mongodb()" and you don't have mongodb in your system so you cannot run it, but you can read the code in as data and it will parse, just like reading in JSON which has a string mentioning some library you don't have; you can still introspect it and write reports like "what names does this data reference?", you can transform it and export it, or pass it through untouched. With SWI's new dot syntax the code might not parse at all, like an incompatible proprietary JSON syntax where you can't even import it. Code written 30 years ago which uses the dot in the old standard way might trigger SWI to try and read it in the Dict.key way and fail. Code exported from SWI 7 might include this syntax which other systems can't import.
I don't know how often it will come up in practise, but it seems that SWI could have done it with a slightly different syntax that would have been as convenient to use and also been a standard term and wouldn't have made this split at all. SWI has some other differences versus ISO Prolog, things inside error handling, for example, but none quite so fundamental as this. And it's annoying from the outside because you can wade into a big-ball-of-mud design-by-committee language, but if you want to look at an esoteric language and they're all arguing over who is most pure and virtuous you have to pick a religion before you can write Hello world.
Markus Triska's Power of Prolog series has been some of the best Prolog publicising material in years, something that isn't (totally) a dry academic text of "a --> a | a. a(A) :- a([a|As]) , a(As).", it must be a huge amount of work on his part. He uses and contributes to Scryer Prolog, and he is especially interested in Constraint Language Programming which he wrote/maintained in SWI[1], and has moved the newer versions to Scryer.
That said, I strongly agree with your comment, SWI is batteries included, it has lots of builtins, a packaging system to download and install modules, it has a debugger and graphical debugger and tracer and just a ton of decades of development and polish that Scryer hasn't had time to develop yet, and is much much friendlier for people not familiar with Prolog to try out. You have to be pretty hardcore to be writing Scryer Prolog in EMACS buffers with no predicate search, no help, limited libraries, limited documentation, limited debugging, very small online community even by Prolog standards which is already small.
When you could open https://swish.swi-prolog.org/ and click 'new Program' and as a beginner be able to write syntax highlighted code in browser with no download, no setup, no install, no account registration, but it's SWI Prolog.
Query "apropos(string)" in the query box in the lower right and see things like "string_lower/2" and "string_concat/3". That search is convenient and those predicates are SWI custom ones.
Query "help(format)" and see HTML styled, coloured, scrollable help for the text formatting domain specific language. That's enormously useful.
The Power of Prolog series is great and what Markus is doing is vital: We must teach that Computer Science is not an exotic, marginal way of approaching software development, but the foundation that we constantly draw upon and inhabit.
I don't know if they could do a try/fallback or if one is available as a setting (I haven't looked), but apparently they don't by default; Scryer Prolog:
?- X = '.'(1,'.'(2,'.'(3,[]))).
X = [1,2,3].
SWI Prolog 9:
?- X = '.'(1,'.'(2,'.'(3,[]))).
ERROR: Type error: `dict' expected, found `3' (an integer)
All of what you say is true, and yet practical applications that did break are somehow not talked about quite as much as hypothetical applications that might have broken. SWI could reuse infix dot precisely because it was universally considered bad style to use it in the old style, and hence was not used in the old style.
Which is not to say that I think the record syntax is particularly useful. But I wish not every Prolog discussion devolved into "Markus Triska fanpersons regurgitate walls of text about infix dot".
I wish not every Prolog discussion had a top comment about Mercury, Curry, Minikanren, et al; but I think you missed the end of my comment where I recommended SWI over Scryer for most people; I am unashamedly a Markus Triska fanperson but that doesn't mean I do everything he does, or that I subscribe to ISO Purity over all else. It was more that the parent comment claimed a "friction between two people" and I think that's unfair and leaves readers expecting soap opera drama where someone insulted someone's mother; whereas it is a difference of opinion about language compatibility and standards - and once you know that you can decide whether it matters to you and your potential use cases (which, again, it doesn't to me and I think it doesn't to anyone who hasn't touched Prolog before).
I am not aware of any practical applications which have broken, but then I'm not aware of anyone using Prolog for anything, anywhere.
> I wish not every Prolog discussion had a top comment about Mercury, Curry, Minikanren, et al
Absolutely. Datalog too.
> but I think you missed the end of my comment where I recommended SWI over Scryer for most people
I did not miss that. I have no complaints about that part of your comment. I complained about the prologue to it, which I thought was beside the point and devalued the whole thing.
> but then I'm not aware of anyone using Prolog for anything, anywhere.
>> Code might say "connect_to_mongodb()" and you don't have mongodb in your system so you cannot run it, but you can read the code in as data and it will parse, just like reading in JSON which has a string mentioning some library you don't have; you can still introspect it and write reports like "what names does this data reference?", you can transform it and export it, or pass it through untouched. With SWI's new dot syntax the code might not parse at all, like an incompatible proprietary JSON syntax where you can't even import it. Code written 30 years ago which uses the dot in the old standard way might trigger SWI to try and read it in the Dict.key way and fail. Code exported from SWI 7 might include this syntax which other systems can't import.
So just write a translation layer, or add some flags to your Prolog so it can parse SWI's syntax. SWI does that (it has flags to adjust itself to other Prologs' syntax). Do other Prologs do that? Not to my knowledge, but why not? It's no big deal and certainly not a big enough deal to cleave a rift in the Prolog community, as if it wasn't small enough and dwindling already. I think some people have convinced themselves it's "better to be first in the village than second in the city" and they just don't want to work with others.
And as it sounds like you probably know, SWI is by far not the only Prolog to commit that cardinal sin of breaking portability. Basically every Prolog ever does that. Every single one. The ISO standard is just as opinionated as everybody else about what Prolog should be like (and btw ISO is not Edinburgh, let's not forget- and who came first, huh?) except it has delusions of grandeur because ISO.
I will take batteries included over nose-in-the-air "we have strict adherence to standards" any day.
> "cardinal sin of breaking portability. Basically every Prolog ever does that. Every single one."
Indeed; still Markus Triska speaks positively about, and recommends, different Prolog systems. He seems to prioritise things above ISO purity, and is not king of the hill of Scryer Prolog[1], he doesn't comment like others who act as if "the village and city can burn to the ground for all I care, heresy against ISO Prolog is NEVER acceptable". So when he's finding this objectionable even after considering that, it seems reasonable for me to weight it more strongly. It's not enough to make me stop using SWI, or stop me recommending it (as I did above).
The lack of portability is a bad problem in the Prolog world and it has bit me a few times, but surely the solution is for all the implementers to work together, rather than engage in petty feuding.
But the biggest problem of the Prolog community is what I pointed out above: there's very few of us and the field isn't really growing much.
