Re: GOP2-3 - GLISS or not

[Joseph Rushton Wakeling]

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.

> It can produce a great pdf when you first write the file,
> but the .ly files require regular maintenance if you want them to
> compile in the latest stable version of lilypond.

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.

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

... so that either way you'd always have a means of compiling a LP file from the 
previous syntax version, but you'd also have a clear warning of where 
maintenance was required.

This way you could build in a deprecation cycle for syntax changes which would 
minimize their impact.

> This is a problem for projects such as mutopia – a large fraction of their
> .ly files don’t compile with current lilypond.

If that's already the case, then it shouldn't block further syntax changes _now_ 
if they are useful and the syntax can be stabilized on the basis of these changes.

> On a personal note, this is one of the biggest reasons I’ve given
> up on using lilypond personally. From 2001 to 2004 I got a minor
> in music composition. I carefully kept all my .ly files but
> foolishly did not preserve the pdfs. And now, 10 years later, I’m
> left with a bunch of music that I cannot generate sheet music for.
> Manually updating the .ly files would take hours or days; I’ve
> started this process a few times but always lost interest after a
> few files, since there’s no guarantee that I wouldn’t need to go
> through the same process in another few years.

FWIW this is still a better archival status than Finale/Sibelius.  In fact from 
what I recall, typical practice of professional engravers with these packages is 
to use the music software to produce a basic layout which they'd then tweak 
further in Adobe Illustrator.  So the PDF/PostScript version would be the _only_ 
reliable archival copy.

> My personal preference is to stabilize a subset. It won’t solve
> all the user problems with manually updating ly files, but it
> would be a step in the right direction. If the process goes well,
> then we can have additional rounds of stabilization where we
> expand the stable subset.

This seems like a good basic policy, but why not add the following caveat -- 
have a large test suite of different cases, including full scores provided by 
users (e.g. the whole Mutopia archive?), and allow syntax changes even to the 
subset if there is both a strong technical justification _and_ the developer can 
provide a convert-ly rule which demonstrably works across the whole test suite?

After all, a breaking syntax change is only bad if it _can't_ automatically be 
fixed.

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.