> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Tom> SCHEME_FALSE, SCHEME_TRUE, SCHEME_NULL, and
> Tom> SCHEME_UNSPECIFIC should be functions, not constants:
> >> Why?
> Tom> [...] because, you never know, those constants might be
> Tom> heap allocated.
> >> That, AFAICS, doesn't mandate the above.
> Tom> Perhaps it would be clearer if I said that those constants may be
> Tom> _newly_ heap allocated.
> No.
> Tom> It isn't GC-safe to return values which may be unprotected from GC.
> Then GC-protect them.
Yes, that's the point. The way to GC-protect them is to ensure they
are protected when generated, before control returns back to the
consumer code.
The GC-safety issues jimb and I have pointed out mean that:
scheme_value x = SCHEME_FALSE;
is inherently not GC-safe. You must use either:
/* JNI/minor-style:
*/
scheme_handle x = SCHEME_FALSE (my_call_context);
or
/* Pika-style:
*/
SCHEME_MAKE_FALSE (&x, my_scheme_instance);
Either way, these "constants" wind up having exactly the same style of
interface as SCHEME_ENTER_* rather than a special case interface that
refers to their traditional implementation using immediate
representations.
> Tom> Anyway, why is it important to write them that way? You can't use
> Tom> them with == or !=.
> Why not?
You don't expect == to implement EQ? do you? I'm not sure what, if
anything, it could be counted on to implement reliably.
-t