Porting Cl code

[Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>]

   Date: Tue, 20 May 86 17:16 EDT
   From: Kent M Pitman <KMP@arpa.scrc-stony-brook>
   Subject: Keyword extensions to Compile

   Let's stop talking "legal" for a while and talk "rational".
   ...

   I've spent some time in-house talking to our software support staff about
   problems they're going to come up against when dealing with CL customers
   and the worst one is going to be the fact that customers using CL are going
   to expect that porting CL code should be a breeze and are going to be quite
   surprised at the difficulties they can encounter. In my opinion, that's
   a fault of CL, not a fault of Symbolics or DEC or Lucid or whomever. 
   ...

I fully agree with everything Kent said in his message, and in particular that
(1) implementations should package extensions so that they do not make visible
changes in the basic language, (2) stricter implementations are better in that
code written for them will be more portable, and (3) portability problems are
often due to looseness in the specification.

(Consider, for example, compiling.  CLtL says very little about the compiler
and refers to most uses of EVAL-WHEN as "esoteric".  There is little to guide
a user (or implementor) who is not already familiar with a similar system, and
implementations of CL differ on default "eval-when times".  IN KCL, for
example, everything seems to be eval-compile-load, so it is very easy to write
programs that run interpreted and compile in KCL but do not compile in, say,
Lucid.)

One of the most common criticisms of Common Lisp that I hear, and such
criticism may be more common now in Europe than in the US, is that it is not
really a language but a collection of languages, and that it takes work to
port programs from one dialect to another.  In a sense, the whole point to
Common Lisp is to make porting easier; we should do everything we can to make
it so.

-- Jeff