[HN Gopher] The Simplicity of Prolog
___________________________________________________________________
The Simplicity of Prolog
Author : thunderbong
Score : 162 points
Date : 2025-01-26 03:04 UTC (19 hours ago)
(HTM) web link (bitsandtheorems.com)
(TXT) w3m dump (bitsandtheorems.com)
| andsoitis wrote:
| > While SQL isn't normally used as a general purpose programming
| language I think it's quite illustrative for those otherwise
| unfamiliar with declarative languages (though apparently it is
| Turing complete)
|
| SQL itself is not Turing complete in its standard form because it
| lacks some essential features of a Turing machine, such as the
| ability to simulate unbounded loops or recursion within a single
| query.
|
| SQL with procedural extensions, such as PL/SQL (Oracle), T-SQL
| (Microsoft), and PL/pgSQL (PostgreSQL), are Turing complete
| because they allow constructs such as loops, conditionals, and
| recursive functions.
| GregDavidson wrote:
| SQL with CTEs is also Turing complete, which is not necessarily
| ideal. The Rule of Least Power
| https://en.m.wikipedia.org/wiki/Rule_of_least_power suggests
| avoiding OP languages. Less powerful languages can be more
| transparent (great for expressing contracts, e.g.
| specifications), tractability (proofs, optimization,
| termination, etc.) and so on. Many systems have been ruined by
| making them Turing complete.
| 29athrowaway wrote:
| Using SQL is perfectly fine.
|
| Datalog on the other hand is absurdly hard to work with.
| guskel wrote:
| To each their own.
|
| Others would say datalog elegant and makes it easy to compose
| statements whereas SQL has an ugly syntax. I mean, ORMs were
| invented to try to avoid writing SQL but they too have their
| own problems.
| sgarland wrote:
| > SQL has an ugly syntax
|
| Speak for yourself. I've always found it to be very clear
| and concise. SELECT <tuples> FROM <table>
| [[type of] JOIN other_table ON ?, ...] [WHERE ? [boolean
| operator], ...] [ORDER BY ? [DESC]] [LIMIT ?]
| baq wrote:
| Ansi SQL 99 defines recursive ctes.
|
| https://en.m.wikipedia.org/wiki/SQL:1999
| anonzzzies wrote:
| In a long forgotten past a large part of my graduation was Prolog
| (I was as far ahead then as i'm behind now with the ol' AI thing;
| I worked on mixing neural nets, reasoning with uncertainty with
| Prolog at the time) and, after hallucinatory episodes living,
| sleeping, (day)dreaming in Prolog for months on end, when
| something was finished I was always so surprised how clean,
| readable and 'too little' the code looked for what it did. Once
| you really grok it, it's a magic tool. I replaced it with Common
| Lisp after (in my uni, there was no mention of Lisp; we didn't
| even know it existed basically besides some weird scribbles in
| papers which were easy enough to study so we didn't give it more
| thought) and have the same feelings/experiences there but CL is
| usable for basically anything, including logic programming.
| ramses0 wrote:
| I really wish there was "regex for prolog", ie: when pounding
| away in JavaScript be able to do: let options
| = { foo: 1, bar: 2, ... } ```prolog $X :-
| fromJson( options ) Solution = Optimize( $X )
| ... ```
|
| ...like writing a whole web app in prolog sounds terrifying
| (same as writing a whole web app in regex), but recognizing and
| having some excellent interop between "modes" is obviously
| useful for regex, sometimes sql is supported in other
| languages, but even with the usefulness of prolog outcomes,
| there's almost never been that convenient "this section is
| logic" in the same way that we've universally adopted "regex"
| for string matching.
| Avshalom wrote:
| You might want http://tau-prolog.org/documentation#js
| andrewflnr wrote:
| It's been a while since I used it, but look at the miniKanren
| implementations for your favorite programming language (js in
| your case, but there are a lot). It's basically a stripped-
| down version of logic programming.
| llsf wrote:
| I think Lambda Prolog, is the only language that physically hurt
| my brain... in a good way.
|
| But damn, it felt like an extreme muscle stretching exercise.
| Painful when doing it, but you feel SO good after :)
| GregDavidson wrote:
| I have a long standing love affair with Prolog and frustration
| for its failure to grow. Prolog has poor features for abstraction
| and is actually not declarative enough!
|
| Prolog's limitations can be great for starting to get the
| paradigm but then you hit a wall. (Kind of like standard Pascal!)
|
| Mercury and Curry fix some of these limitations as does
| miniKanren. Integrating CLP is important yet so far always clumsy
| as standard Prolog provides no way to reify the environment.
|
| Some LP resources:
|
| https://minikanren.org/ https://mercurylang.org/
| https://www.curry-lang.org/
| https://en.m.wikipedia.org/wiki/Constraint_logic_programming
| https://logtalk.org/
| cess11 wrote:
| I take it you have some gripe with https://www.scryer.pl/clpz?
| Could you explain in more detail?
| derdi wrote:
| > Prolog has poor features for abstraction
|
| That's actually what this article presents as its strength and
| simplicity. The straightforward choice in Prolog is to use
| global "who may do what" tables. In contrast, the author
| overengineers a Kotlin solution and then says "look, this is
| overengineered". I think global tables would make the Kotlin
| code half as long and much simpler too.
|
| > Mercury and Curry fix some of these limitations
|
| At the cost of introducing new ones. Mercury makes it
| effectively impossible to pass around partially instantiated
| structures.
| Pet_Ant wrote:
| Doesn't Mercury declare each form of a rule independently?
| upghost wrote:
| Respectfully have to disagree. Prolog has the best features for
| abstraction of any language I've used, I suspect it may be near
| an optimal fixed point for metaprogramming expression[3]. I
| will say the other side of that wall is breathtaking.
|
| Also not sure what you mean, CLP is a first class consideration
| in many Prologs, esp Scryer Prolog. Check these crazy demos
| out:
|
| [1] https://youtu.be/h5Xy4YjCZxM
|
| [2] https://youtu.be/5KUdEZTu06o
|
| Just look at this Sudoku solver code (see [2] for explanation):
| sudoku(Rows) :- length(Rows, 9),
| maplist(same_length(Rows), Rows), append(Rows, Vs),
| Vs ins 1..9, maplist(all_distinct, Rows),
| transpose(Rows, Columns), maplist(all_distinct,
| Columns), Rows = [As,Bs,Cs,Ds,Es,Fs,Gs,Hs,Is],
| blocks(As, Bs, Cs), blocks(Ds, Es, Fs),
| blocks(Gs, Hs, Is). blocks([], [], []).
| blocks([N1,N2,N3|Ns1], [N4,N5,N6|Ns2], [N7,N8,N9|Ns3]) :-
| all_distinct([N1,N2,N3,N4,N5,N6,N7,N8,N9]),
| blocks(Ns1, Ns2, Ns3).
|
| I have yet to see more elegant code in a general purpose
| language.
|
| [3]: https://github.com/mthom/scryer-
| prolog/discussions/2347#disc...
| humanfromearth9 wrote:
| And I have yet to understand this.
| upghost wrote:
| Maybe watch the second link I posted?
| smarx007 wrote:
| Well, that's why language paradigms are a thing - if you
| are not familiar with any language in the logic paradigm
| but are an expert in the OO-paradigm, this could take a
| little bit to wrap your head around. Triska is an excellent
| teacher of Prolog, be sure to check out his videos linked.
| fifilura wrote:
| I am assuming it is a close relative to Norvigs solver
| https://norvig.com/sudoku.html
| javcasas wrote:
| My little pet peeve with prolog is the lack of context
| parameters (which can be thought as a type of abstraction).
|
| For example, imagine I'm writing a maze solver. The maze
| solver predicate receives obviously, but it has to pass as a
| parameter the maze again and again to all sub-predicates.
| There is no concept of "current maze", like in OO you would
| have with this.maze, or in Haskell you would do with a reader
| monad. As a result, all the "internal" predicates in a module
| get full of parameters all they do is pass around until some
| final predicate uses it to do some calculation.
|
| Either that or you do the assert/retract dance and now you
| have bigger problems.
| upghost wrote:
| There are multiple ways to accomplish this, but the one
| that is the most straightforward is to simply make an
| object mapping of the type you are familiar with via AVL
| trees[1]. Easy way to get the "this.maze" semantics. You
| can get global context and local context via
| "blackboard"[2] semantics.
|
| However quite frankly the most powerful way to do this is
| not obvious because it doesn't translate well to other
| languages: meta-interpreters[3].
|
| [1]: https://www.scryer.pl/assoc
|
| [2]: https://www.scryer.pl/iso_ext.html#bb_get/2
|
| [3]: https://youtu.be/nmBkU-l1zyc
| gergo_barany wrote:
| Could you elaborate on all of these?
|
| For [1], you would either need to pass the AVL tree
| around or to have it as a global (which is not wanted),
| and instead pass the key (the "this" context which is
| different for different mazes) for the context around.
|
| For [2] again you have a global table (with copying
| semantics as for assert/retract? or maybe without
| copying? the docs don't say). But again you would need to
| pass a key around.
|
| [3] is... yeah. I mean, sure, you could demonstrate this
| with a toy metainterpreter on a toy example. But do you
| really want to run your whole application inside a
| metainterpreter?
|
| One could also abuse DCG syntax, with the context being
| some state object instead of a DCG list.
|
| A more practical way would be Logtalk-like code
| generation. The most practical way would be actual
| Logtalk. Unfortunately, last I heard Scryer refused to
| host Logtalk for no real reason.
| tannhaeuser wrote:
| Quantum Prolog has this feature where you can query against
| a dynamic database, not just the global default database;
| ie. where in regular Prolog (and in Quantum Prolog as well
| of course since it's full ISO) you query
| p(a). p(b). ?- p(X)
|
| you can instead query KB = [ p(a), p(b)
| ], KB ?- p(X)
|
| introducing a clause-list as first parameter to "?-".
|
| In the description [1], this is used to avoid destructive
| database manipulation via assertz/retract builtins, and
| thus to allow much more complex combinatorial planning
| problems and action post-conditions to be solved/optimized
| without resorting to ad-hoc hacks. But you can also use
| this for mere convenience in large knowledge graphs, and a
| technique very similar to it, albeit implemented in Prolog
| itself and not provided with native speed, has been used as
| a historic extension to Prolog DCG parsing (cf. definite-
| clause translation grammars by Dahl et al).
|
| [1]: https://quantumprolog.sgml.net/container-planning-
| demo/part2...
| coliveira wrote:
| Yes, the OP is probably unaware of the recent advancements in
| Prolog. There is a set of techniques using pure Prolog that
| have made the language incredibly powerful compared to the
| techniques of the 80s and 80s. The more we use the abstract
| features of Prolog, the more powerful it becomes.
| wslh wrote:
| Look also to sudoku solvers in Z3: [0] also papers such as
| "Evaluating SAT and SMT Solvers on Large-Scale Sudoku
| Puzzles" [1].
|
| [0] https://github.com/grencez/grencez.dev/blob/trunk/2015/z3
| -so... [1] https://arxiv.org/pdf/2501.08569
| Horffupolde wrote:
| The thing with Prolog is that it's beautiful for solving very
| specific and well-defined combinatoric problems. Steer away
| and you hit a wall.
| billfruit wrote:
| 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 .
| rscho wrote:
| 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'.
| YeGoblynQueenne wrote:
| 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.
|
| "Very dumb theorem prover"!
| rscho wrote:
| " _Prolog is an efficient programming language because it
| is a very stupid theorem prover._ "
|
| -- Richard O'Keefe
| YeGoblynQueenne wrote:
| So what's that now? An appeal to authority?
|
| 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.
| rscho wrote:
| 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!
| YeGoblynQueenne wrote:
| 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?
| rscho wrote:
| 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'
| YeGoblynQueenne wrote:
| More like a fan than an expert but thanks for the
| compliment and sorry for yelling at you.
| jodrellblank wrote:
| 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.
|
| [1] https://www.swi-prolog.org/pldoc/man?section=clpfd
| "Author: Markus Triska"
| YeGoblynQueenne wrote:
| >> 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.
| jodrellblank wrote:
| > " _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).
|
| [1] for other readers, Mark Thom's Prolog-in-Rust to be a
| type inference engine for his Lisp-in-Rust:
| https://github.com/mthom/scryer-shen
| rscho wrote:
| Mark Thom's intention is implementing Shen. I guess it
| could count as a lisp and that's what you meant, but as
| lisps go, Shen is highly atypical.
| derdi wrote:
| > [...] might [...] might [...] might [...] might [...]
| might [...]
|
| 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".
| jodrellblank wrote:
| 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.
| derdi wrote:
| > 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.
|
| Fortunately, other Triska fans have got you covered with
| the standard talking points:
| https://news.ycombinator.com/item?id=42829782 ;-)
| LoneGeek wrote:
| A practical example: Void Linux installer implemented in
| GNU Prolog (https://github.com/sdbtools/void-pi).
| 2-3-7-43-1807 wrote:
| The declarative expression of the problem is elegant but even
| if this toy example is successfully resolved, make it a
| little more complicated and you'll have the interpreter ping-
| pong between two states infinitely.
|
| As I see it. Prolog as a language and idea is great but the
| existing solvers are useless for any real problem ... or
| you'll have to resort to cuts and memorizing states and at
| least partially implement an imperative solution that you
| yourself have to come up with. And that's totally killing the
| magic.
| rscho wrote:
| Well, I mean... Prolog is an implementation of 1st order
| logic with syntax sugar. So basically, Prolog is
| _incredible_ if your problem can be expressed within the
| framework, but less so if it can 't. That's pretty much why
| there were extension attempts such as lambda Prolog.
| 2-3-7-43-1807 wrote:
| you're simplifying the practicalities of prolog. there
| are many problems that you can express declaratively to
| the t. and yet many (all?) solvers aren't able to reduce
| it to a solution. the search isn't even successfully
| brute forcing - it will get stuck in some branch and
| switch endlessly between its leafs. and then it's up to
| you to figure that out and help the solver. even then
| prolog has its value but it fails at delivering the
| primary promise: you describe the problem, it finds a
| solution.
| YeGoblynQueenne wrote:
| That's the oldest complaint in the book about Prolog:
| "it's not 100% declarative". OK. So use Java. Or C. You
| think you'll have more declarative fun writing a Zebra
| Puzzle solver in C, than in Prolog? Be my guest.
|
| No, the truth is that Prolog is a unique language that is
| almost perfectly poised between the two extremes of
| beautiful but unusable formal purity and everyday
| programming utility. Prolog makes pragmatic choices when
| it has to and chooses to sacrifice declarative purity for
| the sake of performance and usability, because that's the
| only thing that makes sense considering that we have to
| run our programs on real computers, programmed by real
| programmers.
|
| And then people complain that it's no good because you
| can't write a solver in a purely declarative form, even
| though you can't even get close to the declarative
| features of Prolog in most other languages; except ASP,
| which is so declaratively pure that it doesn't even have
| lists.
|
| That's just a very poor criticism, poorly thought out and
| really meaningless in practice.
| 2-3-7-43-1807 wrote:
| my criticism cuts to the chase. that's why you write such
| a lengthy rebuttal. cause it hurts your feelings.
|
| > So use Java. Or C. You think you'll have more
| declarative fun writing a Zebra Puzzle solver in C, than
| in Prolog?
|
| and that, my dear friendo, is _whataboutism_!
| rscho wrote:
| I'd say Prolog delivers in a (relatively wide) subset of
| its domain of application. For instance, I'm writing a
| solver for some common issues in epidemiology, at the
| moment. I was able to write a fully declarative (and
| purely relational) solution! But yes, some applications
| are better suited than others.
| GregDavidson wrote:
| Prolog predicates are not first class values. Data structures
| are not abstract. Compare both with any modern lisp or better
| with functional languages. Mapping and filtering is awkward.
| Arithmetic is awkward. Indexing and search strategies are not
| under programmer control. Modes are awkward. Cut and dynamic
| assert of global facts are abominations which undermine
| logical reasoning. Prolog programmers often write
| metacircular interpreters to fix these problems which is
| wonderfully easy but kills efficiency. The CLP examples
| aren't integrated with Prolog's Horn clause resolution model,
| they're just libraries with strange semantics. I've been an
| enthusiastic Prolog programmer since the mid 1980s, attended
| lots of conferences, read lots of papers, etc. There have
| been many promising attempts to fix these problems but
| they've only shown up as non-standard features in specific
| implementations. It's similar to the "curse of Lisp" -
| everyone does their own thing and no consensus emerges to
| move the standard forward. But it could be worse if the
| standard were "feature oriented" rather than eliminating the
| limitations and flaws by cleanly generalizing the model. I
| study new logic programming languages avidly hoping to see a
| worthy successor to Prolog. So far none quite make it.
| Mercury might do it if it got more love.
| bmacho wrote:
| > There have been many promising attempts to fix these
| problems but they've only shown up as non-standard features
| in specific implementations. It's similar to the "curse of
| Lisp" - everyone does their own thing and no consensus
| emerges to move the standard forward.
|
| > But it could be worse if the standard were "feature
| oriented" rather than eliminating the limitations and flaws
| by cleanly generalizing the model.
|
| Why do you feel that "eliminating the limitations" is the
| way forward, and not standardizing common tasks instead,
| making them ergonomic, uniform, _fast_?
|
| I don't think that more power can lead to those. Maybe
| ergonomics and uniformity can happen by accident if a
| library emerges as the default option for a task, but
| speed, I don't think it can.
| rscho wrote:
| How does MiniKanren fix some limitations? MiniKanren
| corresponds to the purely relational subset of Prolog.
| GregDavidson wrote:
| By allowing you to use the features of the host language to
| complement the features of miniKanren. Having good support
| for multiple programming paradigms is better than trying to
| make one paradigm fit all needs. Poplog[1] was an earlier
| attempt to provide such synergies but it failed to gain
| market share. It's now free software so take a look! The
| Racket ecosystem is another approach where each module can
| choose a language with some of them being Prolog-like[2]. [1]
| https://en.m.wikipedia.org/wiki/Poplog [2] https://racket-
| lang.org/languages.html
| rscho wrote:
| Ok, but MiniKanren isn't intrinsic to Scheme. I agree
| Racket makes it especially easy to embed sub languages, but
| you could embed core relational Prolog just as well as
| MiniKanren. My understanding of your statement is that
| Scheme and MiniKanren share sexp syntax, but the same
| applies: you could embed an sexp-based Prolog just as well.
| The only remaining MiniKanren advantage is then to have a
| complete search strategy, this I concede.
| lionkor wrote:
| How can I use Prolog to actually get something done, other than
| academic tasks?
|
| Say I want to use it as a database query language, presumably
| that's not going to happen, right?
| vixen99 wrote:
| Ditto!
| aktuel wrote:
| There you go: https://github.com/aarroyoc/postgresql-prolog
| Twey wrote:
| In a sense, Prolog _is_ a database query language. The base
| facts in Prolog are equivalent to the rows of a table. You can
| also 'table' predicates with variables (over a finite subset of
| values) by memoizing the results.
| tgamblin wrote:
| > Datalog is a declarative logic programming language. While it
| is syntactically a subset of Prolog, Datalog generally uses a
| bottom-up rather than top-down evaluation model. This
| difference yields significantly different behavior and
| properties from Prolog. It is often used as a query language
| for deductive databases.
|
| https://en.m.wikipedia.org/wiki/Datalog
| 2-3-7-43-1807 wrote:
| do you know what you are writing about? I mean have you
| actually done something with datalog? and then _which_
| datalog? if yes, then you are probably someone working with
| it academically or the answer is no. because try to even set
| a toy project up with it (for the purpose of learning how to
| use it) and you'll quickly run into unmaintained
| interpreters, discussions of what datalog is and what not and
| you can choose between difficult to understand academic
| papers or simplistic introductions that lead you no where.
| UltraSane wrote:
| Have you tried Datomic?
| 2-3-7-43-1807 wrote:
| no.
|
| https://github.com/Datomic/codeq : last update to that
| repo was 12 years ago.
|
| it's JDK which I find unappealing.
|
| also, how close is it to Datalog?
|
| https://github.com/gns24/pydatomic : last update 11 years
| ago.
|
| and that's representative of pretty much anything
| regarding Datalog.
|
| So, I'll just stick to Prolog then.
|
| ---
|
| have you?
|
| would you recommend it?
| upghost wrote:
| No, unless you count cancer research[1], particle physics
| experiments[2], and government funding allocations[3].
|
| [1]: https://dcnorris.github.io/precautionary/index.html
|
| [2]: https://github.com/mthom/scryer-prolog/discussions/2441
|
| [3]:
| https://link.springer.com/chapter/10.1007/978-981-97-2300-3_...
|
| Regarding how, check out Power of Prolog on YouTube.
| smarx007 wrote:
| + https://sicstus.sics.se/customers.html
| kevindamm wrote:
| Consider also checking out Datomic, though technically it's
| datalog not prolog, and not for connecting to your already-in-
| use SQL system, but it is a good example of taking the
| expressive power of logic programming to interface with a
| database.
| kevindamm wrote:
| EDIT: (too late to edit above)
|
| s/logic programming/relational programming/
|
| it isn't as expressive as LP or CLP and works best embedded
| in a functional-biased language
| LoneGeek wrote:
| For example: Void Linux installer implemented in GNU Prolog
| (https://github.com/sdbtools/void-pi).
| brabel wrote:
| > The reverse predicate from this section should not be used in
| practice - most Prolog implementations actually provide a built-
| in version which is a lot more performant than our
| implementation.
|
| That feels like cheating. If you shouldn't use the implementation
| shown, then why do you even show it? Let us see the performant
| version!
|
| That's like Haskell's quickSort implementation in a couple of
| lines... beautiful but horrendously non-performant as it doesn't
| actually implement the algorithm, it just implements the "idea"
| (while losing all the performance of the actual algorithm, which
| requires in-place mutation).
| derdi wrote:
| No built-in is needed for an efficient reverse. It's just one
| or two lines longer because you need to write a tail-recursive
| helper with an accumulator, same as in functional languages:
| https://stackoverflow.com/a/74777180
| aktuel wrote:
| I started learning prolog just a few months ago, when I stumbled
| upon https://linusakesson.net/dialog/ which is a spin on prolog
| optimized for writing interactive fiction.
|
| As a sweet and short tutorial I can recommend these slides:
| https://www.cs.toronto.edu/~hojjat/384w10/
|
| If you want to dive into how Prolog works under the hood I can
| recommend https://github.com/a-yiorgos/wambook
|
| I terms of Prolog implementations I played a bit with
| https://www.scryer.pl but it still feels rough around the edges.
|
| SWI-Prolog is the most popular and most batteries included
| Prolog: https://www.swi-prolog.org With its libraries and
| documentation it is a very practical language. What surprised me
| is, that you can easily produce amazingly small stand-alone
| binaries.
| 0x3444ac53 wrote:
| I read about dialog in another HN thread a few weeks ago.
| Between then and now I've had the itch to write some
| interactive fiction, but I could not for the life of me
| remember the name of that project.
|
| Thanks!
| upghost wrote:
| I always enjoy reading positive pieces about Prolog but without
| touching on the implications of the principles on display, this
| article may do more harm than good.
|
| You would ask reasonable questions like, "for God's sake, _why_?
| ". It feels like you wouldn't use Prolog for anything besides an
| intellectual game.
|
| Regarding the _why_ :
|
| Some of those reasons include Definite Clause Grammars, Meta-
| Interpreters, 1st class constraint logic programming, reified
| conditionals, and term/goal expansion.
|
| There are a lot of exciting modern advances with Prolog,
| especially Scryer Prolog.
|
| Check out Power of Prolog and get your mind blown:
| https://youtube.com/@thepowerofprolog
| agumonkey wrote:
| one example that changed my view of prolog was
| http://faculty.cooper.edu/smyth/cs225/ch7/prolog.htm (a toy
| compiler in prolog)
| coliveira wrote:
| And this is nothing new. People already knew how to write
| compilers in Prolog (easily) in the 90s. The problem with
| Prolog is that it requires a change in the way you think
| about problems, to a more declarative way. Programmers are in
| general not willing to do this since the result will be not
| as performant as what they can do with C. There must be a
| revolution in programming education and tools before people
| fully understand how Prolog works.
| agumonkey wrote:
| yeah yeah i got that too after a while, which is also why i
| like non mainstream programming languages, after a while
| you're tired writing more versions of the same
| routines/procedures/methods that won't help you find better
| solutions
| ParticlesRWaves wrote:
| Am I the only who finds this article to be inaccessible due to
| color choices and implementation?
|
| I'm really interested in Prolog, but my eyes feel the strain
| after a few sentences. The reason is that the contrast ratio of
| some parts is very low, of others excessively high. The constant
| alternations between these extremes intensifies the effect.
|
| The page looks shredded in Safaris reader mode, so that's no help
| either.
| 3willows wrote:
| Love the links to SWISH playground: really got me to want to try
| it out!
| jfmc wrote:
| Other playground (wasm based): https://ciao-lang.org/playground
| fifilura wrote:
| Having used Trino/Athena and BigQuery extensively, I am curious
| about the state of parallelism in the available prolog
| implementations.
|
| Being able to push the calculations to CUDA or the google/AWS
| "cluster" feels like it could be the game changer for a system
| like this.
|
| The declarative nature of the language should leave any
| imperative implementation far behind when it comes to complex
| calculations.
| tannhaeuser wrote:
| Indeed. Not using CUDA but Quantum Prolog has parallel maplist
| and co [1], and the article also contains a short overview and
| brief comparison with other approaches, including a short
| discussion of imperative implementations like SWI's (historic?)
| threading package. Discussion is necessarily limited to that
| particular workload since parallel Prolog has a long history
| dating back to the 1990s (the book "Past, Present, Parallel"
| was an early survey at the time and already contains tens of
| approaches/academic implementations).
|
| [1]: https://quantumprolog.sgml.net/bioinformatics-
| demo/part2.htm...
| titanomachy wrote:
| I liked the authorization example. I've encountered Prolog
| articles before, but showing the code alongside an OOP
| implementation was a nice demonstration of its expressive power.
|
| As a follow-up, I'd love to learn how this auth system could be
| put into production. In this example, authorization rules are
| provided in the code (`user_role(mike, supervisor)`) and queried
| similarly. What if I wanted this system to expose authorization
| as an HTTP endpoint with REST semantics, and store authorization
| rules on disk? Would this be straightforward, involved, or
| impossible? Would I use another language for HTTP, and query a
| prolog "server" running on the same machine?
| rscho wrote:
| https://github.com/Anniepoo/swiplwebtut/blob/master/web.adoc
| derdi wrote:
| > What if I wanted this system to expose authorization as an
| HTTP endpoint with REST semantics, and store authorization
| rules on disk? Would this be straightforward, involved, or
| impossible?
|
| Straightforward. Prolog supports self-modifying code. You can
| mark the user_role predicate as "dynamic", i.e., modifiable. At
| runtime you can then read rules from disk or receive them via
| HTTP or construct them based on some other form of input, and
| add them to the code, or remove them as needed.
|
| The HTTP part is not standardized; you would need to use
| libraries specific to some concrete implementation. But the
| libraries exist.
| axefrog wrote:
| Fun fact: A large portion of TerminusDB's codebase is written in
| Prolog. https://github.com/terminusdb
| Guthur wrote:
| It's actually quite pleasing to see much health debate in these
| comments. Shows life in this amazingly powerful language.
___________________________________________________________________
(page generated 2025-01-26 23:01 UTC)