Re: Syntax change proposal:

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Thursday, July 26, 2012 11:12 AM
>
>> The _function_ does not behave differently.  It is just that more
>> material belongs to the music expression argument.
>
> That's splitting hairs.  As far as the user is concerned
> \dichrom3D e 3.1 and \dichrom3D e 2.9 would behave
> very differently, unless I'm still missing something.
>
> I don't relish writing user documentation to explain
> this behaviour:
> Warning: if a music function takes music and a real as
> two arguments and the first argument does not have an
> explicit duration the second argument must not begin
> with 1, 2, 4, 8, ... or the result will surprise you.

It's much simpler than that.  Expressions are "greedy": what can become
a part of them, will.  For that reason, it may make sense to enclose
simple music in braces, or it is likely to integrate durations and
postevents not intended for it.

For argument parsing it might be nice if { single-music-event } would
not turn into sequential music, similar to how #{ single-music-event #}
doesn't, so that you can make music arguments unambiguous without
causing them to be wrapped in sequential music.

> In the past you've always been in favour of eliminating
> surprises.  Are you really proposing we should 
> implement this syntax?

\displayMusic c4-3

is existing syntax.  Long-existing syntax.  A total nuisance to support.
But it is not like there is much choice involved here.  It has been
around eternities.  Do you think all the backtracking folderol and
mode-switching and token-juggling that is going on in the parser
bypassing the basic LALR(1) algorithm has been implemented because I
consider it fun?

Indeed, on the user list we get complaints from really good aspiring
developers that there are still too many unnatural restrictions (what
you will call non-surprises) in connection with argument parsing.

If you can rely on strict greediness, that's an advantage.  You might
want to call for a few more syntax errors.  I am not sure they always
help.

-- 
David Kastrup