[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: parser variables persist beyond { } scope
From: |
Mark Polesky |
Subject: |
Re: parser variables persist beyond { } scope |
Date: |
Thu, 6 Aug 2009 09:55:05 -0700 (PDT) |
Ian Hulin wrote:
> Is there a way of do this sort of thing sometime in the future?
>
> \afterGrace {d1 {c16[ d] }} % works as now - except extra braces
> \afterGrace {d1 {c16[ d] } 15 16} % extra optional parameters
Well, now I think we're pretty much back at Han-Wen's original
suggestion, which was to have two commands, one for temporary
afterGraceFraction overrides, like
\afterGrace <music> <music>
\afterGraceCustom <pair> <music> <music>
Though I admit, I'm not particularly fond of this solution.
I considered what it would take to truly implement your suggestion
above. It can't be done precisely as you've laid it out. At first
I considered this syntax:
\afterGrace { d1 { c16[ d] } }
\afterGrace { d1 { c16[ d] } #'(1 . 2) }
But that would change the 2-argument signature to one argument
with two (or three) parts to it. Presumably the typecheck for the
one argument would be "ly:music?", but that wouldn't work since
lone scheme-pairs aren't incorporated into music-expressions. You
can see this for yourself if you do:
\displayMusic { c c #'(1 . 2) }
==>
(make-music
'SequentialMusic
'elements
(list (make-music ...)
(make-music ...)))
The scheme-pair simply isn't included in the music-expression.
Maybe there's another typecheck that would allow this, but I'm not
aware of one.
Perhaps it could be done by enclosing the \afterGrace along with
its own arguments in a set of curly-braces:
{ \afterGrace d1 { c16[ d] } }
{ \afterGrace d1 { c16[ d] } #'(1 . 2) }
The idea then would be to allow an optional argument in the
signature:
afterGrace =
#(define-music-function
(parser location main grace . fraction)
(ly:music? ly:music? . pair?)
...)
This would require modifying the define-music-function defmacro
(on line 764 of music-functions.scm), which may be interesting,
but most likely would create far more problems than it would fix.
Not even sure if it would be possible. I could be wrong, but I
expect a firm veto from Han-Wen...
But I am curious; this is interesting. Could it be done?
- Mark
- Re: parser variables persist beyond { } scope, Ian Hulin, 2009/08/04
- Re: parser variables persist beyond { } scope, Han-Wen Nienhuys, 2009/08/04
- Re: parser variables persist beyond { } scope, Mark Polesky, 2009/08/06
- Re: parser variables persist beyond { } scope,
Mark Polesky <=
- Re: parser variables persist beyond { } scope, John Mandereau, 2009/08/06
- Re: parser variables persist beyond { } scope, Reinhold Kainhofer, 2009/08/06
- Re: parser variables persist beyond { } scope, Werner LEMBERG, 2009/08/07
- Re: parser variables persist beyond { } scope, Mark Polesky, 2009/08/07
- Re: parser variables persist beyond { } scope, Reinhold Kainhofer, 2009/08/07
- Re: parser variables persist beyond { } scope, John Mandereau, 2009/08/09
- Re: parser variables persist beyond { } scope, Carl Sorensen, 2009/08/09
- Re: parser variables persist beyond { } scope, Mark Polesky, 2009/08/09
- Re: parser variables persist beyond { } scope, John Mandereau, 2009/08/10
- Re: parser variables persist beyond { } scope, Ian Hulin, 2009/08/10