Re: [GSoC] Proposal: Modular LilyPond Parser (C++)

Dan Eble <[email protected]> writes:

> It's not clear to me what "this way" is or in what sense the syntax is
> currently unstable; however, that shouldn't be too surprising since
> there is approximately one person who understands most of the current
> language processing, and probably a couple of others who probably
> understand a large part of it, and I'm not one of them.

As a note aside: I hate that kind of choke point.  I've tried my best to
keep things documented as I go.  The state of things is that the
complexity of the inner parser workings has gone up in the last decade
or two of development: you needed a Bison-affine hacker to deal with it
before.  You now need a pretty solid Bison-affine hacker.

On the plus side, the number of people who can contribute functionality
effectively for dealing with tasks in a manner taking reasonably
natural-looking input has grown by several numbers of magnitude, and you
can do wagonloads more without even recompiling LilyPond.

Overall, the tradeoff has worked pretty well I think.  There may be a
point in converting LilyPond's parser to a GLS type parser in order to
hide much more of the complexity of ambiguity resolution from the
programmers dealing with LilyPond.  The problem is that this makes it
much easier to introduce ambiguities by accident into the language that
are as hard to resolve for parsers as they are for humans, and when that
happens, users may increasingly be flabbergasted by some resolutions (or
non-resolutions) the parser ends up picking.

-- 
David Kastrup