[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP2-3 - GLISS or not

From: David Kastrup
Subject: Re: GOP2-3 - GLISS or not
Date: Thu, 26 Jul 2012 17:50:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

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

> 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                  -- uses the current standard syntax
>     lilypond --deprecated     -- 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. ] 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]