Re: parser variables persist beyond { } scope

[Ian Hulin]

On 09/08/2009 23:23, John Mandereau wrote:
> Sorry for my initial reply to this, it was not enough to the point, I'm
> trying again :-)
>
> Le jeudi 06 août 2009 à 09:55 -0700, Mark Polesky a écrit :
> > 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>
>
> Is there consensus on the name of the second function before we add it
> to Git?  I thought on \afterGraceCustomSpacing, but it's a bit too long.
>
>
> > { \afterGrace d1 { c16[ d] } }
> > { \afterGrace d1 { c16[ d] } #'(1 . 2) }

I'm still unclear why we need two interfaces.
I know Scheme functions have the ability to use optional parameters if 
you use the (ice-9 optargs) mudule (your can even specificy keyworded 
paramters), so would this kine of thing be possible:

(define* afterGrace (parser location #:optional (fraction (3.4)) 
mainnotes aftergraces) (pair? music? music?)
; the fraction parameter doesn't need to be specified, and if it's
; omitted will be give an default value of (3.4)
(set! afterGracefraction fraction) ; or whatever munging you need to
; convert the pair into a numeric value as a fraction .
;
; do all the current afterGrace code
;
)
So providing we could stitch this into the lilypond parsing, you could get
\afterGrace #(5.16) {c'1} {d16[ e16]) ;or
\afterGrace  {c1} {d16[ e16]} ; or even

\afterGrace #:fraction #(5.16} #main: {c1} #grace {d16[ e 16]} ; and
\afterGrace #:main {c1} #:grace {d16[ e16]}

If you added the keyword clauses to the definition.  Keywords would get 
round the problem of having to order the parameters to make sure the 
music expressions are at the end.

Keywords may be going a bit far, but is the optional parameter idea 
maybe a runner?

Cheers,

Ian

> I don't know if it's possible, but this is surely not desirable: braces
> in LilyPond mean either sequential music or block boundaries (\book,
> \score...), overloading them further may add confusion.  Moreover, the
> planned improvements syntax intend to get rid of any prefix commands, so
> these outer braces which would protect fragile commands in TeX are not
> in the right direction.
>
> Best,
> John
>
>