Comment by PaulHoule | Hacker News Reader

Comment by PaulHoule | Hacker News Reader

Parent Full thread

I am thinking about this sort of thing

https://en.wikipedia.org/wiki/OPS5 https://en.wikipedia.org/wiki/IBM_Operational_Decision_Manag...

Inform 7 has a very primitive rules engine and (to me) a very interesting model in which defaults and the overriding of defaults is a major strategy of control. For instance the default response to you typing in a command is basically

   printf("huh?\n")

and then the commands you can type in are defined in terms of exceptions to that rule, exceptions to those exceptions and so forth.

I tried to write a text adventure in Drools in a way inspired by Inform 7 and got to the 30% mark of a demo, I was convinced it was possible but that it wasn't for me because I couldn't make head or tail of the error messages I was getting because Drools syntax is an unholy mixture of the host language (Java) plus Drools-specific constructions. (One reason we can't have good things in programming languages is that we're still using your father's parser generators.)

(The other time I wrote something unconventional with production rules, which was the control plane for a stream processing engine, I had no trouble coding it and little trouble with the error messages because I could read and understand the source code for the Jena Rules Engines... That didn't stop the Jena maintainers from telling me that my use case was unsupported.)

It's sad that production rules became unfashionable when Duran Duran did because between the RETE algorithm, improvements on the RETE algorithm, and keeping rules in a hash table, production rules engines have improved dramatically since "expert system shells".

> (One reason we can't have good things in programming languages is that we're still using your father's parser generators.)

I don't think it's the parsing technology that's the problem. It's that designing a good grammar is actually quite difficult. It's like doing UX design, API design, and mathematics all at the same time.

I'd respectfully disagree. Sometimes the grammar is already defined, already exists, and you just want to parse it. Sometimes you want to make a new grammar based on one that already exists, for instance:

- add an "unless(X) {}" statement equivalent to "if(!X) {}" to Java

- add a new SQL literal type to Java that compiles to something like JooQ; to make it easy lets use Unicode characters like « » to switch languages

- almost any programming language contains an expression language that could be lifted out and used independently of the real language and slotted into another grammar (think making something like Python's list comprehensions, a business rules language, Microsoft's LINQ with SQL-like syntax)

All of the above should be a few lines of code on top of existing grammars.

Existing parser generators are one way: if they were two way (can unparse as well) you'd be in good shape for code generation.

You should be able to write your grammar together with your AST objects easily (don't get me started about Yacc's callback hell interface.)

The one feature I want from yacc is a PEG parser where it's as easy to set operator precedence as it was in the early C language parser. (Ought to be possible by rewriting the grammar... In fact there are a handful of problems with PEG parsers that everybody agrees should be fixable but nobody gets around to it.)

... and yeah, compiler books still say "Writing parsers that give comprehensible error messages is hard" without giving you any guidance as to how to do it.

Text adventures are a different monster alltogether.

And the i7 compiler it's almost a simple English parser by itself.

you could go back to the original LISP

https://github.com/briangu/OPS5/blob/master/demo/ops-demo-ma...

The Jena Rules Engine isn't too different from that, that's why the source code is easy to read!

Reply on news.ycombinator.com