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

61–70 of 134 posts

Re: The Simplicity of Prolog

#61

Post by gergo_barany »

upghost wrote: post #34
javcasas wrote: post #29

Earlier quoted context omitted.

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

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

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.

Re: The Simplicity of Prolog

#62

Post by kevindamm »

kevindamm wrote: post #39
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?

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.

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

Re: The Simplicity of Prolog

#63

Post by YeGoblynQueenne »

2-3-7-43-1807 wrote: post #59
rscho wrote: post #47

Earlier quoted context omitted.

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.

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…

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.

Re: The Simplicity of Prolog

#64

Post by rscho »

YeGoblynQueenne wrote: post #60
rscho wrote: post #58

Earlier quoted context omitted.

Not an appeal to authority. Just showing that quote wasn't of my invention. I don't really get why you're so riled up. I'm not saying SLD resolution is dumb, just that Prolog stays simple by not including all the clever heuristics and circumstantial techniques of other solvers. Which is a big part of what makes Prolog a nice programming language. It's more a compliment than a critic, really!

I'm not riled up, I even upvoted your OP, but it's uncouth to drop a quote without any context as a reply to a comment. Of course there's going to be misunderstandings. I didn't remember that quote from O'Keefe. Prolog is indeed not trying to be smart and SLD-Resolution is dead simple - it's a sound and complete deductive inference system with a single rule. The reason Prolog is in turn so simple is because, thanks t…

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'

Re: The Simplicity of Prolog

#65

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

YeGoblynQueenne wrote: post #63
2-3-7-43-1807 wrote: post #59

Earlier quoted context omitted.

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…

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

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_!

Re: The Simplicity of Prolog

#66

Post by ramses0 »

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

Re: The Simplicity of Prolog

#67

Post by rscho »

2-3-7-43-1807 wrote: post #59
rscho wrote: post #47

Earlier quoted context omitted.

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.

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…

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.

Re: The Simplicity of Prolog

#68

Post by rscho »

GregDavidson wrote: post #7

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

How does MiniKanren fix some limitations? MiniKanren corresponds to the purely relational subset of Prolog.

Re: The Simplicity of Prolog

#69

Post by titanomachy »

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?

Re: The Simplicity of Prolog

#70

Post by UltraSane »

2-3-7-43-1807 wrote: post #44
tgamblin wrote: post #19

Earlier quoted context omitted.

> 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

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?
Post reply on HN