LilyPond Contributor's Guide: 14.7 Grand LilyPond Input Syntax Standardization (GLISS)

[ << Administrative policies ]	[Top][Contents][Index][ ? ]			[ LilyPond grammar >> ]
[ < GOP-PROP 9 - behavior of make doc ]		[ Up : Administrative policies ]	[ Specific GLISS issues > ]

14.7 Grand LilyPond Input Syntax Standardization (GLISS)

Summary

Start: sortly after 2.14 comes out, which is currently estimated to happen in January 2011.
Length: 6-12 months. We’re not going to rush this.
Goal: define an input 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.

The Problem

One of the biggest complaints people have with lilypond – other than silly thing like "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.

Scope and Limitations

tweaks will not be included. Anything with \override, \set, \overrideProperty, \tweak, \revert, \unset... including even those command names themselves... is still fair game for NOT_SMART convert-ly updates.
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?
we need to get standards for command names. 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 affect 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 should 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. The vast majority won’t really fit into either -devel or -user, so we’ll use a list devoted to syntax issues.
Once we have a serious proposal that gained general acceptance from the separate syntax mailing list, I’ll bring it to -devel. We’re not going to make any changes without discussing it on -devel, but if we’re going to have huge threads about English grammar and silly ideas, and 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.
Whenever possible, we’ll decide on policies at the highest level of abstraction. For example, consider \numericTimeSignature, \slurUp, \xNotesOn, \startTextSpan, and \verylongfermata. One of them starts with the name of the notation first (slur). One has an abbreviation (x instead of cross). One has the verb at the end (On), another has it at the beginning (start). The adjective can come at the beginning (numeric, x) or end (Up). Most are in camelCase, but one isn’t (verylongfermata).
Instead of arguing about each individual command, we’ll decide on abstract questions. Should each command begin the notation-noun, or the verb? Should all commands be in camelCase, or should we make everything other than articulations in camelCase but make articulations all lower-case? Are abbreviations allowed?
Once we’ve answered such fundamental questions, most of the syntax should fall into place pretty easily. There might be a few odd questions left ("is it a span, or a spanner?"), but those can be settled fairly quickly.

Implementation

Nothing until the project is finished, then we declare the next stable release (2.16.0 or 2.18.0 ?) to be the final 2.x version, release it, then apply all the GLISS syntax changes and start testing a beta for 3.0 a week or two later.

Discussion

Don’t respond to any of the specifics yet. Yes, we all have our pet irritations (like "what’s up with \paper and \layout?!"). There will be plenty of time to discuss them once GLISS starts.

That said, we have a list of specific items that people really wanted to have written down. See Specific GLISS issues.

[ << Administrative policies ]	[Top][Contents][Index][ ? ]			[ LilyPond grammar >> ]
[ < GOP-PROP 9 - behavior of make doc ]		[ Up : Administrative policies ]	[ Specific GLISS issues > ]