Re: GOP2-3 - GLISS or not

[Graham Percival]

On Fri, Jul 27, 2012 at 12:56:12PM -0300, Han-Wen Nienhuys wrote:
> On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival
> <address@hidden> 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?
> 
> I think Lily is way past the point for us to decide that the language
> needs to be changed in any major way: syntax is not what stops people
> from using lilypond, and changing it in notable ways will only drive
> people away from Lily.

If we're not going to change a piece of syntax, then why not
inform users of that fact so that they can rely on it being the
same?  At the moment we have something like a "de facto" standard
-- if somebody writes a GUI which exports lilypond 2.12 code, then
it will probably work in lilypond 2.16.  Unless it doesn't, in
which case convert-ly will fix it.  Unless it doesn't, in which
case the GUI fails and the user needs to manually edit the
exported .ly files and/or file a bug with the GUI project.  Of
course, then the GUI front-end needs to either support multiple
.ly backends (i.e. "output to lilypond 2.12", "output to lilypond
2.16").  Or else it could drop support for lilypond 2.12 and only
output for lilypond 2.16.

Regardless of GLISS, we already *are* changing the format in
non-convert-ly ways.  Just last week, Keith found an example from
mutopia that failed to compile after a proposed patch was applied.
Now, I still support making that change, but I think we should
give users (and programmers of projects which convert or export to
lilypond) some hope that simple music won't be changed.

I'm not saying that GLISS will necessarily involve any change of
notation.  I think we should discuss each notation element
separately, and we should certainly consider whether any
disadvantages of the current notation outweigh the pain of
changing.  Maybe we'll decide that it's not worth making any
changes at all, so GLISS really will just be "input syntax
*stabilization*".

> We've had this problem for many years in the 1998-2003 period, when it
> was a usable but limited program, and people had to re-tweak their .ly
> files every few months because we had to get out of a corner we
> painted ourselves into.

Right.  I was good friends with the guy who tried to maintain the
rosegarden lilypond export when we were doing 1.6 to 1.8.  I think
that was when we changed from simultaneous music being <> to <<>>
?  I can't remember the specifics, but he was pretty frustrated
and in the end gave up.

> Rather than "defining" some stable subset (and then getting into a lot
> of discussion on what that subset should look like), I think we should
> just take the overall decision on intent, that is: what are we trying
> to do? My suggestion is:
> 
> * big changes: not OK

I agree with this.

> * small changes, especially when they clean up things (I'm thinking of
> the 4. vs 4.0 change David is working on): in principle OK, but the
> upgrade path should either be automatic or cause failure on
> compilation.

I disagree; we're not going to be perfect with any new syntax.  I
think it's worthwhile to introduce new syntax for a year or two,
find out what works and what doesn't, and fix it if necessary.
Just look at all the iterations that footnotes have gone through!

> * small changes that do not fall in the latter should be done over two
> stable releases. First, you make the old syntax trigger compile
> failure, and only the 2nd stable release you introduce a new
> interpretation.

That requires a fair amount of programmer effort to add the extra
error checks and remove them later.

> > ** Stability or not?
> >
> > Stabilizing a language is a tricky process. If you do it too
> > early, then you’re stuck with whatever mistakes or poor design
> > decisions.
> 
> LilyPond has been around for 15 years, and its basic syntax for 9
> years. It would be weird to suggest that we'd be stabilizing to early.

In general, yes.  But some aspects of our syntax haven't been
around for a long time -- footnotes, woodwind fingering, compound
meters, etc.  Do we have the best syntax for those?  I mean,
maybe David can figure out a way to allow us to write
  \compoundMeter (3+2)/8
or simply
  \time (3+2)/8
instead of
  \compoundMeter #(3 2 8)


> > and then we guarantee that this file will compile, completely
> > unmodified (no convert-ly allowed), for every lilypond 3.x
> > version. This seem like a really small step, but I really don’t
> > think that we can overestimate how much time, energy, and
> > arguments this will require.
> 
> I think this reasoning is red herring. Arguments take as much energy
> as the participants want to invest in it. If you spend too much time
> on it, stop writing replies to discussions.

If people declared somebody as the ultimate dictator of input
syntax, then sure we could avoid arguments.  But I'm trying to
move us to a more inclusive, community-based model of development.
It would be nice if we could reach consensus, or at least agree on
the advantages and disadvantages of a particular point.

So far I think this model has worked for GOP discussions.  Yes,
they take a *lot* more time and effort than if somebody just
declared the answer, but I'm betting that this inclusive method of
project management will lead to a better project overall.

Occasionally I've side-stepped policy discussions, such as when I
introduced the patch countdown, Patchy git-cl testing, and the
staging branch.  But those instances should be the exception, not
the rule.  I'm hoping that if we have regular well-researched
policy questions introduced on Tuesday and go through the two-week
discussion period, developers will be happier and more motivated
to work on lilypond.

I'm considering this to be an experiment on the time-scale of
years, not weeks, and I'm not inclined to change the experimental
procedure in the middle of it.


> I understand the desire of each of these changes, but I don't see any
> of them either:
> 
> * expand on what people can do with LilyPond

Other than indirectly possibly motivating people to work on
converters and GUIs from lilypond code, I don't see GLISS as
adding new features to lilypond at all.  Rather, I'm expecting
that new development continues as before; after some syntax has
been around for long enough that we're confident that it's good,
we declare it as "stable" so that users and programmers can rely
on it.

> * dramatically simplify our parser/lexer code in a way that brings
> future rewards.

David is working on this.  Some of his changes will break user
code, and some users will be upset by this.  I'm trying to make
users feel better by phrasing it as a "give and take" situation.
Yes, some things will break, but other things will have a
guarantee of stability -- and the area of stability will increase
over time.

> * dramatically expand our user-base

Syntax stability can't hurt converts and GUIs.  I hope that GLISS
can indirectly increase our user-base by making it easier for
people to convert music into lilypond.

- Graham