Re: reducing time overhead of text display (in 1.1)

• To: clim@BBN.COM, SWM@stony-brook.scrc.symbolics.com
• Subject: Re: reducing time overhead of text display (in 1.1)
• From: clarisse@iexist.att.com
• Date: Tue, 21 Dec 93 15:06:55 CST

> 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: clarisse@iexist.att.com, clim@BBN.COM, chyde@BBN.COM,
>         pnorvig@norvig.east.sun.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.
> 
Good point!
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.

• Prev: Re: reducing time overhead of text display (in 1.1) (now 2.0)
• Next: Re: reducing time overhead of text display (in 1.1) (now 2.0)
• Index: CLIM Mailing list (1-Jan-93 to 31-May-94)
• Thread: CLIM Mailing list Index (1-Jan-93 to 31-May-94)