Re: GOP2-3 - GLISS or not

[David Kastrup]

Joseph Rushton Wakeling <address@hidden> writes:

> On 24/07/12 10:09, Graham Percival wrote:
>> Let’s decide whether to try to stabilize the syntax or not. What
>> type of project do we want LilyPond to be? What kinds of
>> guarantees (or at least firm intentions) do we want to give to
>> users with respect to lilypond 2 or 5 years from now being able to
>> read their current ly files?
>
> As a first step, surely it's important to understand what are the
> typical sources of conversion problems, i.e. what kind of syntax
> changes can convert-ly not deal with?
>
> It seems to me that \override statements and custom-written Scheme
> inherently come with a "may break in future" health warning
> (especially the latter).  I don't think improvements to the language
> should be held back for the sake of such explicit departures from
> default behaviour.
>
>> Given that, LilyPond is not suitable as an archival format for
>> music.
>
> That surely depends on whether your archive can also maintain earlier
> versions of LilyPond to compile its older files with.

And earlier versions of GCC to compile its older LilyPond versions
with.

> How feasible is it for LilyPond to support a deprecation mechanism for
> syntax? E.g. so that when compiling you might get an error message,
>
>     [such-and-such a syntax element] is deprecated syntax that will be
>     removed from a future version of LilyPond.  Use [new syntax]
>     instead.

At some time, it will be removed or the warning is pointless.  So this
will not address the topic of bitrot for large mostly dormant bodies of
music like Mutopia satisfactorily.

> Or alternatively, to simply maintain in LP the previous syntax as a
> separate option, so that for example
>
>     lilypond file.ly                  -- uses the current standard syntax
>     lilypond --deprecated file.ly     -- uses the previous syntax

If it was simply...

> My overall feeling on this is that while there are areas of "standard"
> modern musical notation
> [e.g. https://code.google.com/p/lilypond/issues/detail?id=1278 ] that
> aren't supported by LilyPond, it's difficult to guarantee syntax
> stability.  So perhaps a first step is to define the subset of
> _musical_ notation that you want to provide stable support for.

Sounds to me like that was what Graham proposed in the first place.

-- 
David Kastrup