Re: parser variables persist beyond { } scope

[Ian Hulin]

On 10/08/2009 10:52, John Mandereau wrote:

Le lundi 10 août 2009 à 00:36 +0100, Ian Hulin a écrit :
  

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?
    

I'm not sure I know why all languages I know (including Scheme) that
support optional arguments require them after mandatory arguments, but I
think it's not worth fighting against this by trying to support optional
arguments first in ly music functions.

IMHO keyword arguments are not worth the effort, patches might be
welcome to prove the contrary.

John
  

_______________________________________________
lilypond-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/lilypond-devel
  

John,
I'm away from home at the moment but I'll have a play with this after tomorrow when I get back.  We could try something like
(define* afterGrace (parser location #:optional (fraction (3.4))
  ( main (ly:error "Main notes music _expression_ required for \afterGrace")
    grace (ly:error "Aftergraces music _expression_ required for \afterGrace") ) 
  (pair? music? music?)
;; fraction gets defaulted to (3.4) if not coded
;; mainnotes parameter throws error if not coded
;; aftergraces parameter throws error if not coded
;
; rest of function body
)
I suppose your next observation would be the error messages would need to be in translatable string definitions . . .

Cheers,
Ian