[Top][All Lists]
[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.
- Re: New read/eval Scheme syntax inconsistent in handling existing code, Valentin Villenave, 2011/12/01
- Re: New read/eval Scheme syntax inconsistent in handling existing code, David Kastrup, 2011/12/01
- Re: New read/eval Scheme syntax inconsistent in handling existing code, Valentin Villenave, 2011/12/01
- Re: New read/eval Scheme syntax inconsistent in handling existing code,
Valentin Villenave <=
- Re: New read/eval Scheme syntax inconsistent in handling existing code, David Kastrup, 2011/12/01
- Re: New read/eval Scheme syntax inconsistent in handling existing code, Valentin Villenave, 2011/12/02
- Re: New read/eval Scheme syntax inconsistent in handling existing code, David Kastrup, 2011/12/02
- Re: New read/eval Scheme syntax inconsistent in handling existing code, Valentin Villenave, 2011/12/02
- Re: New read/eval Scheme syntax inconsistent in handling existing code, David Kastrup, 2011/12/02
- Re: New read/eval Scheme syntax inconsistent in handling existing code, Valentin Villenave, 2011/12/03
- Re: New read/eval Scheme syntax inconsistent in handling existing code, David Kastrup, 2011/12/04
- Re: New read/eval Scheme syntax inconsistent in handling existing code, David Kastrup, 2011/12/04
- Re: New read/eval Scheme syntax inconsistent in handling existing code, David Kastrup, 2011/12/04
- Re: New read/eval Scheme syntax inconsistent in handling existing code, Valentin Villenave, 2011/12/04