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

[David Kastrup]

Valentin Villenave <address@hidden> writes:

> On Fri, Nov 25, 2011 at 6:18 PM, David Kastrup <address@hidden> wrote:
>> Valentin, any more news of bad effects on your scores?  Apart from the
>> bug that should now be fixed?
>
> OK, I've now had a chance to test the staging code, it's certainly an
> improvement!
>
> ... Aand I'm blocked by another bug (or unwanted behavior) that
> affects nested levels of string evaluations.
>
> I have yet to track down the exact problem, but here's an example of
> the quirks I used to rely upon:
>
>
> myvar = { b'4 }
>
> $(eval-string "(define-public myvar #{ a'2 #} )" )
>
> \new Staff \myvar
>
>
> (Granted, this wouldn't have worked with previous versions either.

It wouldn't have worked but you used to rely on it?

> But the mechanism is the same.)

Huh?  That is just the old well-known premature evaluation order timing
problem that $ has inherited from #.

Write #(eval-string ... instead and the example presumably does what you
want.

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.

Apparently I lack the imagination to understand the nature of your
problem given this example.  Can you find an example that is better
suited to my limited capacities?

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.

-- 
David Kastrup