David Kastrup <[email protected]> writes: > Valentin Villenave <[email protected]> writes: >> >> myvar = { b'4 } >> >> $(display "this shouldn't be needed anyway") >> $(eval-string "(define-public myvar #{ a'2 #} )" ) >> >> \new Staff \myvar > > You need #(display ...). $ takes a look at the type of the enclosed > expression and creates a token of the appropriate type in the input > stream. The type of the enclosed expression is *unspecified* so nothing > gets inserted into the input stream by the lexer and the parser is > completely unimpressed. With #(display ..., the resulting token type is > a Scheme token. The parser throws it away in this context, but it knows > that a Scheme token can't be between { b'4 } and \addlyrics (for > example). So the rule it exercises for throwing the Scheme token away > makes sure that the next token is not needed as lookahead token for > finishing the previous token. > > You can't write #(display ... in any context, only where Scheme tokens > are allowed. $(display ... in contrast is allowed anywhere since the > parser never gets to see anything. Since the parser does not get to see > anything, it does not change parsing.
Actually, it was a deliberate change that $*unspecified* does not create SCM_TOKEN. I considered it strange that there are places where you can write $(+ 2 3) but not $(display 3). Yes, I did not actually discuss this change separately I guess. Part of the reason is that $ was not used in the manner of making the parser skip a beat previously, so I saw no point in making it do it now. -- David Kastrup _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
