Readtables

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

    Date: Mon, 28 Apr 86 20:01:23 EDT
    From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>

    NIL and the MIT/LMI-LISPM system had just such a mechanism, named readtables.
    (GET-READTABLE-NAMED "Maclisp") would be analogous to (FIND-PACKAGE "Maclisp").
    The mechanism was invoked by the good-old file mode line:
    ;;;-*-mode:lisp;readtable:maclisp;base:10-*-

    I suppose we will have to wait for the gods-on-high, er, I mean Symbolics REL7,
    before any discussion of "environment issues" can progress however. We
    all wait, breathless.

Give us all a break, George.  You used to, and possibly still do but I
can't tell since your mail originates from MIT, work for one of
Symbolics' comercial competitors whose system has the same roots as
Symbolics'.  The reason Symbolics people ask others to be careful about
the distinction between language and programming environment is because
we think about it every day as part of our work.  People at LMI, Xerox
and others probably do too.  People at Lucid (possibly the other end of
the spectrum) probably don't because their current business is to
produce a powerful compiler.  This also has nothing to do with releases.
We need to decide what is part of Common Lisp, the Language.  With the
multidimensional designations I've seen for the ISO Common Lisp, we need
to be even more specific.  Not only do we need to know if it is language
or environment, but we have to know what level (substrate, basic,
advanced, toplevel, etc) of each it is.

    Date: Mon, 28 Apr 86 21:38:33 edt
    From: Brad Miller(Tech. Ops. Mgr)  <lab@rochester.arpa>

    So you feel this is an environment issue rather than a language design
    issue? I would think the need and the solution (at least a proposed
    solution of formally folding it into packages) could be addressed at
    the language level: gives us portability of code; forces all vendors
    to address the problem, and other nice side effects...

A few questions: Why should readtables be folded into packages?
Consider the following, not too far-fetched, duple:
 - What's wrong with using a prolog readtable with the USER
   package?  The implication is that the user is writing code for the
   USER package, but the code is being written in prolog!
 - What's wrong with using a CL readtable in the PROLOG-USER package
   (which normally uses a prolog read-table)?  The implication here is
   that a prolog user is writing code, but is writing it in Common Lisp.
The current main differences between the interfaces to readtable and
packages that I can think of off the top of my head are the following.
 (1) Packages are globally named and seldom stored in variables, whereas
     readtables are not generally named but are stored in variables.
 (1a) To find a package one generally uses (find-package <name>).  To
     find a readtable one generally uses *foo-readtable*.
 (2) Packages cannot be copied for the purpose of modification.
     Readtables can, and this mechanism exists.
 (3) Because of (1) and (2), packages determine the identity of symbols
     for the lifetime of the incarnation of the Lisp in which they
     exist (which includes saving worlds and rebooting, etc).  Symbols
     are rather permanent in this sense.  Readtables, on the other hand,
     determine how TEXT is parsed into LISP.  By changing the readtable
     you can alter the parsing.  There aren't any "reasonable" ways to
     meaningfully alter packages to get similar effects.
 (4) If packages did not have names, we would be writing symbols as
     *foo-package*:print-name instead of foo:print-name.  But since this
     IS THE TEXT it is divorced from the readtable.  We currently don't
     have a way to say #@Maclisp ...maclisp-form....
 (5) The effects of in-package are the dynamic extent of the load
     operation of the file (see page 183).  I couldn't find an
     equivalent thing for *readtable*.

I personally don't have any problems with (1), (2) or (3).  I think the
current readtable paradigm is sufficient and adequate.

Regarding (5), I will cast a vote that the effects of
	(eval-when (eval load compile) (setq *readtable* *my-readtable*))
have the dynamic extent of the load operation in the same way
in-package does.  I will also cast a vote that a form should be
considered to capture the above notion.

Regarding (4), we need to decide if we want to add some functionality to
readtables that are parallel to packages.  Do we want to globally name
readtables?  Do we want an in-band way to change the readtable for one
or more forms?  The package system has its roots in experience, and it
still has problems.  Do people have enough experience with readtables to
feel comfortable about any of these issues?