Re: parser.yy: rearrange to allow more lenient use of music arguments for music functions. (issue4815052)

[dak]

http://codereview.appspot.com/4815052/diff/2001/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):

http://codereview.appspot.com/4815052/diff/2001/Documentation/extending/programming-interface.itely#newcode146
Documentation/extending/programming-interface.itely:146:
On 2011/07/29 07:17:19, MikeSol wrote:
> Can you give a more lilypond examples as you do above (with s
1*0-\fun).  I
> think that is very clear, and more examples like that would help
understand this
> faster.

Don't get me wrong: I don't think that this documentation is of good
quality.  But to a large part, it is not documenting what I have
changed, but rather what has been there for a long time without any
documentation.

If you take a look at music-functions.scm, you'll get a few eye-openers
about what was possible previously.

So my main priority with regard to the docs is getting them to be
reasonably complete.  Turning complete documentation into good
documentation is then more of a frog's task.  Or at least it is mostly a
separate issue than what this patch is about.

Personally, I'd like things like #{ -. #} to work, namely let #{ #} be
able to surround more than just serial music, a reasonable subset of
what we can do in assignments or top-level expressions.

http://codereview.appspot.com/4815052/diff/2001/lily/parser.yy
File lily/parser.yy (right):

http://codereview.appspot.com/4815052/diff/2001/lily/parser.yy#newcode1598
lily/parser.yy:1598: }
On 2011/07/29 07:17:19, MikeSol wrote:
> I think this points to a larger issue of the information that
enclosing
> characters (brackets, parentheses, etc.) carry in LilyPond.

The problem is rather that music functions can currently accept a music
expression not enclosed with braces or anything else at all.  One reason
is that such music expressions can serve as a poor man's substitute for
pitch arguments, and are used for that.  Perhaps this can be changed in
future (we have pitch arguments now), but currently this would likely
break too much existing code.

> Is there a way,
> like in LaTeX with verb, that people can construct their own
begininning and end
> delimiters to help the parser?

Not really.

> This would not only be useful here, but in cases
> like \musicFunction { a \times 2/3 { a b } c } which in LilyPond would
compile
> the tuplet on two notes.  However, if we could do \musicFunction ={ a
\times 2/3
> { a b =} c }, then the parser could know that ={ and =} are supposed
to go into
> the music function.

The corresponding data structures can't be broken off in the middle like
that.

http://codereview.appspot.com/4815052/