Re: Don't use => in COND...

[Bob Strong <csi!bs%UUCP@YALE.ARPA>]

    Date: Tue, 16 Jul 85 12:14:27 EDT
    From: Ashwin Ram <Ram@yale>
    To: T-Discussion@yale

    . . .

       (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,

It does:

> (test-compile (lambda () (cond (p => (lambda (x) q)) (else r))))
. . .
;;; Optimized result:
(LAMBDA () (IF P Q R))

                                                    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".

If the problem is in the "kernel" of your system, then why don't you just
compile it.  I don't think it is in the charter of STANDARD-COMPILER to
produce breathtakingly efficient code.  It does, however, want to do its
job rather quickly.