On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival
<gra...@percival-music.ca> wrote:
> This summer hasn't been going as I'd hoped -- heh, who am I
> kidding, this whole year hasn't been going as I'd hoped. Anyway,
> we seem to have radically different concepts of what "input
> stabilization" might mean, or even if it's a good idea worth
> doing.
>
> Hopefully we can settle those questions now.
> http://lilypond.org/~graham/gop/gop_4.html
>
>
> ** Summary
>
> 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.
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. There are probably lots of other syntax
details that we adopted for them to be better-looking (eg. "\tempo
4.") that are making our lives difficult now.
I think the real problem with syntax changes is that users cannot be sure that
old syntax can be reinterpreted under new syntax rules to be something
else. That means that you have to check the output of the new file
note by note, and most users just don't have the time for that.
As a corollorary, it is OK for a syntax change to invalidate previous
.ly files, if it generates a warning at the problematic location.
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
* 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.
* 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.
> ** 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 greater detail: I’m suggesting that we have a round of syntax
> stabilization (GLISS). At the end of it (3 months? 6 months?), we
> add a few regression tests that might look something like this:
>
>
> \version "2.16.0"
> \score {
> \music {
> \staff {
> \voice {
> a4 b c4. d8 |
> \tuplet 2/3 { fis4 a bes } r2 |
> }
> }
> }
> }
>
> 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.
> ** Example questions
>
> Here’s a few sample questions that we’d encounter even with a
> really small subset.
>
> PLEASE DO NOT DISCUSS THESE RIGHT NOW.
>
> - do we keep dutch as the default language, or switch to
> english?
> - do we finally make that \times -> \tuplet change that’s been
> discussed for years?
> - \score \staff vs. \new score \new staff.
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
* dramatically simplify our parser/lexer code in a way that brings
future rewards.
* dramatically expand our user-base
I think these should be the guiding principles for any kind of change
we contemplate.
I also think that there are very few changes that could meet these
standard because:
* what people can do is very often limited by the typesetting
infratstructure rather than syntax
* the lexer/parser is complex, but it is sunk cost. Cleaning it up is
only worthwhile if you intend to do further work (ie. more syntax
changes) on it.
* people that don't use Lily now probably do for lack of a graphical interface.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
