Re: [Chicken-users] question about commit c157ff502829c6f2856df4a963d81a88ee241ebf

[Felix]

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