bug-lilypond
[Top][All Lists]
Advanced

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

Re: New read/eval Scheme syntax inconsistent in handling existing code


From: Valentin Villenave
Subject: Re: New read/eval Scheme syntax inconsistent in handling existing code
Date: Thu, 1 Dec 2011 22:22:37 +0100

On Thu, Dec 1, 2011 at 9:57 PM, Valentin Villenave
<address@hidden> wrote:
> Unfortunately, it does not.

[Oops, sent it a bit too soon.]


This used to work, for instance:


myvar = { b'4 }

#(display "this needs to be here")

#(eval-string "(define-public myvar #{ a'2 #} )" )

\new Staff \myvar

... And now it doesn't. For some reason it produces a "wrong type"
error. No matter whether you use $ or #. (So the breakage seems
unrelated, but it did happen at the very time the syntax changed. And
in proper REPL, non-embedded guile it does work.)

>> It looks like you complain that something that did not work before now
>> can be kept from working when you rewrite it in a special discouraged
>> and completely unnecessary way that is documented to work just as badly
>> as # did before my changes.
>> If that's the worst effect on your scores you can come up with, I can
>> live with that.

Well, as I said it *does* break all of my scores.
And I certainly can understand why such ugly things are discouraged,
but with **my** limited coding abilities I couldn't find any other
(more proper) way.

>> Or do you actually _rely_ on the wrong evaluation order for some strange
>> reason?  If you do, you'll be able to use $ (possibly in connection with
>> *unspecified* to avoid interpretation) to get things evaluated in the
>> old unnatural order.

Yes, I figured that much (so far I used to jump through several hoops
to work around the behavior).

Cheers,
Valentin.



reply via email to

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