Language extensions (formerly [italics]package arguments.)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 17 Apr 87 11:16:15 mst
    From: John Diamant <diamant%hpfclp@hplabs.HP.COM>

    > Or they can provide a "mode" in which extensions are
    > disabled as much as possible, to help users assure portability of "pure
    > CL" code.  Conformity with the standard only means that an implementing
    > will correctly run correct CL programs.

    O.K.  I stand corrected.  It is not a violation of the standard  per-say
    to  provide  such an  extension.  However,  to do so without a mode like
    what  you  describe  or a  flag  that  provides  warning  messages  when
    extensions  are used is doing a grave  disservice  to the user.  This is
    really  the same  issue as the list of  exported  symbols  from the LISP
    package.  Nowhere  in CLtL  does it say  that  extra  symbols  can't  be
    exported,  but you make  portable  code  virtually  impossible  to write
    unless you require that.  I believe the same is true for any  extension.
    It must be  clearly  delineated  either by being in a  separate  package
    (possibly  shadowing the symbol in the LISP  package) or it must provide
    some kind of feedback  that the operation  just  performed is not Common
    Lisp.  That  CLtL  does  not  discuss  issues  like  this  is, I  think,
    extremely unfortunate.

It does discuss this, on pages 1 through 3.  (It discusses just the
philosophy and doesn't get down to specific cases.)  I think that providing
tools to ease writing of portable code is a fine idea, and vendors should
do so.  I violently disagree with the idea that any implementation that
does not come with a 100% perfect set of such tools is not Common Lisp.

Note that CLtL pp.1-3 says that Common Lisp is a common dialect to which
each implementation makes any necessary extensions, and that Common Lisp
is designed to make it easy to write programs that depend as little as
possible on machine-specific characteristics, but does not say that
Common Lisp's purpose is to support writing of only programs that are
100% painlessly portable.  Common Lisp would be a lot less interesting,
and a lot less widespread, if that were so.