Tom Lord <lord@emf.emf.net> wrote:
+---------------
| ...please also explain why `if' should switch on anything
| other than boolean values (#t and #f), and why `and' and `or' should
| accept and return non-booleans.
+---------------
I dunno, perhaps those *should* be cleaned up...? ;-} ;-}
+---------------
| Shouldn't we also remove `=>' from `cond' and restrict it to booleans, too?
+---------------
Well, personally, I've never been very happy about that particular wart
in "cond", myself. "Cond" is already defined to yield the value of the
test if the test is true and there are no further expressions in the
branch, so as a "cond" branch:
(value => func)
is just the same as:
(value (func value))
or if "value" has side-effects or is so complex as to consume
excessive cpu-time when recomputed, then:
((let ((x value)) (and x (func x))))
In the former case, writing the alterate form is just as simple. In
the latter case, usually the complexity of the "value" form dwarfs
the added complxity of the "let". IME, I simply haven't seen a large
number of "in between" cases where "=>" is clearly preferable. But as
usual, YMMV.
However, the suggestion of restricting "cond" to booleans creates a
problem with eliminating "=>" as shown above, since R5RS "3.5 Proper
Tail Recursion" requires that if the "cond" is in tail position then
the procedure called by "=>" be in tail position. Yet the rules for
tail expressions in 3.5 don't seem to require that the "test" expression
itself be in tail position in the special case that the test is true
and there are no subsequent expressions in the branch (and thus the
value of the branch is the value of the test). That is, given a "cond"
branch like this:
(value => func)
3.5 requires the call of "func" to be tail call (if the "cond" is in
tail position itself), but AFAICT does not require the same for the
call to "func" in *this* branch:
((if value (func value) #f))
[even though if the "if" itself were in a tail position then the call
to "func" would be, of course]. Or this one, which is how "=>" is
normally thought of as being implemented under the covers [and which
is indeed how R5RS "7.3 Derived expression types" defines it!]:
((let ((x value)) (if value (func value) #f)))
Methinks before we can start mucking about with restricting truth
to only "booleans" there'd have to be a *lot* more examined and
possibly changed or at least clarified in other parts of the spec.
[E.g., defining the tail-ness of the test position in a "cond".]
-Rob
-----
Rob Warnock, 30-3-510 <rpw3@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [R.I.P.]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaanalyst@sgi.com and zedwatch@sgi.com aren't for humans ]