Re: Unbound variable GUILE error when no whitespace before closing brace

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> On 05/02/2012 08:30, David Kastrup wrote:
>> The variable is not } but 0.9} instead.  Anything that can't be parsed
>> as a constant in Scheme is a variable.
>>
>> This has nothing to do with Lilypond:
>>
>> address@hidden:/usr/local/tmp/lilypond$ guile
>> guile> 0.9}
>> ERROR: Unbound variable: 0.9}
>> ABORT: (unbound-variable)
>> guile> address@hidden:/usr/local/tmp/lilypond$ 
>>
>>
>> You could likely say
>>
>> #(define 0.9} 0.9)
>>
>> and have the above work except for the missing closing brace.  There is
>> absolutely nothing that LilyPond could, or even _should_ be trying to
>> fix here.  Scheme is Scheme and outside of LilyPond's responsibility
>> regarding syntax and semantics.
>
> Actually, LilyPond's parser decides which chars are part of the scheme
> expression and which are part of lilypond's syntax.

No, it doesn't.  It fires up the Scheme reader at the current position
in the input, and picks up again wherever the Scheme reader leaves the
input position.

> The lilypond parser decides that the scheme expression includes the },
> which from a user's POV doesn't make sense, as the } is LilyPond's
> delimiter and should thus definitely end the scheme expression (even
> though 0.9} would be a valid guile variable).

You are wrong here.  The LilyPond parser decides _nothing_.  That is the
job of the Scheme reader.

This is _slightly_ different with #{ ... #}: here LilyPond reads
forward, switching into the Scheme reader at every $ or # without
looking at anything else, until it reaches #}.  But again: inside of a $
or # constructs (or what LilyPond thinks may be one) the decisions are
left to the Scheme reader alone.  LilyPond _starts_ the Scheme reader
and is content to continue wherever the Scheme reader will leave it.  It
has no idea in advance where its #} will end.  Which also means that you
can nest those constructs, since the outer LilyPond never even gets to
see the inner #}.

-- 
David Kastrup