lilypond-devel
[Top][All Lists]

## Lilypond Syntax Development and 3.0

 From: Graham Percival Subject: Lilypond Syntax Development and 3.0 Date: Mon, 27 Jul 2009 03:22:33 -0700 User-agent: Mutt/1.5.18 (2008-05-17)

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)

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.

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

- other than that, everything is on the table.  Is it a problem to
have the tagline inside \header?  What should the default
behavior of \include be?  When we abolish \times, do we move
to \tuplet 3:2 or \tuplet 2/3 or what (for typical triplets
in 4/4 time)?

- we need to get standards for commands.  This will help users
remember them, and reduce the options for future names (and
potential renamings later on).  \commandOn and \commandOff
seem to work well (should we *always* have an Off command?),
but what about the "command" part?  Should it be \nounVerbOn,
or \verbNounOn ?  Or \verbNotesWithExtraInformationOn ?

- we need standards for the location of commands.  Ligature
brackets, I'm looking at you.  (non-postfix notation must die!)

- this Grand Project doesn't change whether we have a 2.16 or
not.  The main problem will be deciding what to do (with a
bit of messiness anticipated for \tuplet); we could definitely
release a 2.16 before merging _any_ of these changes.

- we obviously can't /guarantee/ that we'll /never/ make any
non-convert-ly changes in the basic format.  But we *can*
guarantee that such changes would force lilypond 4.0, and
that we would only do so for overwhelmingly good reasons.

WORKFLOW

- We're going to have lots and lots of emails flying around.  They
don't really fit into either -devel or -user, so we'll use a
mailist on lilynet.net.  Maybe the already-created proposals

- I could be convinced to use the lilynet wiki for this project,
although we'd need account-locked pages, and it would increase

- after the initial discussion of proposals has died down, I'll
bring it to -devel.  We're not going to make any (significant)
changes without discussing it on -devel, but we're going to
I don't want to clutter up -devel.  Once whatever chaotic
silliness on the syntax list is settled down, I'll bring the
ideas to -devel.

- as with GDP, I'll moderate the discussion.  Not as with mailist
moderation, but rather by introducing issues at specific
times.  We don't want a free-for-all discussion of all parts
of the syntax at once; nothing will get resolved.

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 scope, how much interest is there, and does anybody object to
such work?

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.

I think we should make *all* manual changes at once, but reassure
people that this will (probably) be the last time (for non-tweaked
scores, at least).

This also serves as test of developers: we've avoided getting
"pinned down" with the input syntax because that would limit
development.  How do you two feel about your hard work on the \cr
stuff being delayed by up to a year?  I don't like asking this,
but I think there are solid reasons for it.

Cheers,
- Graham