Issue: IN-SYNTAX?

[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?  It has always seemed
to me that the context sensitivity of LOAD/COMPILE-FILE has been a 
"throwback" to MacLisp days, where the standard input radix was octal!

But even if 99.44% of all programs never tamper with the improved syntax 
standards, I agree that there must be a reasonably convenient way to 
overide the "binding" parts of LOAD/COMPILE-FILE.  What would you think 
of the following avenues:

    (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]

    (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]

    (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.]


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.


-- JonL --