3 ms·
> Prolog also requires you to understand the execution model before you can do much of anything. This is true of most (all?) languages. Prolog's control flow i
by discarded1023 3y ago
> Prolog also requires you to understand the execution model before you can do much of anything.
This is true of most (all?) languages. Prolog's control flow is ultimately not too different from the usual stack-based semantics people are used to from imperative languages like C (if you're not too ambitious with the backtracking; if you are, best of luck!). The tricky part is perhaps understanding the dataflow that arises from unification. That can be arbitrarily complex but it seems people tend to go no further than difference structures, which are easy to comprehend in terms of pointers. (Yes yes I know, but logic variables are essentially just single-assignment pointers.)
The thing I find deeply weird about the logic programming literature is that if you want to reason about your program you're told to use things like Hoare logic [1] or intended interpretations [2] and not fundamental logical concepts like implementations implying specifications (ala Lamport and many others who grappled with refinement).
[1] see Krzysztof Apt's papers
[2] see e.g. https://people.eng.unimelb.edu.au/lee/papers/dd.html https://people.eng.unimelb.edu.au/lee/papers/dd.html
- usgroup 3y ago> This is true of most (all?) languages. Well no, I’d go as far as to say that your average JS/Python dev will know very little about how their code is executed — and doesn’t need to know necessarily. SQL on the other hand is a different story . Noobs don’t know , but pros know and consider the execution graph of a query. You don’t really have a choice in Prolog —- gotta know what the interpreter is doing from the beginning otherwise you can’t debug.
- felixyz 3y agoIt't just that everyone has the execution model of imperative languages so internalized, we mostly don't think about it. Same with OO semantics, not to mention various JS pitfalls - they are second nature to enough people that they count as nature-given, but one false move and they come back to bite you.
- convolvatron 3y agoIt’s worth pointing out that the semantics of prodcedural programs tend to be pairwise, while coaxing the prolog solver to terminate is a more global, transitive problem
- discarded1023 3y agoI don't disagree with your stance but one of the most beautiful things to come from this line of work was Ehud Shapiro's declarative debugging [1]. I'd recommend taking a look at his PhD thesis if you're at all interested in what logic programming can do (that nothing else can [2]). You can also see it as a philosophical exercise: he shows how we might understand Popper's falsification criterion and use it to do science. [1] Tech report: https://cpsc.yale.edu/sites/default/files/files/tr237.pdf https://cpsc.yale.edu/sites/default/files/files/tr237.pdf [2] There have been attempts to build declarative debuggers for other languages but for one reason or another (complexity, space use, incomplete coverage of the language, ...) they don't appear to get used very widely. Shapiro's setup is beautifully simple for what it does. Here "declarative" means that you have a model in mind ("model" in the sense of logic, i.e., you expect your predicates to hold of particular arguments) and the tool helps you explore the divergence between what you wrote and what you intended. Thinking this way means you can completely ignore the details of SLD-NF resolution (the details of the Prolog implementation)... I mean, it's unlikely to be perfect in practice for any number of reasons, but I find it very disappointing that we don't dream like this any more.
- usgroup 3y agoThank you — this is a nice find.
- chriswarbo 3y agoI disagree. A JS/Python developer will have no problem understanding the following example, which makes absolutely no sense without some (operational) semantic model of the code: x = x + 1