Re: GOP2-3 - GLISS or not

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> Graham Percival wrote Tuesday, July 24, 2012 10:09 AM
>
>> ** Summary
>> 
>> Let’s decide whether to try to stabilize the syntax or not.
>
> We /should/ try to stabilize the syntax, but trying to do this
> at exactly the time when David is straightening out the
> parser seems a bad idea.

To be fair, it is not likely that David will stop "straightening out the
parser" anytime soon.

One problem with "straightening out" the parser, however, is that it is
very much guided by remaining upwards compatible, and that individual
changes breaking upward compatibility are hard to argue on their own
merits.

So the trend is to resolve ambiguities by adding complexity.  That
avoids compatibility issues for the time being.  However, it means that
the same amount of complexity for resolving ambiguities would need to
get applied by convert-ly, text editors with syntax support for
LilyPond, and tools importing LilyPond, all of which is not realistic.
So the price of LilyPond retaining the ability to process almost
anything it was able to process before and calling that the de facto
standard is that everybody else gives up on LilyPond as a music
description language.

It also means that the moving target for full anecdotal backward
compatibility (try supporting anything that may have worked at some
point of time) gets more horrific the longer this goes on.

> As yet we do not know where the parser changes may lead eventually.

Well, the expectation in the medium range is to solidify on music
functions, and have a mechanism where there is just one kind of them,
and just one kind of argument parsing.

>> ** Stability or not?
>> 
>> Stabilizing a language is a tricky process. If you do it too
>> early, then you’re stuck with whatever mistakes or poor design
>> decisions.
>
> Exactly.  We should wait until David's parser changes settle out.

Again: this is not going to happen anytime soon, and even if we are
postulating that I am the only one working on the changes, they need to
fit with some direction.  At the current point of time, I am more or
less factually dictator of the lexer/parser since a statement "this is
not doable" from me will go uncontested.

But the path of least resistance is a path where lots of mostly
historical ambiguities, partly due to arbitrary design choices, get
resolved with a considerable involvement of complexity.

And defining the whole of what will compile at a current point of time
as an archive language does not really work.

>> 2. Define a subset of input as being stable for the 3.x branch.
>>     We add regression tests for that subset of notation and
>>     forbid running convert-ly on those files. At the moment, I
>>     imagine that the subset would consist of at most Notation
>>     sections 1.1 Pitches, 1.2 Rhythms, and the overall file
>>     organization; nothing else.  Changes to input other than that
>>     subset are fine. 
>
> I'd be happy to see a start being made on this now, in spite of my
> comments above, but we must delay the actual release of the definitive
> syntax-stable version until we have confidence the parser changes have
> stabilized.  The task David has set himself is difficult enough
> without his being hamstrung by a premature release imposing further
> constraints on the parser.  Predicting the effect those constraints
> might have on the parser is pretty well impossible.

It has to be said that at the current point of time the main challenge
in lexer/parser work is in the _lack_ of constraints.

-- 
David Kastrup