Commit 4778c7326d726f50f6ac541322006d6b90795945
Hey all, I believe that the variable `clone' needs to be unquoted in commit 4778c7326d726f50f6ac541322006d6b90795945 (it is part of a quasi-quoted list). I haven't tested it thoroughly, but please give it a look and lemme know if this is indeed the case. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commit 4778c7326d726f50f6ac541322006d6b90795945
m...@apollinemike.com m...@apollinemike.com writes:
Hey all,
I believe that the variable `clone' needs to be unquoted in commit
4778c7326d726f50f6ac541322006d6b90795945 (it is part of a quasi-quoted
list). I haven't tested it thoroughly, but please give it a look and
lemme know if this is indeed the case.
No idea what makes you think that. clone is part of the generated
let*-form. There is some trickiness involved since the let* generates a
bunch of lambdas that could theoretically also access a variable called
clone in a closure the user defines.
However, since clone is the _first_ variable in the let* and does not
get its binding until all the lambdas have been created, there is no
conflict of interest.
You might try something like
#(display '#{ This #(and that) and $whatever #})
to better see how this works.
So apparently you have encountered a problem and believe this to be
related to the non-unquote of clone. It isn't.
How about reporting the problem you are actually seeing?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commit 4778c7326d726f50f6ac541322006d6b90795945
Le Dec 6, 2011 à 2:01 PM, David Kastrup a écrit :
m...@apollinemike.com m...@apollinemike.com writes:
Hey all,
I believe that the variable `clone' needs to be unquoted in commit
4778c7326d726f50f6ac541322006d6b90795945 (it is part of a quasi-quoted
list). I haven't tested it thoroughly, but please give it a look and
lemme know if this is indeed the case.
How about reporting the problem you are actually seeing?
If one defines a music function incorrectly and then tries to use it, i.e. :
foo =
#(define-music-function (parser location)
#{ a #})
\foo
One gets the following warning message:
Parsing...
foo.ly:4:1: error: GUILE signaled an error for the expression beginning here
#
(define-music-function (parser location)
Unbound variable: clone
fatal error: failed files: foo.ly
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commit 4778c7326d726f50f6ac541322006d6b90795945
m...@apollinemike.com m...@apollinemike.com writes:
Le Dec 6, 2011 à 2:01 PM, David Kastrup a écrit :
m...@apollinemike.com m...@apollinemike.com writes:
Hey all,
I believe that the variable `clone' needs to be unquoted in commit
4778c7326d726f50f6ac541322006d6b90795945 (it is part of a quasi-quoted
list). I haven't tested it thoroughly, but please give it a look and
lemme know if this is indeed the case.
How about reporting the problem you are actually seeing?
If one defines a music function incorrectly and then tries to use it, i.e. :
foo =
#(define-music-function (parser location)
#{ a #})
\foo
One gets the following warning message:
Parsing...
foo.ly:4:1: error: GUILE signaled an error for the expression beginning here
#
(define-music-function (parser location)
Unbound variable: clone
fatal error: failed files: foo.ly
That would likely be the list of predicates starting off as
(let* ((clone ...
that means, the first argument is of type let*, the second argument is,
uh, whatever. I don't see that the #{...#} can evaluate to anything not
looking like an arglist superficially.
(begin (let* (( ...
would be a predicate of begin followed by an optional predicate let*
with a value of (( and then you are again at a point where clone is
getting called.
define-music-function could possibly try to check for the most likely
programming errors and turn them into an error explicitly.
Frog task.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commit 4778c7326d726f50f6ac541322006d6b90795945
David Kastrup d...@gnu.org writes:
m...@apollinemike.com m...@apollinemike.com writes:
If one defines a music function incorrectly and then tries to use it, i.e. :
foo =
#(define-music-function (parser location)
#{ a #})
\foo
One gets the following warning message:
Parsing...
foo.ly:4:1: error: GUILE signaled an error for the expression beginning here
#
(define-music-function (parser location)
Unbound variable: clone
fatal error: failed files: foo.ly
define-music-function could possibly try to check for the most likely
programming errors and turn them into an error explicitly.
Frog task.
Well, for a frog liking scheming. ly:make-music-function is too late,
and the body of define-syntax-function is partly not late enough (it's
not in the right lexical context to look at the defined-ness of
symbols), partly too late (if the whole macro replacement contains
undefined symbols later on, creating a useful error message at its start
might prove tricky).
Well, at least the guile command line has no problem with
(and #f barf barf barf)
so if one uses the right special forms, one might escape this niggle.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Commit 4778c7326d726f50f6ac541322006d6b90795945
m...@apollinemike.com m...@apollinemike.com writes:
Le Dec 6, 2011 à 2:01 PM, David Kastrup a écrit :
m...@apollinemike.com m...@apollinemike.com writes:
Hey all,
I believe that the variable `clone' needs to be unquoted in commit
4778c7326d726f50f6ac541322006d6b90795945 (it is part of a quasi-quoted
list). I haven't tested it thoroughly, but please give it a look and
lemme know if this is indeed the case.
How about reporting the problem you are actually seeing?
If one defines a music function incorrectly and then tries to use it, i.e. :
foo =
#(define-music-function (parser location)
#{ a #})
\foo
One gets the following warning message:
Parsing...
foo.ly:4:1: error: GUILE signaled an error for the expression beginning here
#
(define-music-function (parser location)
Unbound variable: clone
fatal error: failed files: foo.ly
Pushed a few patches to staging making this blow up sooner more reliably
with symptoms easier associated with #{ #} and music lists.
Also I like the output of
#(write '#{ this $is #(it!) #})
better than previously.
It's not the same as an error handtailored to the mistake, but that is
actually astonishingly hard to do.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
