Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In university, Learning prolog was my first encounter with the idea that my IQ may not be as high as I thought


I also found it mindbending.

But some parts, like e.g. the cut operator is something I've copied several times over for various things. A couple of prototype parser generators for example - allowing backtracking, but using a cut to indicate when backtracking is an error can be quite helpful.


"Keep your exclamation points under control. You are allowed no more than two or three per 100,000 words of prose."

Elmore Leonard, on writing. But he might as well have been talking about the cut operator.

At uni I had assignments where we were simply not allowed to use it.


That may make sense for Prolog code - I don't know Prolog enough to say. But the places I like to use it, it significantly simplified code by letting me write grammars with more local and specific error reporting.

That is, instead of continuing to backtrack, I'd use a cut-like operator to say "if you backtrack past this, then the error is here, and btw. (optionally) here is a nicer error message".

This could of course alter semantics. E.g. if I had a rule "expr ::= (foo ! bar) | (foo baz), foo baz would never get satisfied, whereas with "expr ::= (foo bar) | (foo baz)" it could. (And in that example, it'd be totally inappropriate in my parser generator too)

I'm guessing the potential to have non-local effects on the semantics is why you'd consider it problematic in Prolog? I can see it would be problematic if the cut is hidden away from where it would affect you.

In my use, the grammar files would typically be a couple of hundred lines at most, and the grammar itself well understood, and it was used explicitly to throw an error, so you'd instantly know.

There are (at least) two ways of improving on that, which I didn't bother with: I could use it to say "push the error message and location" and pop those errors if a given subtree of the parse was optional. Or I could validate that these operators don't occur in rules that are used in certain ways.

But in practice in this use I never ended up with big enough code that it seemed worth it, and would happily litter the grammars with lots of them.


I used to use a cut operator about every 2 to 4 rules. If you are constantly using it as error handling, I would agree you are using it too often. If you are using it to turn sets into scalars or cells, then you are using it correctly. It just makes the code really hard to reason about and maintain.


I thoroughly enjoyed doing all the exercises. It was challenging and hence, fun!

I don't think I ever learned how it can be useful other than feeding the mind.


There was a time when the thinking was you can load all the facts into a prolog engine and it would replace experts like doctors and engineers - expert systems, it didn't work. Now its a curiosity


intro to quantum physics for me (which is only sophomore) I noped out of advanced math/physics at that point, luckily I did learn to code on my own




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: