[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] question about commit c157ff502829c6f2856df4a963d81a
Re: [Chicken-users] question about commit c157ff502829c6f2856df4a963d81a88ee241ebf
Wed, 08 Dec 2010 05:25:20 -0500 (EST)
From: Alan Post <address@hidden>
Subject: [Chicken-users] question about commit
Date: Tue, 7 Dec 2010 09:05:16 -0700
> I have a question about commit
> c157ff502829c6f2856df4a963d81a88ee241ebf, the change for detecting
> cycles in equal?
> The last change in runtime.c is as follows:
> @@ -3865,7 +3876,8 @@ C_regparm C_word C_fcall C_equalp(C_word x, C_word y)
> C_header header;
> C_word bits, n, i;
> - C_stack_check;
> + if(C_stack_test)
> + barf(C_CIRCULAR_DATA_ERROR, "equal?");
> if(x == y) return 1;
> Given that equal? returns either #t or #f, is it the case here that
> *if* we have detected circular data, is it by definition eq? to
> itself, and therefor rather than calling barf() here we can return
No, because two compared data-structures might be circular, yet
not made up of identical data.
> If that isn't true, could we perform this check later in this
> routine, say before we recurse rather than immediately upon
> entering? That would allow some non-recursive checks to run (and
> potentially succeed) before deciding that we really have to
> terminate. I think we could detect some cases of equality that this
> patch won't, because of the placement of this check.
> It seems that the stack check is placed in a "generic" location that
> would work with any potentially circular data, but in the case of
> equal?, the fact that it returns a boolean value means we can do
> better than "generic" code that might return any value.
Sorry, I'm not sure I understand - could you show an example of
such a case?