Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Simplicity of Prolog

bitsandtheorems.com

Post reply on HN
Print view View original

81–90 of 134 posts

Re: The Simplicity of Prolog

#81

Post by 2-3-7-43-1807 »

UltraSane wrote: post #70
2-3-7-43-1807 wrote: post #44

Earlier quoted context omitted.

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 b…

Have you tried Datomic?

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?

Re: The Simplicity of Prolog

#82

Post by jodrellblank »

YeGoblynQueenne wrote: post #53
jodrellblank wrote: post #50

Earlier quoted context omitted.

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…

>> 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 do…

> "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

Re: The Simplicity of Prolog

#83

Post by derdi »

jodrellblank wrote: post #76
derdi wrote: post #55

Earlier quoted context omitted.

> [...] 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 t…

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 t…

> 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 ;-)

Re: The Simplicity of Prolog

#84

Post by derdi »

titanomachy wrote: post #69

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…

> 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.

Re: The Simplicity of Prolog

#85

Post by andrewflnr »

ramses0 wrote: post #66
anonzzzies wrote: post #3

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 fo…

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 i…

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.

Re: The Simplicity of Prolog

#86

Post by LoneGeek »

lionkor wrote: post #11

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?

For example: Void Linux installer implemented in GNU Prolog (https://github.com/sdbtools/void-pi).

Re: The Simplicity of Prolog

#87

Post by LoneGeek »

jodrellblank wrote: post #76
derdi wrote: post #55

Earlier quoted context omitted.

> [...] 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 t…

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 t…

A practical example: Void Linux installer implemented in GNU Prolog (https://github.com/sdbtools/void-pi).

Re: The Simplicity of Prolog

#88

Post by rscho »

jodrellblank wrote: post #82
YeGoblynQueenne wrote: post #53

Earlier quoted context omitted.

>> 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 do…

> " 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 Pr…

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.

Re: The Simplicity of Prolog

#90

Post by bmacho »

GregDavidson wrote: post #73
upghost wrote: post #23

Earlier quoted context omitted.

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://yout…

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 metaci…

> 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.

Post reply on HN