Re: Lilypond Syntax Development and 3.0

[Carl Sorensen]

On 7/27/09 4:22 AM, "Graham Percival" <address@hidden> wrote:

> I was going to hold off introducing this until the 3-4 major
> development issues had been sorted out, but the third time I found
> myself writing "yes, I have a plan for this, but I'm going to wait
> a bit before discussing it", I decided I was behaving like a
> smarmy teenager.
> 
> There's nothing time-critical in this thread, so if you're
> currently working on anything important, skip this email and come
> back to it later.  We won't make any real decisions for a week or
> so.
> 
> 
> Lilypond Syntax Development   (tentative name)

Are you on mind-altering drugs? ;)

> 
> One of the biggest complaints people have with lilypond -- other
> than that silly "there's no gui" -- is the changing syntax.  Now,
> inventing a language or standards is difficult.  If you set it in
> stone too soon, you risk being stuck with decisions which may
> limit matters.  If you keep on updating the syntax, interaction
> with older data (and other programs!) becomes complex.
> 
> However, I think we now have a critical mass of interested users,
> experience with the syntax, and developers.  I therefore propose
> to have a Grand Project devoted to stabilizing the lilypond input
> format.


There's probably another reason why it makes sense to do this at this time:
the syntax has largely settled down.

> 
> 
> SUMMARY
> 
> Start: Sep 2009.
> 
> Length: 6-9 months.  We're not going to rush this.
> 
> Goal: define an input format which we commit to being
> machine-updateable for the forseeable future.  Any future patches
> which change the syntax in a non-convert-ly-able format will be
> rejected.  (subject to the limitations, below)
> Once this is finished, we will release lilypond 3.0.
> 
> 
> LIMITATIONS and SCOPE
> 
> - tweaks will not be included.  Anything with \override, \set,
>   \overrideProperty, \tweak, \revert, \unset, #(blah blah) ...
>   including even those names themselves... is still fair game for
>   NOT_SMART convert-ly updates.

One nice thing about this limitation is that it allows ongoing syntax
development outside of the base syntax.  That is, if somebody wants to
develop a new feature that is incompatible with the existing base syntax,
they can do so in the form of a tweak (in the general sense, not the \tweak
sense).  They can work out the bugs, get the functionality going, and have
usable output, even if it can't be added to the base syntax yet.  So this
preserves flexibility for development, while stabilizing syntax for standard
usage.

> 
> DISCUSSION
> 
> Don't respond to any of the specifics yet.  Yes, we all have our
> pet irritations (like "what the mao is up with \paper and
> \layout?!").  There will be plenty of time to discuss them.  At
> the moment, I'm looking for comments about the mandate -- what's
> the scope, how much interest is there, and does anybody object to
> such work?
> 

I'm a bit skeptical that we will be able to really do this job right; and
doing it wrong is worse (IMO) than not doing it at all.  But I think that
it's worth trying (maybe on a separate development branch) so that we can
evaluate it before we commit to it.

> 
> CRESCENDO
> 
> Reinhold and Frederick: as you may have guessed, I'm proposing
> that your patch waits until 3.0.  Anything requiring such manual
> tweaks will make some people very unhappy, such as mutopia.

What if we added the new crescendo syntax as new syntax (e.g. with something
like \newcresc), and kept the old syntax as well (so as not to break
existing scores)?  This would allow the use of the new syntax in current
scores, and get the work going right now.  By using different names, we
could easily do the convert-ly when it came time to upgrade scores.  The new
syntax would be converted to version 3.0 syntax automatically, and the old
syntax would get a NOT_SMART.

We wouldn't need to wait for a year to get it going in this scenario.  We'd
simply have to live with less-than-optimal-syntax that would be
automatically fixable when the new version comes out.

This idea is similar to developing a new_foo_engraver, which is eventually
phased converted to foo_engraver when the old foo_engraver is removed.


Thanks,

Carl