Compiling CASE

[Rob MacLachlan <RAM@C.CS.CMU.EDU>]

    Date: Saturday, 11 April 1987  06:07-EDT
    From: Hvatum at MIT-MULTICS.ARPA
    Re:   Compiling CASE
     
    The package system will not protect Common LISP from having its
    functions redefined, since a user who wants to define his/her own CAR
    function will likely not call it USER:CAR; thus, since there is
    already a CAR in the LISP package, that's the one that will get
    defined.

This is what SHADOW is for.
     
    [...]  What if the function was not
    CAR, but (say) ENCODE-UNIVERSAL-TIME?  It is reasonable to suppose
    that Joe Lisphacker will not wish to look up every potential
    function name to see if it is already defined.  [...]

It is reasonable to suppose that programmers won't want to look up
every symbol before they use it, but it is not reasonable to redefine
system functions.  Programs that redefine system functions are not
portable for two reasons:
 -- You might redefine a system facility that other parts of the
    system depend on, for example, it you redefine
    DECODE-UNIVERSAL-TIME, our compiler will not work.
 -- Even if a program attempts to redefine a facility in an upward
    compatible way, that program cannot coexist with other programs
    that redefine the same facility an in incompatible upward
    compatible way.

Just as in COBOL, the programming environment should provide ways to
prevent users from screwing themselves by redefining the system.

    [...] It is also not reasonable for the compiler to reject this
    usage because it is an error to redefine ENCODE-UNIVERSAL-TIME
    [...].  It's also likely that the interpreter will make different
    choices in the same matter, probably all bad ones.

This is another good reason to forbid redefinition of standard
functions and macros.  If you allow redefinition, then you must
specify what the result is; this is difficult to do in the presence of
a variety of implementations of evaluation such as compilers and
interpreters.

Note on a point of dogma: it doesn't make any sense to say that a
construct is "Legal in Common Lisp but implementation dependent";
Common Lisp is nothing if not a specification of how to write portable
Lisp programs.  In some cases it is reasonable for Common Lisp to
suggest standard mechanisms for accessing common implementation
features, but programs that rely on such constructs having any
particular effect are not portable, and thus not really Common Lisp
programs.

  Rob