[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP2-3 - GLISS or not

From: David Kastrup
Subject: Re: GOP2-3 - GLISS or not
Date: Sun, 29 Jul 2012 16:46:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival
> <address@hidden> 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.
>> ** 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.

Yes and no.

I have just created
Patch: Unify the lexer's idea of words and commands across all modes.

This a a change of LilyPond's syntax in a major way.  For example, the
previously working program

{ c-flat }

now no longer works.  Similarly

\paper { dim2 = 5\cm  dim3 = 2\dim2 }

stops working.

Will this cause an outcry?  Hardly.  You'll rather get "Wait, you mean
this worked?"  It is unlikely that there is a significant body of code
around that would have relied on this to work because while it "worked"
previously, it did so undocumentedly, under circumstances that are not
documented and are not even explainable in terms meaningful to a user.

This is a large and invasive syntax change, and it does not even affect
the regtests.

LilyPond has a "de facto" syntax that is more or less being used and
documented.  We won't be tying it down anytime soon.  But it is also
clear that some changes are an improvement.  With the above change in
place, I can write

\paper { paper-width = #(+ #{ 3\cm #} #{ \paper-width #} )}

and it works.  Even though #{...#} sets up \notemode nominally.

There is good reason to make such a change.  But of course there is also
"old code might have relied on this behavior".

And I agree with Graham that at some point of time we _should_ try to
settle just _what_ behavior people may rely on safely.

> As a corollorary, it is OK for a syntax change to invalidate previous
> .ly files, if it generates a warning at the problematic location.

You _can't_ reliably generate a warning for every undocumented detail
that may change its interpretation in future.

How would you even _start_ generating warning for a lexer change like
the one I pointed out?

Lexer changes are almost impossible to do with a proper deprecation
phase.  Parser changes are hard, but sometimes possible.  Music function
changes are often feasible.

The deeper the change is, the harder it is to do a deprecation phase
because in a deprecation phase, something needs to be interpreted in two
manners, and the whole point of the phase is presumably to arrive at a
completely different interpretation.

> 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.

Well, take the above lexer change.  It is a big change, but it is
unlikely many people will encounter its effects because they likely have
shied away from completely undocumented behavior only working in corner

I want fewer corner cases, and more documented behavior.  Fewer corner
cases means incompatibilities, but how many people actually have been
sitting in the unlighted corners anyway?

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]