I would be really interesting in getting a list of common problem or category of problem that people usually implement in "common" languages but that would benefit highly from being written using Prolog.
I did learn prolog during my engineer degree but we never went further than the "school" exercises of finding if Mary is a member of the family of Bob or not.
I then later played, while still being a student (i.e still playing with things for intellectual fun rather than actual real life/business problem solving) a bit with Flora2 http://flora.sourceforge.net/ that seams to me like a hackier but stronger variant of Prolog (the object-like syntax and the possibility to pass rule has parameter to other rule).
At the opposite I learned also about functional programming, and until last year I was also wondering the same until it became clear to me with javascript (for the 'no class', function as parameter) and Rust (for the immutable by default part). Ohhhhh suddenly all these for loop to create an other list of the same size, all these for loop to arrive to one result, all these for loop to get a subset of the list, all these for loop to find one specific value, ALL gones and replaced by primitives.
All of that to say I really hope I'm missing something with Prolog that can elevate my thinking.
There's no simple list, really...it's just highly domain specific. I can give you an example though.
At work, we have a very large set of data representing individual "runs" that has to be "scored" (given various different numbers) in an ever-growing list of complicated ways. Originally these scorers were written in Python. This proved to be very difficult to maintain, and we recently moved to writing these in a Prolog-like language (not Prolog, but close enough for this discussion). At the end of the day it feels kind of like a much more powerful SQL (which makes sense, as SQL is a "relational" programming language and quite similar in concept). The facilities of logic programming perfectly fits this use case.
Similarly, you might take a look at anything people use "miniKanren" (an embeddable logic DSL) for. The fundamental thing to realize about Prolog, imho, is that while it's Turing-complete and has GUI facilities I wouldn't really call it a general-purpose programming language. It really works best as something like a DSL when you have tasks that require lots of logic and searching.
edit: Actually, writing this, I have a list for you. Do you need to perform a search and compute a result over a big data set, sort of like (in theory) you would with SQL on a relational DB? Then that's where logic programming languages shine.
If my link epic fails its "Representing Game Dialogue as Expressions in First-Order Logic" by Kaylen FJ Wheeler
Something like using clojure core.logic which is a minikanen which is prolog to implement video game dialogue programatically. Its a one line summary of 100 pages so take with grain of salt.
I have no connection with this topic other than skimming the paper when I went thru a phase after reading the most recent 7 languages in 7 weeks book and googling for minikanren applications and generally fooling around with the topic. There may or may not be better example, but it is at least "an" example.
NLP is old territory for AI and lisp and the like. Whats interesting about this specific part of NLP is limiting the territory and "guiding" it to fit a gaming requirement and integrating the conversation with game plot, more or less.
As another example, I thought for a bit about some kind of prolog reasoning engine to help with some ETL stuff I do and got pretty much nowhere, although it also is a limited area of NLP type stuff. There probably is some way to apply it... somehow. There should be a way to semi-intelligently read engineering data formatted in vague and confusing ways then reason about how to correctly import it.
I've used it as the basis for a rules based heads up no limit poker agent (game logic is also implemented in Prolog, GUI is Java/JS...needs a major rewrite though). Constraint satisfaction programming is pretty helpful.
It's mostly a rather simple agent but I'm currently working on a DSL to codify strategies more easily. I'm fully aware a rules based agent will never be strong but I'm mostly interested in figuring out how well experts can codify their strategies and if you can make them comparable (also looking into inductive reasoning and datamining strategy rules from sufficient hand samples of winning online players)
Mostly a toy project these days :)
[Edit: I'm actually going to rewrite it because it used Sicstus and I want to use an open implementation so I'll switch to SWI + while I'm at it I'll drop the Java stuff and go full JS/HTML. Pengines looks pretty good: http://www.swi-prolog.org/pldoc/package/pengines.html]
I think this might be a misunderstanding, the claim just shows up in a single CIA report about contemporary Soviet computer technology. Elsewhere[0] we read,
> Two new specific software languages known as "PROL-2" (used by the on-board computers) and "DIPOL" (used by ground computers using vehicle testing) [...] were developed for Buran
So I guess the what the CIA report refers to as Prolog is PROL-2. But is this really a Prolog variant? That seems like an unlikely choice of language for a real-time system.
Later, both of these languages developed into DRAKON [1], and looking at the Wikipedia page that language doesn't appear very Prolog-like, at least not superficially.
On the other hand, here[2] is a reddit comment that claims that is was indeed a Prolog variant, but it doesn't cite the source.
After my post I read up more and, like you, am now skeptical. I wonder if it's a case of someone mistaking PROL to be an abbreviation of prolog?
My old German university's web server was written in prolog, so it's not completeley inconceivable for a spacecraft, but I'd like to see more evidence.
Yes, that is my guess too. On the other hand, I would be _extremely_ interested to see a real-time Prolog dialect used to control real-life space shuttles, that's totally my aesthetic. :) But I can't understand Russian, which makes it difficult to research.
I had a ton of fun with Prolog embedded in the Tivoli Enterprise Console for managing network events from OpenView/NetView and a gaggle of other tools in a huge network.
We basically took about 120k daily events and turned that into about 60 actionable events that were meaningful to the NOC... All in about 2,000 LoC.
When our was at university, for part of the computer algebra course we had to work with a MacOS theorem prover application, written totally in house.
The theorem prover logic was in Prolog: it was totally the right tool for the job, and was small, effective, usable and (relatively) easy to understand.
The MacOS user interface was also in Prolog: it was totally not the right tool for the job, and to this day I am still astonished that it could even be done, let alone produce a usable UI.
Logic programming shines in any domain where unification is used heavily. An example is writing executable semantics or type inference/checking algorithms. Here's some code I hacked up as an example a few years ago that implements an interpreter and HM type inference for a small functional language: http://pastebin.com/aWBWSwiW
Michael Hendricks' talk at last year's Strange Loop on "Production Prolog" gives an excellent high-level survey of the uses, advantages, and drawbacks of Prolog: https://www.youtube.com/watch?v=G_eYTctGZw8
BTW, I have played a tiny bit with Flora2 myself. It seemed really neat. If you're interested in the intersection of OO and Prolog, you may also want to look at Logtalk[0]. FWIW, if I understand your meaning correctly, it is very easy to "pass rules as parameters to other rules" in vanilla Prolog. It facilitates all sorts of higher-order approaches and is very good for meta-programming.
I could think of some interesting applications for graph analysis and the semantic web with Prolog. As an outsider looking in, Prolog as a programming language appears to have a lot more flexibility than a query language such as SPARQL or the various graph traversal libraries and APIs that are out there.
A lot of UI programming patterns are much easier to express in a constraint programming language. Things like data binding don't exist in logic programming, since they are captured by constraints. It is also easier to do common tasks like position elements in a way which reacts nicely due to resizing a viewport, etc.
Today constraint solving is still confined to a lot of niche applications like physics engines or CAD systems, but I keep hoping for the day that someone will build a more integrated system which makes it easier for anyone to grab constraints and plug them in where it makes sense.
I once had to write a menu system in Turbo Prolog. Not fun. Totally the wrong tool for the job. Prolog isn't that useful when you have to cause an action, as opposed to computing a result.
Have you used any of the numerical constraint solving libraries available for many Prolog implementations?[1] (It is also worth noting that Turbo Prolog is a rather peculiar—and now rather old—take on Prolog. I believe it has been superseded by Visual Prolog).
Another issue for prolog is that many of these "constraint solving" problems will lead to exponential-time algorithms in the worst case, specially if you use a naive implementation. Because of this, its common to use more specialized solvers (linear programming, SAT, ILP, SMT, etc) instead of a general logic-programming one.
I've been actively trying to learn Prolog for the past few months. It's definitely very different from other languages I've used, and it's changed the way I think about programming. Prolog seems to be a really brilliant set of ideas embedded inside a mediocre syntax with poor library support for things that are trivially easy in other languages.
I think Prolog rules can replace a lot of spaghetti code: stuff like "Usually do this, but then other times do this, unless this other thing is true. If there's a parse error, then do xyz and keep going." In ordinary procedural code, the exception cases can dominate the body of a function and may need to be deeply nested, but in Prolog, it's possible to cordon them off or express them at the top level.
I suspect it might be most useful as a DSL you can embed inside of other languages, though I haven't seen a good implementation of that. (The clojure core.logic library mentioned elsewhere looks really promising.)
I think it may also be useful for domain experts to specify simple rules that capture an aspect of their expertise. If you restrict the domain down enough, and work to figure out what predicates are needed, prolog rules can become easy enough to read that you don't need to know much programming to use them. But the devil seems to be in the details of connecting the core logic into a bigger system that actually does something.
For example, the answer for hooking prolog up to a SQL database is "Look at the ODBC library!", which is not a very satisfactory answer. I think you could build a really beautiful ORM system in Prolog, but nobody's done it yet. (Maybe ORM isn't the right phrase, but a clean way of relating prolog queries to database queries and vice versa.)
The syntax is wonderfully simple, but also has almost no sugar for common idioms. The predicate notation makes it somewhat harder to batch up a bunch of attributes into one conceptual "thing" than in other languages. That means you need to keep positional arguments in your head a lot more. I think aping the class constructor and attribute notation of other languages would be helpful like `my_foo(foo, bar:attr, baz:attr) :- [...].` Then you could reference that either as a constructor (`my_foo(a,b,c)` would state that `a.bar=b` and `a.baz=c`) or to generate goals, like `my_foo(foo), other_predicate(foo.bar)`. Prolog is so old that choices like "make '.' the end of a statement" made sense at the time, but haven't stood the test of history.
(Disclaimer: Many of my criticisms may have perfectly valid solutions in prolog. I'm still learning it.)
Right. I think this is how a lot of business requirements are specified, since they are frequently constructed by non-programmers. Taking a bunch of cases from a spec document generated by a domain expert and turning them into maintainable/readable procedural code takes a lot of creativity. I think it's easier to express case analysis like this in Prolog.
Datalog is a query language, but I haven't found good libraries for the "connector" pieces of translating prolog/datalog predicates to SQL, constructing or syncing schema definitions, and database migrations. It seems like if you want to use Datalog, Datomic is the best option. (But datomic is sort of pricey for commercial use relative to SQL databases like Postgresql.)
What sort of library support have you found wanting? While the Prolog ecosystem is admittedly tiny compared to mainstream languages, I have often been surprised by the amount of useful libraries available.
I love Prolog syntax. I do think there is room for improvement, but the language is also extremely flexible, and it is very easy to roll your own syntax. Funny enough, so far my many experiments with alternative syntax have mainly had the effect of convincing me of the elegance and power of standard Prolog syntax.
While there is no particular reason the '.' should be used to terminate statements (except the resonance with many natural languages in this regard), I think some sort of terminator is necessary to keep the syntax as flexible as possible. Like Lisp, Prolog syntax is isomorphic to its AST. Currently my main gripe with Prolog syntax is that it represents conjunction and delimitation of predicate arguments and list items with the same operator, `(,)/2`. However, that can be fixed in two lines:
:- op(1000, xfy, user:(&)).
A & B :- A, B.
But I'm not sure it really needs "fixing"...
Regarding, "batching up a bunch of attributes into one conceptual 'thing'": SWI-Prolog has implemented a special data structure it calls "dicts"[dicts] for this purpose, but I am not very fond of it (and there's a fair amount of concern over the way this implementation breaks compatibility with ISO standards). More traditional solutions are to use lists of "pairs"[pairs], option lists[option], or, for larger data structures and when performance and lookup time is an issue, association lists[assoc] or records[records]. Using the first of these techniques looks like this:
It might be the case that Prolog's flexible syntax leaves it spoiled for choices here... That being said, it would be straightforward to implement syntax similar to your description, which evaluates and replace attribute accessors in place, using `term_expansion/2` and `goal_expansion/2`. Then you could use `As.baz` in place of the value itself (I've done so before, and this is what the SWI-Prolog's dict expansion does). Even easier, you could use Michael Hendricks' func package[func] to make a function for this purpose. But I've increasingly come to think of Prolog's explicit evaluation as a unique strength rather than a problem to be solved.
I definitely agree that the terminator is a good idea, just that "." happened to be an unfortunately historical choice since other languages used that character for a very different meaning.
Thanks for the links! These look extremely helpful!
Am in my daipers. Could you point me in the right direction in learning about querying prolog through JavaScript. Av read some documentation on Pengines but wud love some more example code.
All standard Prolog really does is matching up "trees with wildcards in them" with other "trees with wildcards in them". The matching process happens in a very specific order and all I/O happens as side effects of small steps in the matching process (I/O operations are implemented as pseudo-constraints, i.e. small "twigs").
As a result, the order you write your constraints ("trees") in in Prolog is /very/ important. Things may not terminate or may blow up the stack or take far, far too long or produce the wrong I/O if the order isn't just right.
So standard Prolog is not a nice language.
But the idea of specifying constraints and let the computer find solutions is really nice. If only we didn't have those side effects weaved into the constraint solving process. And if we could specify the constraints separately from heuristics on how to solve them (i.e. the order in which to try things). Or if it could handle something more interesting than just "trees with wildcards".
mini-Kanren seems to be such a better constraint solving language -- I haven't tried it yet, since I am not done with my Prolog studies but I'm very much looking forward to it.
Some Prologs have extensions that ameliorate or completely fix some of the problems with Prologs. GNU Prolog, for example, has an extension to handle other kinds of finite domains (such as integers) than just trees:
Configuration problems -- "I'd like the fizzbiggle thingy with quanger III options and a blue prelz in red. Will that fit through my door and how much will it cost?".
I don't have a list, but I once wrote a software for finding the weak keys on Triple-DES using a functional-logic language. Writing the software was mostly defining the problem in a mathematical way, on the left side defining the hashing function and on the right side defining the desired properties (same output), leaving the hashes as free variables.
I have to say I was not only amazed by the exact solutions provided, but that it was found in 12 milliseconds - which includes program load and I/O time.
Not even a full Prolog, but Datalog, is very well suited for querying about graphs. I.e., for quite a lot of things you want to do inside a compiler. See an example here: http://people.csail.mit.edu/mcarbin/papers/aplas05.pdf
I also use full Prolog to implement type systems.
Prolog extended with a constraint solver is another thing one may want to employ for an elaborate program analysis, see how https://github.com/eholk/harlan is using cKanren for its region inference.
So, in my book, Prolog per se may have very limited use outside of teaching, but an embedded Prolog or a dumbed down Datalog can be an extremely powerful querying DSL which can make LINQ look dumb and clumsy.
I think it depends on one's notion of "scale". Expert systems would typically have few, correct facts. Or put another way, little, but very accurate information. If you say that anything less than a 128 (or 64 or 32 for that matter) gb working set is "small" (fits in ram) - for many problems you never need to "scale".
I did learn prolog during my engineer degree but we never went further than the "school" exercises of finding if Mary is a member of the family of Bob or not.
I then later played, while still being a student (i.e still playing with things for intellectual fun rather than actual real life/business problem solving) a bit with Flora2 http://flora.sourceforge.net/ that seams to me like a hackier but stronger variant of Prolog (the object-like syntax and the possibility to pass rule has parameter to other rule).
At the opposite I learned also about functional programming, and until last year I was also wondering the same until it became clear to me with javascript (for the 'no class', function as parameter) and Rust (for the immutable by default part). Ohhhhh suddenly all these for loop to create an other list of the same size, all these for loop to arrive to one result, all these for loop to get a subset of the list, all these for loop to find one specific value, ALL gones and replaced by primitives.
All of that to say I really hope I'm missing something with Prolog that can elevate my thinking.