[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


OK, let me redefine the original problem. Maybe this 'makes' it an
environment issue. Given that I have two or more programs under
development. Why should my defining a macro in one program have an
effect on the other? Currently it does because I have changed the
default readtable. Changing my package from one program's package to
the other program's package used to be sufficent for a 'context
switch' but now I also have to change readtables. What I was
suggesting is that the readtable was defined inside of a package, and
in some sense should be part of that package. i.e. if I change the
default readtable, I am really changeing the default FOR A PACKAGE.
Packages are very much like contexts. If I have a package that has an
ancestor, it should inherit the default readtable from that ancestor.
If I redefine the default readtable, I do it locally, not to the
ancestor (unless I do so explicitly). 

Note that this is just a change to the DEFAULT readtable mechanism,
and does not constitute a change to other mechanisms already present.
If a prlog user wants to write code in the USER package, that's fine,
and he can use the prolog readtable. When he changes to the CL
package, he shouldn't still be stuck with the prolog readtable,
however, (and have to do something explicit to change it).

Now you could argue that I shouldn't be altering the default readtable
at all, and changing the readtable depending on the task involved
(rather than just changing packages, or whatever). But consider this,
given two programs in package A and B, where A has a macro bound to
#\! and B does not, this is what would be nice:

(pkg-goto 'USER)
<invoking !foo would mean !foo - no macro invocation,
 invoking A:!foo WOULD invoke the macro>
(pkg-goto 'A)
<invoking !foo would invoke the macro
 invoking B:!foo would NOT>

Note that this does not imply any change to the way readtables or
referenced. If mI want to talk about a readtable explitily, I may
still want to use variable, but each package might have associated
with it a variable *default-readtable*, and it is inheritable if it is

Now I will totally agree that whether this is a
basic/advanced/toplevel etc. issue is unclear to me. All I am stating
is that I think there is a need to do this sort of thing; it would be
nice that if everyone who said they supported CL supported this.
Also, does anyone else think similar thoughts, or am I out in left
field, since there are other existing easy ways to do this sort of
thing, and/or it has no business being in the CL language?

Brad Miller	 ARPA:	lab@rochester.arpa	UUCP:rochester!lab
			(also miller@rochester for grad student stuff)
			Title:	CS Technical Operations Manager
			 Snail:	University of Rochester Computer Science Department
			617 Hylan Building	Rochster, NY 14627