guile-user
[Top][All Lists]
Advanced

[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



reply via email to

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