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> Either way, these "constants" wind up having exactly the
> Tom> same style of interface as SCHEME_ENTER_* rather than a
> Tom> special case interface that refers to their traditional
> Tom> implementation using immediate 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'm not arguing for SCHEME_FALSE(), I'm arguing for either:
SCHEME_FALSE (my_call_record)
/*
* JNI/minor style: returns a handle not a scheme_value
*/
or
SCHEME_FALSE (&var_to_set_to_false[, my_instance])
/*
* Pika style: stores #f in an output parameter.
* (whether or not an instance parameter is
* required here is a separate issue).
*/
because something like those styles of interfaces are required for
GC-safety.
If it were just SCHEME_FALSE() then obviously there would be just:
#define SCHEME_POUND_F (SCHEME_FALSE ())
As for "why does scheme use #f instead of (false)": because Scheme
programs don't have to explicitly protect intermediate results of
expressions from garbage collection so there are no parameters needed.
Implementations are required to protect intermediates implicitly.
It's quite reasonable to regard all constants in Scheme as a special
syntax for applications of nullary procedures -- you could very well
regard #f just as shorthand for (false).
As for "why does scheme require EQ? to compare booleans as EQV? does":
Personally, I think EQ? is a historical wart on the language. But
more fairly, clearly the intention is to carve out an approximation of
EQV? which nearly all conceivable maximum-performance-concerned
implementations can optimize down to a bitwise comparison of two
1-word values. Meanwhile, implementations with other priorities
(e.g., small implementation size; simple implementation using C++
objects; etc) are free to implement EQ? as EQV?. If they do so, they
aren't paying any penalty that they care about. The FFI should
accomodate both kinds of implementation, though -- so it should not
assume that EQ? is distinct from EQV? or that EQ? is the same as C's
==.
-t