Scryer Prolog(scryer.pl)
scryer.pl
Scryer Prolog
https://www.scryer.pl
34 comments
SWIProlog[1] has so far been my go to due to the extensive support system it has. However, I've been meaning to explore higher order logic a bit and Ciao[2] caught my attention there, with sugar for function-like notation and higher order programming including "lambda" style predicate expressions .... and it compiles down to executable. The function notation in this context is along the same lines as Mozart/Oz and can be convenient. Not explore the higher order aspects much though.
[1]: https://www.swi-prolog.org/
[2]: https://en.wikipedia.org/wiki/Ciao_(programming_language)
[1]: https://www.swi-prolog.org/
[2]: https://en.wikipedia.org/wiki/Ciao_(programming_language)
Hey, if you're interested in higher-order logic programming then you might want to have a look at Meta-Interpretive Learning (MIL). It's a new approach to Inductive Logic Programming (ILP) that learns by SLD-resolution with first- and second-order definite clauses (hence, "higher-order").
You won't find much on MIL as "higher-order logic programming" but that's really what it is: it's logic programming; with a higher-order program (i.e. one containing both first- and second-order clauses). The catch is that once you do this any proof you complete gives you instantiations into the second-order variables in the second-order clauses and now you have yourself a first-order program, that you didn't have before; hence "inductive". So it's basically a form of machine learning of logic programs, from other logic programs.
There are a few papers you can find online about MIL, but I recommend (PLUG ALERT) the documentation of the MIL system I created for my doctoral thesis as a starting point:
https://github.com/stassa/louise
I recommend that as a starting point because it's written for people who are familiar with logic programming, but not necessarily ILP. Anyway, plug over. I think MIL is an exciting new development that has of course gone under the radar of the logic programming community at large.
You won't find much on MIL as "higher-order logic programming" but that's really what it is: it's logic programming; with a higher-order program (i.e. one containing both first- and second-order clauses). The catch is that once you do this any proof you complete gives you instantiations into the second-order variables in the second-order clauses and now you have yourself a first-order program, that you didn't have before; hence "inductive". So it's basically a form of machine learning of logic programs, from other logic programs.
There are a few papers you can find online about MIL, but I recommend (PLUG ALERT) the documentation of the MIL system I created for my doctoral thesis as a starting point:
https://github.com/stassa/louise
I recommend that as a starting point because it's written for people who are familiar with logic programming, but not necessarily ILP. Anyway, plug over. I think MIL is an exciting new development that has of course gone under the radar of the logic programming community at large.
Beware of the license - https://github.com/stassa/louise/blob/master/LICENSE.md
Eh? What's wrong with the license? :P
It's not a free software license as it restricts freedom zero, the ability to use it for any purpose.
https://www.gnu.org/philosophy/free-sw.html#four-freedoms
It's interesting because I'm sure no free software author wants to inadvertently support a dubious cause. The Anti-Mil clause prevents that (in theory at least, as license enforcement is hard for everyone). However, it also nominally prevents use by good causes as well (you can grant exceptions, however). Good and bad here are relative to the author.
I guess it's a balancing act between upholding ones own sense of right and wrong, and the freedom for someone else to have a differing opinion than you.
Edit: Removed "strictly" from "strictly free software". It's unfree.
Edit: Added some words for clarification.
https://www.gnu.org/philosophy/free-sw.html#four-freedoms
It's interesting because I'm sure no free software author wants to inadvertently support a dubious cause. The Anti-Mil clause prevents that (in theory at least, as license enforcement is hard for everyone). However, it also nominally prevents use by good causes as well (you can grant exceptions, however). Good and bad here are relative to the author.
I guess it's a balancing act between upholding ones own sense of right and wrong, and the freedom for someone else to have a differing opinion than you.
Edit: Removed "strictly" from "strictly free software". It's unfree.
Edit: Added some words for clarification.
Thanks for your feedback. To be honest I wasn't thinking about free software, I wanted a license that would make the project available to everyone, unless they are affiliated with the military of some nation. There are no such licenses, so I improvised.
Perhaps there should be more such licenses. On the other hand, it might also create problems. For example, what if I decide that I don't want my code to be used by people who are against same-sex marriage, or abortion, or who are for those things, or who eat meat, or don't eat meat, etc?
In any case, the license is what it is. It's an unfree license. Thanks for pointing it out, I hadn't realised.
Perhaps there should be more such licenses. On the other hand, it might also create problems. For example, what if I decide that I don't want my code to be used by people who are against same-sex marriage, or abortion, or who are for those things, or who eat meat, or don't eat meat, etc?
In any case, the license is what it is. It's an unfree license. Thanks for pointing it out, I hadn't realised.
There's an immediate issue and a more important social issue.
The immediate issue is that other projects can't use your code because your license is incompatible with their license. That's why we all use the same handful of standard licenses. We definitely can't use non-lawyer licenses with jokes in them.
The social issue--which may be more important--is that the use of standard licenses is sort of a shibboleth for industry programmers. Homegrown non-lawyer licenses stick out; you may not be aware of how much signaling this license is doing about the seriousness of the project. It flags the project as purely academic or an unserious toy. Sort of an "outsider art" feel; a product of our industry in-group would have used an unmodified, standard real license instead.
The immediate issue is that other projects can't use your code because your license is incompatible with their license. That's why we all use the same handful of standard licenses. We definitely can't use non-lawyer licenses with jokes in them.
The social issue--which may be more important--is that the use of standard licenses is sort of a shibboleth for industry programmers. Homegrown non-lawyer licenses stick out; you may not be aware of how much signaling this license is doing about the seriousness of the project. It flags the project as purely academic or an unserious toy. Sort of an "outsider art" feel; a product of our industry in-group would have used an unmodified, standard real license instead.
Thanks for your comment.
>> The immediate issue is that other projects can't use your code because your license is incompatible with their license. That's why we all use the same handful of standard licenses.
The simplest solution to this problem that comes to mind is that other projects adopt the same license as mine. That would also take care of the social issue.
You say the license marks me as an outgroup to an ingroup. Given that the license prohibits the use of my code by users affiliated with the military of any nation, that's not an ingroup I want to be part of, and I think, if that's the result of using the license, then mission accomplished.
The joke of course is silly. It's an Easter egg. It could be removed if there was a real need.
But let's make no bones about this: the entire matter is completely irrelevant because the reason most people would have to not use my code is not the license, but the fact that it's written in Prolog, and it's a system that learns Prolog programs from Prolog programs. There is currently about 0 interest in that, outside a very narrow academic circle and certainly not in the wider industry, or the "ingroup" you mention above.
So really, the license, or the joke in it, makes no difference at all in practice.
>> The immediate issue is that other projects can't use your code because your license is incompatible with their license. That's why we all use the same handful of standard licenses.
The simplest solution to this problem that comes to mind is that other projects adopt the same license as mine. That would also take care of the social issue.
You say the license marks me as an outgroup to an ingroup. Given that the license prohibits the use of my code by users affiliated with the military of any nation, that's not an ingroup I want to be part of, and I think, if that's the result of using the license, then mission accomplished.
The joke of course is silly. It's an Easter egg. It could be removed if there was a real need.
But let's make no bones about this: the entire matter is completely irrelevant because the reason most people would have to not use my code is not the license, but the fact that it's written in Prolog, and it's a system that learns Prolog programs from Prolog programs. There is currently about 0 interest in that, outside a very narrow academic circle and certainly not in the wider industry, or the "ingroup" you mention above.
So really, the license, or the joke in it, makes no difference at all in practice.
Yes but that wouldn't accomplish the obvious intent of the license, which is clearly important to the author.
I think they're signaling exactly what they want to.
I think they're signaling exactly what they want to.
[deleted]
Thanks for that ref ... and plugs like that very much welcome!
I work with Mark Thom, a Scryer Prolog developer. That said I have used Swi-Prolog for 20 years so it may be a while before switching.
Coincidentally I just started re-reading The Art of Prolog yesterday. It is an old book, but good. For some types of applications, Prolog is pretty much amazing.
EDIT: nice documentation pages, BTW.
Coincidentally I just started re-reading The Art of Prolog yesterday. It is an old book, but good. For some types of applications, Prolog is pretty much amazing.
EDIT: nice documentation pages, BTW.
Is the difficulty switching from SWI due to tooling issues or because source code changes are required?
mark, which type of applications is prolog amazing for?
Not Mark.
The obvious answer: knowledge base. Prolog is the best database I know when it comes to encoding complex relationships and querying for complicated answers.
Less obvious: parsing. It's very easy to write parsers in Prolog. I wrote Protobuf and Thrift parsers in it (for the schema, not the binary payload) and each one took about a day of work. I didn't use those parsers in commercial settings, but I did write a parser in Prolog to help me to generate Swagger from some RoR structured comments (I don't know Ruby, but could figure out what was in the comments).
Another ways I used Prolog in practice and would use it more: software testing. Prolog lends itself very well to describing the model of SUT and to "parametrization" of testing. I was very close to using Prolog in this capacity, and worked for almost half a year on a proposal for replacement of the company's existing tests with something based on Prolog, but eventually failed to convince my bosses that it would work (same arguments as always, basically, "water from the toilet").
The obvious answer: knowledge base. Prolog is the best database I know when it comes to encoding complex relationships and querying for complicated answers.
Less obvious: parsing. It's very easy to write parsers in Prolog. I wrote Protobuf and Thrift parsers in it (for the schema, not the binary payload) and each one took about a day of work. I didn't use those parsers in commercial settings, but I did write a parser in Prolog to help me to generate Swagger from some RoR structured comments (I don't know Ruby, but could figure out what was in the comments).
Another ways I used Prolog in practice and would use it more: software testing. Prolog lends itself very well to describing the model of SUT and to "parametrization" of testing. I was very close to using Prolog in this capacity, and worked for almost half a year on a proposal for replacement of the company's existing tests with something based on Prolog, but eventually failed to convince my bosses that it would work (same arguments as always, basically, "water from the toilet").
Sorry, I'm curious, what is "water from the toilet"? A quick search of the internet turns up nothing very clear.
It's a reference to Brawndo marketing campaign, a sugary soda drink from the movie Idiocracy. The marketing campaign discouraged buyers from using water for drinking and irrigation which caused famine because the audience was not good at critical thinking but very susceptible to marketing tricks. Whenever there was a question of using water s.a. to water the crops, everyone would ask with disgust if they intend to use the same water that's used in the toilet.
This is the attitude I've encountered a lot when dealing with trends in technology. For example, there's hatred of XML suit of tools and formats. And it is so entrenched and especially more so with people who have a very superficial understanding of the subject, who also happen to be the majority of the target audience. Thus, every time when a project requires a simple to parse format with schema validation, powerful querying mechanisms, extensibility... while XMLs easily checks all those boxes, developers will tie themselves into knots only to avoid using it making all sorts of ridiculous claims about XML.
I'm not specifically advocating for the use of XML, and I believe there are better formats... unfortunately those would be an even harder sell :) I'm just using XML as an example of something that should've been a no-brainer for many trivial tasks, and yet it's been avoided like a plague for superficial reasons.
This is the attitude I've encountered a lot when dealing with trends in technology. For example, there's hatred of XML suit of tools and formats. And it is so entrenched and especially more so with people who have a very superficial understanding of the subject, who also happen to be the majority of the target audience. Thus, every time when a project requires a simple to parse format with schema validation, powerful querying mechanisms, extensibility... while XMLs easily checks all those boxes, developers will tie themselves into knots only to avoid using it making all sorts of ridiculous claims about XML.
I'm not specifically advocating for the use of XML, and I believe there are better formats... unfortunately those would be an even harder sell :) I'm just using XML as an example of something that should've been a no-brainer for many trivial tasks, and yet it's been avoided like a plague for superficial reasons.
Oh, I see, thanks! I've watched Idiocracy but I guess I didn't make the connection. Good on you for avoiding spoilers also ;)
And that's a good point about entrenched opinions in tech. On the positive side, this kind of thing creates an imbalance that opens opportunities. For example, I managed to start a PhD in Inductive Logic Programming at a good university, when my academic record up to that point had been average, and I suspect that was mainly because I applied for research in an area where there are very few applications, namely Inductive Logic Programming: even now everyone's running the other way, towards deep learning :D
And that's a good point about entrenched opinions in tech. On the positive side, this kind of thing creates an imbalance that opens opportunities. For example, I managed to start a PhD in Inductive Logic Programming at a good university, when my academic record up to that point had been average, and I suspect that was mainly because I applied for research in an area where there are very few applications, namely Inductive Logic Programming: even now everyone's running the other way, towards deep learning :D
Nit: a page advertising ISO Prolog shouldn't start with non-ISO builtins such as append/3 however widespread append or the belief it's in ISO may be. Here's a variant using atom_concat/3 which is actually defined by ISO:
[1]: https://quantumprolog.sgml.io/browser-demo/browser-demo.html
?- atom_concat('Hello, ', X, 'Hello, ISO Prolog!')
[1]: https://quantumprolog.sgml.io/browser-demo/browser-demo.html
append/3 is a so-called extension of the standard:
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/prologue
Strings are a good representation for ephemeral data, where allocating an atom would yield additional overhead, via an entry in the atom table that is not needed elsewhere and can only be reclaimed by GC instead of much faster on backtracking.
Another major attraction of strings is that we can use DCGs to reason about them, and we can write this specific example equivalently as:
3.70 extension: A facility provided by the processor
that is not specified in this part of ISO/IEC 13211 but that
would not cause any ambiguity or contradiction if added
to this part of ISO/IEC 13211.
e) Offer a strictly conforming mode which shall reject
the use of an implementation specific feature in Prolog
text or while executing a goal.
$ scryer-prolog -f
?- append("Hello, ", X, "Hello, Scryer Prolog!").
error(existence_error(procedure,append/3),append/3).
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/prologue
Strings are a good representation for ephemeral data, where allocating an atom would yield additional overhead, via an entry in the atom table that is not needed elsewhere and can only be reclaimed by GC instead of much faster on backtracking.
Another major attraction of strings is that we can use DCGs to reason about them, and we can write this specific example equivalently as:
?- phrase(("Hello, ",seq(Cs)), "Hello, Scryer Prolog!").
Cs = "Scryer Prolog!".
> append/3 is only available if library(lists) is loaded
But it isn't loaded in the example Prolog showcase; that was my point ;)
Now, if it's being loaded via use_module (ie using flawed ISO/IEC 13211-2 modules that shall be forgotten since portability isn't achieved), then it would be at odds with the Prologue for Prolog which assumes it's being imported via ISO-conformant ensure_loaded, rather than as a module.
But it isn't loaded in the example Prolog showcase; that was my point ;)
Now, if it's being loaded via use_module (ie using flawed ISO/IEC 13211-2 modules that shall be forgotten since portability isn't achieved), then it would be at odds with the Prologue for Prolog which assumes it's being imported via ISO-conformant ensure_loaded, rather than as a module.
Any progress for Quantum conformity wise? It's doc reads is a full ISO Prolog implementation https://quantumprolog.sgml.io/docs/langreference.html
Hey,folks who are working with Prolog - what sort of work are you doing?
I work on an ancient, legacy system that manages company car rentals, written in Visual Prolog. Visual Prolog is an ojbect-oriented, typed, compiled, version of Prolog, so it's very, very different than ordinary Prolog ("ordinary" for me anyway).
To be honest, it's not the most exciting system to be working on. It's basically using Prolog to encode business rules and perform calculations that you would sometimes expect to see in a spreadsheet (but then, there are parallels between logic programming and spreadsheets, e.g. see [1,2]). Prolog of course is a great language for that sort of use. On the other hand, I think the idea of turning Prolog into an object-oriented language is the worst idea of all times. I mean, when I quit my job in the industry to do a PhD, a big draw was that I could work with Prolog, but not OOP. And now I'm back in the industry working with an OOP Prolog. Resistance is futile.
The fun part is that the project I'm working on has been developed over 20 years by multiple people with very, ah, let's say varied opinions on the necessity of maintainability of old code. There are missing sources, old configurations that break compilation, no structured comments whatsoever, no version control (NO VERSION CONTROL!!! AAAAAH!!!), about 1/10th of the LOCs are commented-out for reasons unknown and unspecified in any comments, and so on, so forth.
So it's really cool to work with. I absolutely love digital archeology! :D
_________________
[1] https://www.j-paine.org/spreadsheet_structure_discovery.html
[2] https://dl.acm.org/doi/10.1145/67449.67466
To be honest, it's not the most exciting system to be working on. It's basically using Prolog to encode business rules and perform calculations that you would sometimes expect to see in a spreadsheet (but then, there are parallels between logic programming and spreadsheets, e.g. see [1,2]). Prolog of course is a great language for that sort of use. On the other hand, I think the idea of turning Prolog into an object-oriented language is the worst idea of all times. I mean, when I quit my job in the industry to do a PhD, a big draw was that I could work with Prolog, but not OOP. And now I'm back in the industry working with an OOP Prolog. Resistance is futile.
The fun part is that the project I'm working on has been developed over 20 years by multiple people with very, ah, let's say varied opinions on the necessity of maintainability of old code. There are missing sources, old configurations that break compilation, no structured comments whatsoever, no version control (NO VERSION CONTROL!!! AAAAAH!!!), about 1/10th of the LOCs are commented-out for reasons unknown and unspecified in any comments, and so on, so forth.
So it's really cool to work with. I absolutely love digital archeology! :D
_________________
[1] https://www.j-paine.org/spreadsheet_structure_discovery.html
[2] https://dl.acm.org/doi/10.1145/67449.67466
I keep seriously considering trying https://logtalk.org/ to get myself object orientation in prolog - haven't done so yet, expressing no opinion as to whether it's a good idea in practice, but it definitely looks like it'd be fun to play with.
Well, Paulo (Moura, logtalk maintainer) has done an amazing job and I don't want to disparage it. I still think it's a bad idea to make an OOP Prolog. I think it's a bad idea to do anything to Prolog to make it more like something else. Prolog is a unique jewel of computer science, with unique flaws and unique virtues, and I am pretty convinced that there is nothing that can make it better, without breaking the delicate balances that make it absolutely amazing the way it is. There have been many efforts to "make a better Prolog" (never explicitly articulated like that), for example, Answer Set Programming, or Datalog, I guess. Everytime someone tries to do that, they break Prolog irreparably: Datalog and ASP can't even use lists; ASP has to ground the entire program and then hand off to an NP-complete solver.
As to OOP, I think I'm not alone when I say that I've seen the horrors that people create when given the freedom to instantiate their classes, and I will never unsee them. A great idea, but so was the Industrial Revolution, and now we have climate change.
As to OOP, I think I'm not alone when I say that I've seen the horrors that people create when given the freedom to instantiate their classes, and I will never unsee them. A great idea, but so was the Industrial Revolution, and now we have climate change.
Now that is a name I didn't saw for a while.
I remember the ads in Dr Dobbs!
Thanks for sharing.
I remember the ads in Dr Dobbs!
Thanks for sharing.
I didn't succeed in convincing my bosses to adopt a testing framework written in Prolog, but, technically, I worked in Prolog for almost half a year when working on this proposal. This, however, was 5+ years ago.
For this purpose I used Golog (a very simple, and not very performant Prolog interpreter written in Go). We had already a lot of infrastructure code written in Go, so it would've been a big problem if we couldn't reuse it during migration.
I extended the interpreter in two major ways:
1. Marshalling of structs from Go to Prolog and back. 2. Made most of the meta-predicates parallizable.
The second was meant to be an essential improvement over existing testing framework because it struggled with deploying tests in a large distributed system, running them while allowing various communication patterns and collecting results. The system that was supposed to be tested in this way was a distributed parallel filesystem. The kind of tests I was hoping to leverage with my proposed framework were along the lines of: let multiple users perform various filesystem-related operations on the shared filesystem tree while connecting from different physical nodes and see if anything goes wrong.
The system worked enough for a demo, but was never approved for real use.
For this purpose I used Golog (a very simple, and not very performant Prolog interpreter written in Go). We had already a lot of infrastructure code written in Go, so it would've been a big problem if we couldn't reuse it during migration.
I extended the interpreter in two major ways:
1. Marshalling of structs from Go to Prolog and back. 2. Made most of the meta-predicates parallizable.
The second was meant to be an essential improvement over existing testing framework because it struggled with deploying tests in a large distributed system, running them while allowing various communication patterns and collecting results. The system that was supposed to be tested in this way was a distributed parallel filesystem. The kind of tests I was hoping to leverage with my proposed framework were along the lines of: let multiple users perform various filesystem-related operations on the shared filesystem tree while connecting from different physical nodes and see if anything goes wrong.
The system worked enough for a demo, but was never approved for real use.
Sorry to hear that. It sounds like a project that would have been very rewarding to work on. I for one would have liked to hear more about the parallelisation of meta-predicates, that sounds cool.
There was a recent thread Prolog at work with many interesting links and posts:
https://news.ycombinator.com/item?id=34164221
https://news.ycombinator.com/item?id=34164221
Nice, this project has been sorely missing some documentation.
Are there any nice temporal logic libraries?
https://news.ycombinator.com/item?id=28966133
Since then, a great number of improvements have become available, among them:
The system is now much faster, thanks to a much more compact internal representation of WAM heap cells. In addition, goals that occur as arguments of meta-predicates are now automatically compiled much more efficiently, avoiding superfluous lookups at runtime. Also, Adrían Arroyo Calle has contributed new and much improved HTTP server and client libraries, based on the Rust crate "hyper".
Scryer Prolog 0.9.1 and later versions ship with all these improvements and several smaller corrections and additional features.
Adrían also built the documentation system DocLog that he uses to generate this nice home page of the project:
https://github.com/aarroyoc/doclog
DocLog uses Djota, a Prolog implementation of the markup language Djot:
https://github.com/aarroyoc/djota
Such systems show that nice applications can already be built with Scryer Prolog and its innovations.
Thank you a lot to Mark and everyone who contributed to Scryer Prolog, please keep up the great work!