S&I's idea of EQ?

[Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>]

I agree that the advantages of coalescing are implementation
dependent, but that is part of what I tried to point out in my
message: closures can be implemented in such a way that it is not so
clear that coalescing is necessary.  The reason some implementations
want to coalesce is precisely because closing is too expensive for
them (BTW, what's the difference between C and Scheme if closures are
so expensive that users avoid them like the plague?).  Note that the
optimization I suggested does not imply a high variable lookup cost, its
only added cost is the "cons", but it is more applicable than
coalescing and satisfies the procedures-have-locations semantics.

Besides, coalescing is not really necessary, since it is an
optimization which can be trivially accomplished by the user by
slightly rearranging his/her code.  On the other hand, if the
implementation is free to coalesce, the other behaviour can only be
obtained thorugh very obscure and unintuitive coding.  I'm not saying
that I agree completely with the philosophy that if an optimization
can be done by the user himself the implementation should not do it,
but it is something worth considering.

Again, I don't care that much, but I have not seen powerful reasons to
make the decision go that way.