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

Carl Sorensen <[email protected]> writes:

> %%%
> \version "2.24"
>
> \new Staff <<
>     \time 6/8
>     \new Voice {\voiceOne a'1 b'1 c''1}
>     \new Voice {\voiceTwo d'1 e'1 f'1}
>>>
> %%%
>
> Furthermore, there are a range of different possible arguments to the \time
> command; your preliminary specification is incomplete, although I don't
> know enough about the proposed specification to know if that's planned for
> being fixed.
>
> It appears to me that you are proposing to replace an intentionally
> flexible (and therefore complex) lexer with a simplified lexer that will
> not have the same flexibility.
>
> The flexibility in LilyPond is one of its greatest assets -- it allows the
> engraving of music that wasn't explicitly planned for (AFAICT) in the
> original design; but because of the flexibility inherent in the lexer the
> types of music to be engraved can be readily expanded.
>
> I do not believe there will be a lot of support in the LilyPond community
> for decreasing the flexibility of the lexer.

It depends on what you call "the lexer".  I don't really see LilyPond's
own lexer and particularly its parser getting replaced by significantly
differently working code: semantic tie-ins, particularly when parsing
music functions that can be defined by the user, are not going away.

LilyPond's syntax is too unconstrained to work independently of
semantics.  I am partly responsible for the current scope of
flexibility, but music function parsing with variable types and numbers
of arguments was a thing before I dug in and worked on making the parser
both much more powerful and simpler to use (and less maintainer-friendly
in spite of best efforts and adding quite a lot of comments).

At the same time, syntax highlighters, formatters, IDEs and so on need
fast parsing (in some cases incremental) that works with reasonable
heuristics and fairly robustly on code formatted in reasonably standard
manner and using a good subset of features.

That is a tradeoff, and there is a place for other parser
implementations within that tradeoff

-- 
David Kastrup