Problems with packages?

[Jon White <JLW@SU-AI.ARPA>]

Just to review, do we all agree that 
  (1) readtables, 
  (2) packages, 
  (3) dynamic variables *read-base* and *read-suppress* etc
all form part of a global database affecting the reader syntax, and that it
is a unique featue of Lisp that this database may be modified dynamically
by the user?  Perhaps a fourth point ought to be added:
  (4) packages do not solve, nor even address, the problem of lexicality.

Too often in the past several years I've seen persons who "come up" with
a solution to the problem of lexical variables by "putting them in
separate packages".  It takes a lot of explaining to separate out the
difference between syntax parsing and program semantics; perhaps it is
because Lisp is so lividly dynamic that this confusion is so easy to make.
On the other hand, the spate of conjectures as to what "lexical packages" 
might possibly mean leads to a situation, a variant of (4), which could be 
stated as:
  (5) lexicality does not solve, nor even address, the problem of packages.

Given this background, and the fact that the "lexical packages" discussion 
seems to have been started by a misunderstanding of "lexical" or "packages" 
or both, then I think we can best spend our broadcasted mail time focusing
on questions like the following:
  (A) What else besides the default setting of *package* should be added
      to the set of conventions?  is the ZetaLisp "Syntax:" command adequate?
      Of course there is *read-base*, but what else?
  (B) Must the editor settle all parsing/syntax related settings before
      even "loading" in the file ?  or can it wait until a READ operation
      is applied to some part of the buffer?  a "lazy" parsing.
  (C) What are reasonable conventions for scoping a database configuration?
      Is a file the appropriate scope?   What about streams that arent files?

Regarding (B), one may well ask why a line like
    (IN-PACKAGE "FOO")
is any more mysterious to a default-context parser than the line
;;; Package: FOO
Dill seemed to be asking this question in his note last week; one needn't
think that the former line has to be subjected to READ any more than the
latter one.  But the more lispy looking line *can* be interpreted by
the simple-minded read-eval-print loaded.

Weinreb seemed to summarize the differences between th ZetaLisp approach
and the SpiceLisp approach as the amount of importance attached to the
editor context problem.  I hope it will never be the case, such as it
is now in Interlisp, that one can create files which the standard system
tools cannot parse well enough to be able to edit (and, hence to fix
the silly little bug that managed to creep into them).  Admittedly it
doesn't happen often, but on those ocasions one must abandon the standard
program/file editor (in Interlisp) and drop down to some kind of text
editor to repair the damage.  [It is not, repeat not, such a simple 
thing to do to an Interlisp program file, for generally lots of low-level
things you never really wanted to know about will break when you "hand-
edit" a file, and you'll spend half an hour to half a day trying to
figure out random messages about "file maps" and so on.]


-- JonL --