[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Errors using Guile 2.0 vs. Guile 1.8
From: |
Mark H Weaver |
Subject: |
Re: Errors using Guile 2.0 vs. Guile 1.8 |
Date: |
Sun, 29 Jan 2012 20:16:12 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Paul Smith <address@hidden> writes:
> On Sun, 2012-01-29 at 17:57 -0500, Mark H Weaver wrote:
>> Replying to myself...
>>
>> > The relevant difference is that in Guile 1.8, (define foo ...) returns
>> > #<unspecified>, but in Guile 2 it returns the 'variable' object for
>> > 'foo'.
>>
>> I actually think that this qualifies as a bug in Guile, so please don't
>> depend on this behavior. Ideally, (define foo ...) should always return
>> #<unspecified>, and I hope we can fix that in 2.0.4.
>
> This definitely is the culprit. If I add a #f to the end of my
> definition, so the result is #f, then it works fine. Ouch. That is
> going to be a bummer, and no two ways about it.
>
> Was this change present in 2.0/2.0.1/2.0.2 as well?
Yes.
> Either I have to recommend everyone add #f for portability, or else I
> have to modify my guile-to-make string conversion to map Guile variable
> objects to empty strings, which could cause compatibility issues in the
> future if we decide to do something "interesting" with those objects.
I think it would almost certainly be fine to map variable objects to "",
because I can't imagine why anyone would ever want to return a variable
object to 'make'. I agree that it's not ideal, but I can't imagine it
ever being a problem in practice.
I'll respond to your other question (about error handling) later.
Mark