lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Kastrup
Subject: Re: Unbound variable GUILE error when no whitespace before closing brace
Date: Wed, 15 Feb 2012 16:53:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Reinhold Kainhofer <address@hidden> writes:

> On 15/02/2012 15:30, David Kastrup wrote:
>> Reinhold Kainhofer <address@hidden> writes:
>>
>>> 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.
>
> Yes, but it's our parsers decision to give the scheme reader
> everything it might want, even if that means chunking away from the
> lilypond code...

That is a confused view.  There is no "LilyPond code" until the Scheme
reader has finished.

> A scheme expression is embedded into lilypond syntax, so why can the
> embedded expression decide where it ends, rather than the surrounding
> LilyPond syntax?

Huh?  That is how _any_ lexer works.  In 314, the "embedded expression"
"3" decides that "14" does not form a token of its own, but is part of
the thing starting with 3.  There is no "surrounding" syntax in the
middle of a token.

> This leads to situations like:
> relative c'' {
>   {\override NoteHead #'X-offset = #(+ 1 2)} c % works
>   {\override NoteHead #'X-offset = #3} c       % doesn't work
> }

It seems probably hard to understand, but 3} is a perfectly valid Scheme
token.  You can define it in Scheme, you can use it in Scheme.  Even
within LilyPond.  LilyPond has no clue about the lexical structure of
Scheme, and it does not need one.  I can write

#(define 3} 7)

\relative c'' {
  {\override NoteHead #'X-offset = #(+ 1 2)} c % works
  {\override NoteHead #'X-offset = #3} } c     % works
}

This is valid code, and there is nothing gained by trying to invalidate
it for some reason.  There is no point in forcing the LilyPond lexer to
understand Scheme without being allowed to ask the Scheme reader.  This
can only lead to trouble, and it will mean that we get only a subset of
Scheme that actually works within LilyPond.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]