Re: New read/eval Scheme syntax inconsistent in handling existing code

[David Kastrup]

David Kastrup <address@hidden> writes:

> Valentin Villenave <address@hidden> 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