Readtables

[David C. Plummer <DCP@SCRC-QUABBIN.ARPA>]

I don't have any good answers for you right now, but I do have some
comments.  Your message does illustrate the issue quite well, thanks.

It could be argued that a different readtable is really implementing a
parser for a different language.  Indeed, the Symbolics implementatin
supports two languages on the same machine: Zetalisp and Symbolics
Common Lisp.  They do have different readtables and they also have
different package hierarchies.  There is a command (Set Lisp Syntax, I
think) I think that selects between the two and sets up all the
necessary environment variables, which include package and readtable.
The editor also knows about this.  This point of view says there should
be a concept of a 'language' which is the right collection of 'things'.

This thing of yours, however:
    (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>
would definitely be part of the language.  I'm not sure I like it
though because it is very surprising behavior (based on today's
paradigms).

As for your doing development on two or more programs, I think if the
compiler and loader bound *readtable* around the compile/load operation,
then you wouldn't have any problem because CLtL's development paradigm
is file-at-a-time operations.  This leaves two major areas, I think:
incremental development (which is programming environment) and using the
two programs (which isn't, or is at least fuzzy).

Incremental development usually means incremental editing and compiling
out of the editor buffer.  Here it would be nice if the editor knew what
the necessary variables in order to understand the language are.  This
could be an extension to the -*- line to the systems that do such
things.

Using the programs, or typing to "its reader" is the unclear issue for
me.  Currently, FOO: affects the translation from strings to symbols,
and you want it to affect the parsing of text at a more global level.  I
think that might be a useful thing, but I don't think : is the place to
put it, but instead something else (@?).  There is the question: Should
this affect the next form in that parser's language or should it affect
all forms until an escape in the other language switches back or out?