[GLISS] why the hell all this fuss (was: modern-straight-flag)

[Janek Warchoł]

On Thu, Sep 6, 2012 at 12:15 AM, Reinhold Kainhofer
<address@hidden> wrote:
> [1] Note, however, that ANY change, even a very small, subtle change, is a
> really grave argument for a music publisher against using lilypond.
> I wrote a huge piece (~95 pages full score, 23 orchestra instruments, choir,
> etc) a few years ago. I didn't count the hours it took me last month to
> bring it up to date with the latest lilypond version (I had to visually
> compare the whole full score and all instruments to make sure that nothing
> had been lost).
> At that time, I really, really, really cursed lilypond and its frequent
> syntax changes.

:(

I think that's Graham's point: syntax changes are bad, so if we have
to make them (and apparently we still have to), let's do it once and
for all.  Or at most 1-2 times per decade.
In order for this to make sense, we must be really confident in the
syntax we are going to label "stable".  That's why i think we all need
a lot of discussions to get a better understanding of both user needs
and problems in parser (ambiguities etc).  In my opinion Lily syntax
isn't expressive enough, which means that sooner or later we'll have
to make some changes, which means that we should make them now.

Example: hairpins.  There is no convenient way of specifying hairpins
that don't align with the notes (you have to use spacer rests, which
is bad for a number of reasons).  We need to have a convenient way.
Adding this will be a syntax change, so let's do it now instead of
later.
Another example: vertical hairpins attached to arpeggios (Elaine Gould
shows them).  I don't think we have a simple way of extending our
syntax to express them - some basic design principles would have to be
changed a bit, i suppose.  So let's change them now.

In fact, i really do think that lack of expressiveness is one of the
big reasons why we have syntax changes.  When something is impossible
to express in "native Lily" (like the hairpins attached to arpeggios),
people invent worarounds.  Workarounds are more likely to stop
working, and each workaround will be different.  That's why i think we
need to design syntax that's easy to extend (as well as unambiguous).

cheers,
Janek