Re: Syntax change proposal:

[David Kastrup]

Keith OHara <address@hidden> writes:

> David Kastrup <dak <at> gnu.org> writes:
>
>> Keith OHara <k-ohara5a5a <at> oco.net> writes:
>> > The pre-defined \cm is acted only in limited contexts -- the same 
>> > contexts where we are allowed to type decimal numbers without a leading #. 
>> > We would like those contexts to be even more narrow, immediately after the 
>> > '=' operator.
>> 
>> I don't see why one would not want that for function arguments.  What's
>> good for assigning to variables is good for assigning to function
>> arguments.
>>
>
> I suspect that I do not want naked decimal numbers as function arguments 
> because they get confused with other notation.

That's not all that different for assignments.

> If I make a function 
>   \dichrom3D { c4 d e f } 3.7
> that engraves a passage so that the notes appear to float 3.7 staff-spaces
> above the paper when viewed with red/cyan 3D glasses, 
>
> then if I use it on an isolated note \dichrom3D e 2.9
> I get a dotted-half-note e floating 9.0 staff-spaces above the page.
>  
> Lilypond's grammar today uses  \dichrom3D e #2.9  to segregate the
> arguments.

Not really.  There is a complex interaction of "closed" and "open" music
expressions that can only be used in certain contexts in order to pick
things apart.  Part of the reason is that some previously hardwired
constructs have been turned into music functions, and the hardwired
constructs permitted (or even demanded) using non-Scheme numbers, so it
is not an option for the music-function based ones to stop doing so.

> I think I prefer the freedom to sloppily write { indent = 2.\mm } to
> the freedom to drop the # when mixing decimal numbers with music.

There is no way you are going to write #2. \mm and have that produce a
meaningful output.  Why don't you write { indent = 2\mm }?  This is
really puzzling to me.

The problem is that _you_ know when you are in a mode for music, and
when not.  Does your syntax-aware editor know?  I find that it is even
hard to make sure LilyPond knows.

> Decimal numbers do not seem to mix well in LilyPond music, so I say
> restrict them to where we use them: the first token after an
> assignment operator '='

So not inside of #{ ... #}?  It is otherwise rather similar to the
"after an assignment operator" situation.

Convenience comes at a price, and it is a price future generations will
have to pay.  The half-life of a parser might be smaller than that of
typical nuclear waste, but at some point of time somebody will actually
have to deal with the consequences.

In fact, giving up on LilyPond as an archivable format _is_ one of the
consequences.  Defining an archivable subset may help, and we might warn
people that this subset's constraints will increasingly become a part of
LilyPond's realities, so they might want to converge to it before it
becomes inconvenient.

-- 
David Kastrup