Redefinition of CL Functions

[Jeffrey Rosenking <ROSENKING@A.ISI.EDU>]

To: common-lisp@SAIL.STANFORD.EDU
Cc: rosenking@A.ISI.EDU
Subject: Redefinition of CL Functions
------------------------------------------------------------------------

13-Apr-87 18:57:41-EDT,3913;000000000001
Return-Path: <@SAIL.STANFORD.EDU,@diamond.s4cc.symbolics.com:DCP@QUABBIN.SCRC.Symbolics.COM>
Received: FROM SAIL.STANFORD.EDU BY USC-ISI.ARPA WITH TCP ; 13 Apr 87 18:53:02 EDT
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87  15:28:26 PDT
Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by navajo.stanford.edu with TCP; Mon, 13 Apr 87 15:24:54 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75945; Mon 13-Apr-87 09:53:51 EDT
Date: Mon, 13 Apr 87 09:57 EDT
From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan <RAM@c.cs.cmu.edu>,
        masinter.PA@xerox.com, Jim Kempf <kempf%hplabsc@hplabs.hp.com>,
        Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
        Mike Hewett <HEWETT@sumex-aim.stanford.edu>,
        common-lisp@sail.stanford.edu,
        navajo!Common-Lisp%sail@navajo.stanford.edu
In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>,
             <RAM.12293665189.BABYL@C.CS.CMU.EDU>,
             <RAM.12293670645.BABYL@C.CS.CMU.EDU>,
             <870411-154536-1554@Xerox>,
             <8704120544.AA05619@hplabsc>,
             <8704130006.AA04788@bhopal.edsel.com>,
             <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU>
Message-Id: <870413095719.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Sun, 12 Apr 87 22:24:43 PDT
    From: Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>

    As someone more concerned with using Common LISP and in
    the portability of it, I can't believe any responsible 
    software engineer would even think of redefining a
    CL-defined function, macro, or special form.

I agree, and the implication (or my inference) is that there are
irresponsible engineers, or even the responsible ones make mistakes.

    Therefore, the question of allowing redefinition is purely
    a CL environment implementation question, and I would think
    that it should be perfectly legal to protect the user from
    himself and not allow redefinition.

I agree here too.  Various implementations do protect the user. The
Symbolics implementation does this by remembering the source file of the
original definition, and if the new source file doesn't match it
queries.  This applies to all functions, not just the core language.

I agree here too, too ! In response to the discussions above (Hewett, Masinter, Plummer, and Steele),
and my feelings on the subject, I THINK that the CL standard should support 
a mechanism to, at least, warn the user if he attempts to redefine a CL-defined
function, macro, or special form [ or perhpas initiate an error, though I 
believe that this will not coincide with the tradional flexibility which LISP
has always had ]. The Symbolics implementation [of a redefinition WARNING 
mechanism] would be a good model for the analagous CL mechanism, and it has
the advantage of working for the definition of all functions, not just those
which are strictly CL-defined. I BELIEVE that this mechanism is an essential
part of a language, especially one which was mainly designed to support 
portability and commonality among various LISP implementations.

                          -: Jeff 
-------
-------