Don't use => in COND...

[Ashwin Ram <Ram@YALE.ARPA>]

Having always considered the "=>" construct in COND a feature of T, I'm
now beginning to wonder if its implementation is more of a bug.  It turns
out to be inefficient with respect to cycles and horrible with respect to
cons cells.

   (cond (p => (lambda (x) q)))

expands to:

   (cond-=>-aux p
                (lambda () (lambda (x) q))
                (lambda () (lambda () **value-of-cond**)))

Now, cond-=>-aux is an integrable procedure defined in the T source as:

    (define-integrable (cond-=>-aux p f a)
       (if p ((f) p) (a)))

This means that two (lambda () ...) forms are evaluated (using up time
and cons cells) each time the COND is called, regardless of whether this
branch is taken or not, i.e., regardless of whether p evaluates to non-nil
or not.  Each time these two closures are set up and thrown away.
Presumably, TC compiles this inefficiency away, but STANDARD-COMPILER
does not.  Thus it is very inefficient (wrt both time and cells) to
use this construct, especially in interpreted code.  (I have statistics
collected from a rudimentary benchmark to back this statement up.  The
difference that was observed was unexpectedly high.)

We are developing a large AI system in T, and I find that we now have to
go back and rewrite the kernel of our system so that it doesn't use this
"feature".  Is this a bug in the STANDARD-COMPILER or have I just overlooked
some implementation issue?  It seems that this should be a pretty straight-
forward thing to implement efficiently...

Ashwin Ram.


-------