Issue: IN-SYNTAX?

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

    Date: Fri, 28 Oct 88 15:46:31 PDT
    From: Jon L White <jonl@lucid.com>

    re: . . . be careful not to make it impossible to write
	programs that set up the environment that they know they want, and then
	call LOAD or COMPILE-FILE.  

    I wondered about this -- namely, is it necessary to provide backwards
    compatibility in exactly the same way it is done now, or would some
    slightly more kludgy replacement be satisfactory?  

I said don't make it impossible, not don't make it incompatible.  Of course
it would be better to be compatible, but that can be judged on its own
merits and might be outweighed by the esthetics of a new approach.

    ....What would you think of the following avenues:

I have another suggestion, which is to leave LOAD and COMPILE-FILE the
way they are, and add WITH-STANDARD-IO-ENVIRONMENT (a Symbolics Common
Lisp feature), which binds all of the variables to their standard values,
and say you should wrap this around calls to LOAD and COMPILE-FILE when
that's what you want.  The reason for WITH-STANDARD-IO-ENVIRONMENT rather
than LET is that you don't have to know all the variables to bind, and
indeed there might be implementation-dependent ones as well as all the
standard ones.

The only problem with this suggestion is that people might be calling
LOAD by hand as the way to load programs, and wouldn't like to have to
type in a WITH-STANDARD-IO-ENVIRONMENT form.  I suppose there are
probably still environments out there in which calling LOAD by hand is
the way to load programs.  But I would hope that more typically one
would call some kind of Load Program command, which would do the
WITH-STANDARD-IO-ENVIRONMENT for you.

	(1) have a keyword argument to LOAD/COMPILE-FILE that says "start
	    out in current syntax rather than in standard syntax"; or have
	    keyword arguments for all the syntax variables.
	    [Pro: simplest to user; Con: added complexity in general, and 
	     more work for implementors in particular]

I prefer the second of those two suggestions over the first of them,
it seems more consistent with the rest of Common Lisp.

In Symbolics Common Lisp, LOAD and COMPILE-FILE have a :PACKAGE argument
that does this.  However, we don't have arguments for the other things,
like base and readtable, because this is thought of as a way to override
what the file says via the -*- line.  In general our system is based
around the assumption that most files use the -*- mechanism for
specifying the attributes, which unfortunately Common Lisp didn't adopt,
and loading or compiling with the caller's attributes is an unusual case
seen only in a few straight Common Lisp programs.  It's also worth noting
that LOAD of a binary file always loads the file with the same attributes
it was compiled with, and if all implementations did this, the issue of
portable programs would be lessened, since compiled programs would always
be loaded correctly, and people who compile programs are no doubt more
careful than people who load them.

	(2) have all standard syntax specifications be user-accessible as
	    the values of special variables; thus ordinary lambda-binding
	    would suffice for tailoring the "standard" environment.
	    [Pro: makes the "primitives" user-accessible; Con: the set of
	    such variables might not be fixed between implementations, and
	    global-variable access to internal data is less "safe" than
	    a functional interface to it]

I agree with the Con.

	(3) have a documentary suggestion that when one wants to retain the
	    syntax environment, he should arrange such communication via
	    his own global variables;  e.g.,
	      (defun my-load (&rest args)
		(let ((*my-package* *package*)
		      (*my-readtable* *readtable*)
		      (*my-read-base* *read-base*))
		  (apply #'load args)))
	   then add the following statement at the beginning of any file
	   for which this hack is needed:
	       (in-syntax :package *my-package*
			  :readtable *my-readtable*
			  :read-base *my-read-base*)
	   [Pro: puts the burden on the weirdo who _really_ wants this;
	    Con: can work unless you can modify the in-syntax of the file.]

This does not appeal to me at all.

    By the bye, I've ignored *READ-SUPPRESS* and *READ-DEFAULT-FLOAT-FORMAT*
    til now.  Probably the former doesn't need to be redefinable by the
    IN-SYNTAX form, but surely it needs to be "protected" over LOAD/COMPILE-FILE.
    As to the latter, I don't have a great argument for it now, but I rather
    tend to view it as a global "site installation" parameter, rather than as 
    a useful dynamic variable; my mind would be changed if I heard of 
    significant "dynamic" use of it.

Outputting postscript.

The fact that there are several variables like this that people tend to
overlook is an argument for WITH-STANDARD-IO-ENVIRONMENT.