[Top][All Lists]

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

Re: Syntax change proposal:

From: David Kastrup
Subject: Re: Syntax change proposal:
Date: Thu, 19 Jul 2012 18:18:55 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Thursday, July 19, 2012 2:43 PM
>> "Trevor Daniels" <address@hidden> writes:
>>> David Kastrup wrote Monday, July 16, 2012 9:18 AM
>>>> Graham Percival <address@hidden> writes:
>>>>> On Mon, Jul 16, 2012 at 02:02:31AM +0200, David Kastrup wrote:
>>>>>> One really ugly problem is interpreting things like "4.".  Looks like a
>>>>>> duration, but then we have
>>>>>> input/regression/  line-width = 4.\cm
>>>>> I am against making a change like this outwith[1] of GLISS.  It
>>>>> could involve a lot of user pain (and documentation-editing
>>>>> pain!), so I think it's important to at least pretend[2] to have
>>>>> good user consultation beforehand.
>>>> I disagree with "a lot of user pain".
>>>>> As far as the actual proposal goes, I'm generally in favor.
>>> [snip a long convincing argument]
>>> I'm generally in favour too, but I'd be happier if this were deferred
>>> until 2.17.
>> Well, let's see what the parser currently delivers in INITIAL mode.
> [snip more convincing argument]
>> I am not convinced that this is an area that's really good for keeping.
>> The semantics of -., for example, were introduced in 2.15.9 with
>> commit da949cdcede0ffb559e9e5e2adbae2088ba1f6d6
> Ah, that's new information
>> so it is not like stable release users rely on them.  While most is
>> older than that, I am not overly impressed with it either.
> The only question in my mind is, how confident are you that
> the change you are contemplating will not introduce
> unforeseen problems, perhaps later?  If you are really
> confident they will not, then let's go with it.  But don't forget, 
> few at present on the list can sensibly review changes to the 
> parser.

The original proposal was to rule out 0. and .5 as real numbers.  This
will introduce foreseen problems: things will break where those had been
used (there are definitely uses of 0. in our own code base but not for
.5).  A few of those problems can be caught with convert-ly rules, but
those would be based on heuristics (like doing conversions when they
occur after = which should catch most existing cases).  Such heuristics
would, however, also catch legitimate uses like

\relative c' { b = 4. }

(quick: can you guess what this does?).

David Kastrup

reply via email to

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