Re: Unbound variable GUILE error when no whitespace before closing brace
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: dak@lola:/usr/local/tmp/lilypond$ guile guile 0.9} ERROR: Unbound variable: 0.9} ABORT: (unbound-variable) guile dak@lola:/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. 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). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unbound variable GUILE error when no whitespace before closing brace
Reinhold Kainhofer reinh...@kainhofer.com 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:
dak@lola:/usr/local/tmp/lilypond$ guile
guile 0.9}
ERROR: Unbound variable: 0.9}
ABORT: (unbound-variable)
guile dak@lola:/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
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unbound variable GUILE error when no whitespace before closing brace
On 15/02/2012 15:30, David Kastrup wrote:
Reinhold Kainhofer reinh...@kainhofer.com 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...
A scheme expression is embedded into lilypond syntax, so why can the
embedded expression decide where it ends, rather than the surrounding
LilyPond syntax?
This leads to situations like:
relative c'' {
{\override NoteHead #'X-offset = #(+ 1 2)} c % works
{\override NoteHead #'X-offset = #3} c % doesn't work
}
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unbound variable GUILE error when no whitespace before closing brace
Reinhold Kainhofer reinh...@kainhofer.com writes:
On 15/02/2012 15:30, David Kastrup wrote:
Reinhold Kainhofer reinh...@kainhofer.com 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
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unbound variable GUILE error when no whitespace before closing brace
James pkx1...@gmail.com writes: On 5 February 2012 07:30, David Kastrup d...@gnu.org wrote: 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. Thanks, I have no problem with that, it's just a case of 'If I made that mistake then someone else sure will', and wanted to make sure I understood why and if we need to warn users in the doc. We already do :) from the LM 'However, whitespace is required to separate many syntactical elements from others. In other words, whitespace can always be added, but not always eliminated. Since missing whitespace can give rise to strange errors, it is advisable to always insert whitespace before and after every syntactic element, for example, before and after every curly brace.' Well, that is talking about LilyPond itself (which tends to separate more rather than less except when in lyrics), and I have not seen anybody write c ' ' ' ! ? 4 ^ \p - . yet because of that somewhat overboarding advice. It may be worth mentioning that Scheme expressions not ending on a closen paren will generally need a following space in order to let the Scheme reader hand back control to LilyPond. Other than that, the spacing advice is mostly relevant for lyrics. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Unbound variable GUILE error when no whitespace before closing brace
Hello,
Just investigating some old Tracker issues I came across that
\new Staff \with { \override StaffSymbol #'staff-space = #0.9 }
\relative {
\times 2/3 { d16[ d16 d16] }
}
compiles
but
\new Staff \with { \override StaffSymbol #'staff-space = #0.9}
\relative {
\times 2/3 { d16[ d16 d16] }
}
Doesn't.
--snip--
GNU LilyPond 2.14.1
Processing `test.ly'
Parsing...
test.ly:14:58: error: GUILE signaled an error for the expression beginning here
\new Staff \with { \override StaffSymbol #'staff-space = #
0.9}
Unbound variable: 0.9}
test.ly:15:1: error: syntax error, unexpected \relative
etc.
--snip-
Note the lack of white space after the '#0.9'
This occurs on 2.14.1 and 2.15.28.
I guess I've been strict with my spacing or never had braces that
close to an override to notice this before.
I assume this is expected if not nice behaviour. I'm curious only
because I am wondering how a '}' would be a variable and why it isn't
ignored or just signalled (if that is the right term) as a close of
the previous open brace?
Regards
--
--
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unbound variable GUILE error when no whitespace before closing brace
James pkx1...@gmail.com writes:
Hello,
Just investigating some old Tracker issues I came across that
\new Staff \with { \override StaffSymbol #'staff-space = #0.9 }
\relative {
\times 2/3 { d16[ d16 d16] }
}
compiles
but
\new Staff \with { \override StaffSymbol #'staff-space = #0.9}
\relative {
\times 2/3 { d16[ d16 d16] }
}
Doesn't.
Sure.
--snip--
GNU LilyPond 2.14.1
Processing `test.ly'
Parsing...
test.ly:14:58: error: GUILE signaled an error for the expression beginning
here
\new Staff \with { \override StaffSymbol #'staff-space = #
0.9}
Unbound variable: 0.9}
test.ly:15:1: error: syntax error, unexpected \relative
etc.
--snip-
Note the lack of white space after the '#0.9'
Sure.
This occurs on 2.14.1 and 2.15.28.
I guess I've been strict with my spacing or never had braces that
close to an override to notice this before.
I assume this is expected if not nice behaviour. I'm curious only
because I am wondering how a '}' would be a variable and why it isn't
ignored or just signalled (if that is the right term) as a close of
the previous open brace?
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:
dak@lola:/usr/local/tmp/lilypond$ guile
guile 0.9}
ERROR: Unbound variable: 0.9}
ABORT: (unbound-variable)
guile dak@lola:/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.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unbound variable GUILE error when no whitespace before closing brace
Hello, On 5 February 2012 07:30, David Kastrup d...@gnu.org 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: dak@lola:/usr/local/tmp/lilypond$ guile guile 0.9} ERROR: Unbound variable: 0.9} ABORT: (unbound-variable) guile dak@lola:/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. Thanks, I have no problem with that, it's just a case of 'If I made that mistake then someone else sure will', and wanted to make sure I understood why and if we need to warn users in the doc. We already do :) from the LM 'However, whitespace is required to separate many syntactical elements from others. In other words, whitespace can always be added, but not always eliminated. Since missing whitespace can give rise to strange errors, it is advisable to always insert whitespace before and after every syntactic element, for example, before and after every curly brace.' Hooray! James -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
