Re: no constants please

[tb@xxxxxxxxxx (Thomas Bushnell, BSG)]

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

  SCHEME_EQ(foo, SCHEME_FALSE())

This is about making sure that the C syntax does not forclose certain
sensible Scheme implementation strategies.

Thomas