[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] question about commit c157ff502829c6f2856df4a963d81a
From: |
Felix |
Subject: |
Re: [Chicken-users] question about commit c157ff502829c6f2856df4a963d81a88ee241ebf |
Date: |
Wed, 08 Dec 2010 05:25:20 -0500 (EST) |
From: Alan Post <address@hidden>
Subject: [Chicken-users] question about commit
c157ff502829c6f2856df4a963d81a88ee241ebf
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?");
>
> loop:
> 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
> 1?
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?
cheers,
felix