[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: no constants please
Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
> >>>>> "Tom" == Tom Lord <lord@xxxxxxx> writes:
> Tom> Either way, these "constants" wind up having exactly the same style of
> Tom> interface as SCHEME_ENTER_* rather than a special case interface that
> Tom> refers to their traditional implementation using immediate
> Tom> representations.
> OK, point taken. But why is that a reason to have SCHEME_FALSE()
> instead of SCHEME_FALSE? (Alternatively: why does Scheme allow EQ? to
> work on booleans, and use #f instead of (false)?)
I have no objection to exactly which C function should be used to
check for falsity. My insistence is that it should always look like a
function, and not like a C constant; nor should C's == be used to
compare Scheme objects.
There may well be more than one C object which all collectively
represent the same Scheme object, and which are eq? to each other, but
not == to each other.
So the SRFI better not constrain an implementation.
It cannot promise to a C programmer that SCHEME_FALSE is a constant,
hence it should be SCHEME_FALSE() which returns a false value.
Then it cannot promise that the following tests whether foo is #f:
foo == SCHEME_FALSE()
so it must have something like
This is about making sure that the C syntax does not forclose certain
sensible Scheme implementation strategies.