no constants please Tom Lord (23 Dec 2003 23:06 UTC)
Re: no constants please tb@xxxxxx (23 Dec 2003 23:10 UTC)
Re: no constants please Michael Sperber (26 Dec 2003 18:31 UTC)
Re: no constants please Tom Lord (26 Dec 2003 19:24 UTC)
Re: no constants please Michael Sperber (27 Dec 2003 16:17 UTC)
Re: no constants please Tom Lord (27 Dec 2003 18:55 UTC)

Re: no constants please Tom Lord 27 Dec 2003 19:19 UTC

    > 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