Re: Syntax change proposal:

[David Kastrup]

"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/dynamics-broken-hairpin.ly:  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