[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Tuesday, 5 April 1988 12:55-EDT
From: ELIOT at cs.umass.edu
There is the impression that this feature introduces an
unacceptible inefficiency in programs.
From the data that is available it seems that this is just being
scared of the dark. It is also possible that my data sample is
The code I analyzed was Lisp Machine system code.
Last year, I wrote a window system in Common Lisp. I needed a simple
flavors system to support it. My generic function dispatcher used
&REST and APPLY to pass arguments from the generic function to the
method handling the generic function.
Since the window system was used everywhere in our product, we needed
maximum efficiency in time and space. We found that &REST CONSing was
taking time and space we couldn't afford (the things it was doing to
the freelist! :-) So much so that we had to make it a general shop
policy not to use &REST.
Maybe this is an issue of "the compiler writers should be smarter."
But we're a startup. We can't wait for the compiler writers to get
smarter. For that matter, we can't wait for an &REST replacement.
If Common Lisp wants to be commercially viable, it needs to address
these issues in some form, however inelegant it may be to have to
worry about them.
There are certainly ways around using &REST in a flavor system. But
they're bulky, cumbersome, and take time to write and debug. Time
that we needed to spend writing the body of our product. Our choice:
use &REST and be too slow and too large, or program around it, making
it a useless feature.
I'm not sure what the "correct" replacement/extension for it is, but
in my experience, &REST \can/ be too slow and too space consuming
for use in a real, deliverable product.