Re: Input variables and Scheme

[Han-Wen Nienhuys]

Michael Welsh Duggan schreef:
> Michael Welsh Duggan <address@hidden> writes:
>
> > Michael Welsh Duggan <address@hidden> writes:
> >
> > > Either the documentation for 12.2.1 "Input variables and Scheme" is
> > > deprecated, or somthing is broken.  Using the following input:
> > >
> > > \version "2.9.19"
> > >
> > > traLaLa = { c'4 d'4 }
> > >
> > > #(define newLa (map ly:music-deep-copy
> > >   (list traLaLa traLaLa)))
> > > #(define twice
> > >   (make-sequential-music newLa))
> > >
> > > { \twice }
> > >
> > > I get the following output:
> > >
> > > lilypond -f ps /home/md5i/lily/test27.ly
> > > GNU LilyPond 2.9.19.mwd
> > > Processing `/home/md5i/lily/test27.ly'
> > > Parsing.../home/md5i/lily/test27.ly:2:3: While evaluating arguments to list in 
> > > expression (list traLaLa traLaLa):
> > > /home/md5i/lily/test27.ly:2:3: Unbound variable: traLaLa
> > Both this and the subsequent bug I have posted are rooted in the same
> > problem.  The asignment rule in parser.yy isn't triggered until after
> > the subsequent scheme expression is lexed.  Since scheme code is
> > executed at lex time, the scheme expression is effectively happening
> > before the assignment preceeding it.
>
> One possible way to fix this problem is to pass on the result of the
> `read' call to the parser to evaluate, instead of doing both in
> ly_parse_scm (internal_ly_parse_scm).  If any of the primary
> developers think this is a good idea, I'll have a stab at implementing
> it.

Hmm, but what about ly:export ? It sets the lexer token type of a scheme 
expression depending on the outcome  of the evaluation. It's not used 
very often, but we have to tread carefully with compatibility.

--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com