[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] question about commit c157ff502829c6f2856df4a963d81a88ee

From: Alan Post
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?");
   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

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.

.i ko djuno fi le do sevzi

reply via email to

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