CLIM mail archive
Re: reducing time overhead of text display (in 1.1)
> From att!BBN.COM!stony-brook.scrc.symbolics.com!SWM Tue Dec 21 13:11:57 1993
> Date: Tue, 21 Dec 1993 12:42 -0500
> From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
> Subject: Re: reducing time overhead of text display (in 1.1)
> To: email@example.com, clim@BBN.COM, chyde@BBN.COM,
> I forget what the issue was named, but user programs are not allowed to
> add new "properties" to symbols that are defined by dpANS. That is, you
> can't say (DEFVAR CAR 20) (I think), or (as Peter points out) you can't
> define a compiler macro for FIND (for example).
Right, and as Steve Haflich noted (thanks) this is clear and makes sense
from CLtL2 p.260.
[If you have the hefty dpANS proposed standard description it's in there too.]
> By the way, if a built-in function is "poor (not efficient)", the *very
> last thing in the world you should do* is redefine it. You should send
> a clear bug report to your Lisp vendor. **Poor performance is a bug**,
> and you should report it as a bug. This is the only way Lisp
> implementations cn continue to improve. If you just silently fix stuff,
> you are doing the whole community a disservice.
I personally don't redefine built-in functions, so this was only intended
as a last resort, and this is what I expect a vendor patch to do for me.
Sometimes however you need a fix before you can get a patch file: e.g. being able
to redefine a built-in and know your code will still run could be essential for
a live system.
Main Index |