[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Jon L White <firstname.lastname@example.org>
- Subject: Issue: IN-SYNTAX?
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 28 Oct 88 19:38 EDT
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <8810282246.AA16141@bhopal>
Date: Fri, 28 Oct 88 15:46:31 PDT
From: Jon L White <email@example.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
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*)
(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*
[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.
The fact that there are several variables like this that people tend to
overlook is an argument for WITH-STANDARD-IO-ENVIRONMENT.