This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> 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