Compiling CASE

[Hvatum@MIT-MULTICS.ARPA]

From: Steve Bacher (Draper Lab)
 
  From: Rob MacLachlan <RAM at C.CS.CMU.EDU>
 
      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.
 
But the point is that it still requires a specific user action which
presumes knowledge that a built-in CL function is being redefined,
be it explicit package prefixing or use of SHADOW.
 
   ...it is not reasonable to redefine system functions.
 
True.  However, if a programmer uses a name like ENCODE-UNIVERSAL-TIME
as a "local" function (in the Franz sense?), such that the compiler
doesn't make its definition globally available, this should be no
problem.  I guess FLET is the solution here.  Otherwise, the LISP
system should probably issue a warning, and possibly rename the
function internally (where possible).
 
I do not have in mind "redefining" CL functions in the sense of
changing the behavior of pieces of the LISP system that use them.
Rather, I mean defining new functions which happen to have names that
are the same as existing CL functions.  If the system is set up so as
to protect itself properly from having pieces of itself suddenly
change their behavior, there should be no problem.  I think that if
guidelines similar to those above are followed, programs that define
functions with the same names as CL functions (NOT "redefine" those
functions) can be portable.
 
One more point:  If you say that portability precludes
implementation-dependent constructs, then we no longer have different
CL-compatible implementations - just a single CL implementation with
different code generators for different hardware.  Maybe this is what
we all REALLY want.  Who knows?
 
   Of course internal compiler representations are highly
   implementation dependent, but this isn't necessarily a problem.
   One of the main things that source code walkers have been used
   for is writing "optimizing macros" for non-optimizing compilers.
   As long as the compiler adequately optimizes the code, macros can
   expand in a simple-minded way without understanding their
   arguments.
 
Let's not try to unload the total optimizing burden on the compiler.
Surely there are situations where a macro is in a far better position
to know how to optimize a particular construct than the compiler,
whose job is to optimize the general cases.
 
Also, as far as internal representation of source code is concerned,
no matter how fancy your compiler is, there's always got to be a
phase where real source code is analyzed and converted to whatever
internal form you like.  Certainly transformations can be invoked
at that level.  What's more, user-written transformations necessarily
operate on the source code, unless a LISP implementation is required
to make its compiler's internal representation open for manipulation.
 
                                                  - SEB