> From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

    > 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