Re: GOP2-3 - GLISS or not

[Nicolas Sceaux]

Le 24 juil. 2012 à 11:09, Graham Percival a écrit :

> ** 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. If you do it too late, then there’s a large body of
> documents in the pre-stabilized version which will require
> updating before they run in the stabilized version.
> 
> I see two options:
> 
> 1. No stability: we go back to the way things worked a few
>     years ago. When a programmer wants to change something, he
>     changes the code and maybe adds a convert-ly rule if it’s
>     convenient to do so, otherwise just adds a warning to the
>     NEWS. I stop telling people “no, don’t change the syntax,
>     and don’t even talk about changing the syntax”.
> 
> 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. 

Hi,

As a maintainer of 100+ Mbytes of LilyPond files, I'm very interested
in this topic.

IMHO, we should aim at stabilizing what is currently hardcoded in the
lexer and parser (notes, file structure...).  Nowadays, only David works
in this area, he has the best expertise on the subject, and he probably
knows what best should be done.

As for the name and semantics of builtin shortcuts, music functions,
markup commands, they'd also be best stabilized in name, signature and
semantics, across stable releases.  The long discussed subjects, like
tuplets (which should cause no problem for convert-ly), should be sorted
out, as you suggest. 

But the name and semantics of grob or context properties and the like
shall not be frozen, even though writing convert-ly rules for them is
often problematic.  This is the area where there are the more changes,
and for a reason: this is where you can reach and change typesetting
functionalities.
[A good LilyPond writing rule is to avoid using \override:s everywhere
in ly files, but to define a music function which in turn calls the override,
to ease conversion.]

I don't see how LilyPond files could be converted automatically, without
loss or deterioration, because of their complexity as soon as scheme
extensions are involved.  However, if we have a toolkit which allows:
ly-file 'A.ly' -> PDF file 'A.pdf'
ly-file 'A.ly' -> MusicXML-file -> ly-file 'B.ly' -> PDF file 'B.pdf'
where A.pdf and B.pdf are identical, (even though A.ly and B.ly are not)
then a part of the problem is solved.
(I have no clue if this is possible).

Nicolas