Re: Keyword extensions to Compile

[hpfclp!diamant@hplabs.ARPA]

   From: hplabs!preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
   
   > From: hpfclp!diamant@hplabs.ARPA
   > The problem with making the default environment the extended one is
   > that it is IMPOSSIBLE to write portable programs!  If implementation X
   > makes an incompatible extension to COMPILE, and I want the CL-only
   > environment so I can use the CLtL version of COMPILE, I must say
   > something like: #+X (progn (unuse-package 'lisp) (use-package
   > 'cl-only))  ; or some other non-standard package name
   ----------
   You're combining the important objection to "some other non-standard
   package name" with the objection to the default environment.  They're
   separate issues.  I think the name of the pure CL package should be
   standard (probably it should be lisp), but I think the default

It is at least as important that the extended environment has a standard name,
or you can't turn it off portably, if it is on by default.  Sure, you can
create your own package and explicitly use the pure package, but you can't
unuse the extended package from the USER package unless its name is
standardized.

   environment should be the local environment, including appropriate
   enhancements, and portable code should back off to the standard
   pure-CL package.  I don't want users to have to specify their
   environment at startup, even in a canned initialization file.  The
   default environment should be what corresponds to our implementation-
   specific users' guide.

I was aware that I was discussing both issues, but I apologize if it
was unclear from my comments above.  Let me explain why I consider these
related.  I believe that we should make the ANSI standard upward compatible
where possible with CLtL.  This requires that the pure Common Lisp package 
be called LISP.  Since CLtL also says that the default environment uses LISP
(MAKE-PACKAGE states this explicitly), and that the USER package uses LISP,
again the only way to make an upward compatible extension is to leave this
alone, and use another mechanism to get full-blown environment (such as a
global flag which is off by default).  Otherwise, people who have written
"portable" programs based on CLtL will have to change them (in a portable way)
to work on ANSI standard Common Lisp.  It is true, I am more concerned about
there being a pure lisp package, and its being called LISP, than about the
default environment.  My earlier objection about the impossibility of writing
portable programs hinges on the name of the extended package being
non-standard, and I see general agreement here that we must standardize that
name.  My concern about the default environment is based on upward
compatibility, and my concern about standardization of the name was to make
sure that it was still possible to write portable programs.
   
   But the name of the pure-CL package should obviously be standardized.
   
   -- 
   scott preece
   gould/csd - urbana
   ihnp4!uiucdcs!ccvaxa!preece
   

My proposal is that we define a function with a standard name that tells
MAKE-PACKAGE et. al. (and sets the values for the USER package) whether to
go by CLtL or to include the extensions package, which by then will have
a standard name.  So you would say something like:

(SET-DEFAULT-ENVIRONMENT 'LISP)   ; for bare CLtL
or
(SET-DEFAULT-ENVIRONMENT 'EXTENSIONS) ; for the extended environment

This would not only set the global flag, but change the use list of USER to
contain the package specified instead of whichever one it had.  This has to
be a function instead of a variable, because it must actively change the use
list of the USER package.  I would still prefer that this would be set to
LISP by default so that programs which are now portable don't need to change
when the ANSI standard comes out, but this way each user can set up (say in
an init file) his preference for getting a portable environment, or a "full"
environment.

Notice that this scheme has the added advantage of allowing the user to
specify an arbitrary default environment (he can make a package with any
mix of LISP, EXTENSIONS, or whatever -- even merge extensions from multiple
Lisps, if the source is available to him.

By the way, regarding the home package problem that KMP mentions, we need to
require that the home package of the symbols exported from the LISP package
(the pure one) are homed in the LISP package.


John Diamant
Systems Software Operation	UUCP:  {ihnp4!hpfcla,hplabs}!hpfclp!diamant
Hewlett Packard Co.		ARPA/CSNET: diamant%hpfclp@hplabs
Fort Collins, CO