Re: Issue 935 in lilypond: Enhancement: optional arguments in music functions

[lilypond]

Updates:
        Labels: -Patch-review Patch-needs_work

Comment #5 on issue 935 by address@hidden: Enhancement: optional  
arguments in music functions
http://code.google.com/p/lilypond/issues/detail?id=935

Joe Neeman <address@hidden> writes:

> > On Mon, Sep 19, 2011 at 9:35 PM, David Kastrup <address@hidden> wrote:
> > >> Colin Campbell <address@hidden> writes:
> > >>
> > > >>> Issue 935: Enhancement: optional arguments in music functions - R
> > > >>> 5023044
> > >>
> > >> Cancel countdown.  I am still fuzzing with avoiding O(n2) rules for n
> > >> syntax classes, and trying to cater for multiple optional arguments  
> > in a
> > >> row.  Doing both is a challenge requiring quite a bit of cleanup, and
> > >> applying the current patch would be a step backward.  Hope to get
> > >> something working soon.  I have a working version right now, but don't
> > >> like to leave ~80 shift/reduce conflicts (basically 2n with n being  
> > the
> > >> number of terminal symbols that may start an argument).
> >
> > Have you considered adding a special syntax for optional arguments?
> > Like \foo[opt]{mandatory} in tex...
Not really interesting since it won't cover the syntax of existing
commands like \relative c' c.

I am making progress, but it's not really pretty.  Basically if one
avoids O(n2) rules and uses one rule to bind them all, then you can't
specialcase something like [music] music namely an optional music
command before a mandatory one.  You need operator priorities to sort
this out.  Now we don't much care what [music] music ends up as (it is
not smart syntax), but we do care what [pitch] music ends up with.  If
optional arguments are greedy, something like [music] music has the
potential to take quite a bit of lookahead, if they are deterring,
however, [pitch] music won't work since pitch would be flushed out into
music (a pitch specification can always be interpreted as music).  With
several optional arguments, one would presumably like to have them
filled left-to-right.  Operator priorities for resolving shift/reduce
concern themselves with the lookahead symbol.  If I look ahead into the
following music stream, I need to define operator precendence for
anything that can follow.  That's just not feasible.

I am still gaming the LALR(1) system.  I'll likely come up with
something workable, but it is really much more work for the bounty than
I had intended.

-- David Kastrup