From: Alan Post <alanp...@sunflowerriver.org> 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 _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users