The LISP-EXTENSIONS Package.

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
    Subject: The LISP-EXTENSIONS Package.

    I'm not saying that there any common extensions.  I'm just saying that
    we should all agree to put our extensions in the same package, just like
    we agree to put our system hacks in the SYSTEM package.  Then the
    CLtL could say "hey, any implementation-specific extensions are in
    the LISP-EXTENSIONS package.  Look there to find all kinds of goodies."

Are you arguing that people should do (APROPOS "" "SYSTEM") and try calling
things that look fun? Each implementation will have to document its goodies,
and in that documentation they can tell you any package you want. There is
no reason for CL to standardize on that package name and a lot of reason for
CL not to (read on)...

    I'm only suggesting we agree on the package name, not on the contents.

The problem is that if one writes:

 (DEFUN FOO (X) (LISP-EXTENSIONS:FROB X))

they may find out that FROB is defined differently in two different systems. 
When a program is written for one implementation and later ported to another,
you may get no compiler warnings since the compiler may not realize that 
the LISP-EXTENSIONS:FROB you're calling is not the one you meant.

Consider the following awful situation, where two implementations have 
FROB1 and FROB2, but where the two have oppposite meanings...

     (DEFUN FOO (X)
       (COND (X #+SOMETHING (LISP-EXTENSIONS:FROB1 X)
		#-SOMETHING (LISP-EXTENSIONS:FROB2 X))
	     (T
	        #+SOMETHING (LISP-EXTENSIONS:FROB2 X)
		#-SOMETHING (LISP-EXTENSIONS:FROB1 X))))

This program is very hard to look at. The following program is not much
prettier, but is a least something which one can begin to fathom at a glance...

     (DEFUN FOO (X)
       (COND (X #+SOMETHING (MY:FROB1 X)
		#-SOMETHING (YOUR:FROB2 X))
	     (T
	        #+SOMETHING (MY:FROB2 X)
		#-SOMETHING (YOUR:FROB1 X))))

This actually comes up in things like file manipulation tools, math (especially
trig) functions, and other such things where the concepts have well defined names, 
but where the exact datatypes and ranges of inputs and outputs can vary widely.

I agree with those at Symbolics who've said there are good reasons for our
having picked SCL: for Symbolics extensions and not dumped all that in 
a standardly named package. At least if SCL:symbols are read into another Lisp,
you'll know right away that you have a portability problem -- an effect which
I have found to be an important -aid- to portability.