Re: Commit 4778c7326d726f50f6ac541322006d6b90795945
"m...@apollinemike.com" writes: > Le Dec 6, 2011 à 2:01 PM, David Kastrup a écrit : > >> "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
Re: Commit 4778c7326d726f50f6ac541322006d6b90795945
David Kastrup writes: > "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" writes: > Le Dec 6, 2011 à 2:01 PM, David Kastrup a écrit : > >> "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
Le Dec 6, 2011 à 2:01 PM, David Kastrup a écrit : > "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" 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