Re: I suppose I have to put in my two cents about DEFSUBST

[George J. Carrette <GJC at MIT-MC>]

Remember a while back when JONL objected to my suggestion
(at the time directed at JKF and &PROTECT), that open-coded
functions simply LAMBDA-FY? He mentioned the same thing you
do now, "an unusably slow compiler". Well, since then we have
talked about it a bit, and I showed him a way to "cache" information
 from DEFUN's so that you can get very close to doing it *right* 
without duplicating a lot of computations in the compiler.

    Date: 13 NOV 1980 0234-EST
    From: MOON at MIT-MC (David A. Moon)
    To:   LISP-FORUM
    Re:   I suppose I have to put in my two cents about DEFSUBST

    There is, of course, a software engineering tradeoff as to whether
    you want to have to be somewhat careful about defining your
    open-codable functions so that simple textual substitution works,
    or whether you would rather have an unusably slow compiler.  The
    Lisp machine chose the former alternative although as the feasible
    memory size and processor power for a personal computer gradually
    increase the alternative of "doing it right" may become
    attractive.  "Doing it wrong" is not VERY wrong of course or we
    wouldn't have done it.

Its simply that your "engineering tradeoff" is a false dilemma,
the key is "as to whether *you* want to ... be somewhat careful about
defining your open codeable ...". Just who is *you*?

Lets take one of the simple cases:

(DEFUN FOOP (X) (NOT (MEMQ (TYPEP X) '(BAR BAZ))))

Even the simplest meta evaluator can tell you that a simple substitution
is 100% correct here.

Given any open compilation there are 3 areas of analysis
[1] Things you can say just by looking at the body of the defun.
[2] Things you can say just by looking at the actual arguments.
[3] Things which involve complicated interactions of body and arguments.

Obviously the information of [1] is that which is done by "people"
now, but it need not be. 

A combination of a good [1], (which may *reject* some candidates for
open compilation as being too complicated to be worth it), and
a simpleminded [2] ( basic SIDE-EFFECTS-P, CONSTANT-P, DEPENDANT-P),
seems to cover the existing uses for open compilation very well.

=> For each candidate for open compilation a decision method
   for doing the open compilation is compiled.
   [meta compilation]

I think the engineering tradeoff is one of how much time you want
to spend hacking the compiler vs. how fast it is vs. how good
it is. (vs. of course how the compiler influences coding style througout
the system).

-gjc