Re: Overloading and extending operators, (l)PEGs and grammars

[Peter Odding <xolox@...>]

Sam Roberts wrote:
> I can appreciate how difficult it is to make a small language with flexible
> operator extensions. Its too bad, things like lpeg could benefit from it.
> 
> With lpeg, we have:
> ...
> There isn't any commonality here, I find it quite anti-mnemonic (all the
> operators are used for different purposes than in the original PEG grammars). I
> can't read a PEG without the table above taped to my monitor.

Contrary to your experience with LPeg's operators I've found them rather
intuitive. It took me a *whole lot* longer to grok regex than it took to learn
LPeg. Though of course if your already familiar with regex then LPeg is not that
difficult, apart from memorizing the operators. For the archives and others
reading this thread (as I'm pretty sure Sam knows this), I believe these
operators were chosen primarily because of their precedence.

> I have mixed feelings about (ab)using operator overloading to support inline
> expression of grammars. I can see the appeal to somehow add grammars as
> elements of the language, rather than strings, but strings aren't so hard to
> use, and are fairly flexible.

One notable advantage to inline grammar expression (IMO) is that you get error
messages while composing your pattern, as opposed to embedding the grammar in a
string, passing that as an argument and receiving an error after that string has
been interpreted (20 lines down from it's composition). The flipside to this is
that if you write a wrapper function for LPeg you can get error messages from
inside that wrapper instead of it's invocation.

 - Peter Odding