Re: preliminary GLISS discussions

[David Kastrup]

David Kastrup <address@hidden> writes:

> Han-Wen Nienhuys <address@hidden> writes:
>
>> On Thu, Aug 30, 2012 at 9:21 AM, David Kastrup <address@hidden> wrote:
>>>> Is there a complete proposal of what is on the drawing board? Barring
>>>> that, is there a list of (perceived) problems in the current
>>>> syntax/parser?
>>>
>>> The possible values for music following a skipped optional argument are
>>> constrained to music parseable without lookahead because the decision
>>
>> I had to let this sink in for a bit, since I had completely missed
>> that a patch doing optional music arguments had went in. Had I noticed
>> in time, I probably would have complained (and we might have ended up
>> in a flamewar).
>
> It was a matter of "what's good for the goose, should be good for the
> gander".  The existing hardwired LilyPond syntax used a variety of
> optional arguments (partly skipped explicitly using \default, partly
> left out like with \relative { c' }).  Bringing the preexisting syntax
> within the scope of music functions meant making Scheme programmers
> stop being second-class citizens who have to take what they are fed.

As one example for an analogous use of optional arguments, consider

\tweak Accidental #'color #red cis4

\tweak has always been a music function.  Being able to use a syntax
fairly analogous to that of \override makes things simple and
straightforward for the user.  You don't want to write \default in place
of Accidental for every use without a grob qualification.

And you don't want to have him remember different function names for
each argument list variation.

Of course this means that _compiling_ LilyPond into Scheme rather than
interpreting it is not feasible when using #{ ... #} inside of
functions.  If this becomes really important one day, one can use trace
compiling techniques: one compiles a version corresponding to the
_current_ argument values while keeping track of the preconditions on
the values corresponding to every syntactical decision taken.  As long
as the preconditions for the taken syntactical decisions are met on the
next call, one uses the precompiled Scheme equivalent of the passage in
LilyPond syntax.  Otherwise, one repeats the process by calling the
parser on the LilyPond version again.

It is likely that 99% of all #{ ... #} constructs are not syntactically
polymorphic, at least not intentionally so, so this technique should
usually be low-overhead.  On the other hand, the LilyPond parser is not
exactly inefficient, either.

-- 
David Kastrup