Packages then and now

[Jeff Barnett <jbarnett@nrtc>]

This note is in regargds to the recent conversation about packages.  First, a
few historical comments.  The first appearance in the LISP world was in LISP2
where global program pieces, e.g., special variables, functions, macros,
etc., where given a first and last name.  (The first name was an integer in
the range of 0 to 127.)  Symbols, then called identifiers, had only one
incarnation.  LISP2 was done in the early 1960's.  As far as I know, this
looked just like the mechansim used by IBM assemblers  from the
early-middle 1950's.  In both, there was a default package (first name) in
which to put definitions unless the name of the defined object included an
explicit  package.  Reference ambiguity was resolved, at compile time, by an
ordered list of package names.  If a symbol (rather than a full name) was
used, if there was a definition in the first package on the list it was used;
if not, the second one was tried, and so on.  For the record, packages were
called sections and the first name was really written second.
	The last attempt at a development along these lines was an
implementation called CRISP done in the mid 1970's.  In CRISP, symbols and
names were different kinds of objects: SYMBOLP and NAMEP were different
predicates and no object satisfied both.  There were subtypes of name, e.g.,
variable, function, function with partially specified interface, etc.  The
mechanism was to protect system developers from each other; not to protect
the system from the users.  A name object had fields for its binding, type
information (as specifically as known), its print name (two symbols) and junk
for the GC.  A symbol had fields for its printname, property list, and system
property list.  The system property list located all name objects with this
primary name, i.e.,  all objects with this name in all the packages in which
it existed.  The property list was tree structured.  A node on the property
list was a 4-tuple: property name, property value, rest of property list, 
and inferior property list.  The property functions took a list of
indicators, e.g.,
     (GET 'foo 'semantics 'lexicon 'phonetics)
Usually, the names of the first property was the same as a package name.
Most programs only used a single indicator while the layers below it used
two. Though the qualification string could be indefinately nested, more than
two indicators were rare.  Further, the name qualification was only one deep
though it could have been generalized.  It was not for two reasons: (1) it
didn't seem necessary and (2) the default rule became very complex.  A
finally historical note, these systems were meant for Programmers (with a
capital P).  They were not meant to separate the unwashed from each other.
In fact it is clear that, without change they cannot do the whole job.
	As to the current state of affairs.  I don't like the present package
system very much.  I happen to like the distinction between symbols as
universals and names of program pieces.  Unfortunately, in this
standardization effort, a change as radical as this would imply is probably
misguided.  What I hope is that there will be a variety of implementations
that experiment with the issues that bridge naming, encapsulation, and
presentation.  I don't know of an entirely satisfactory solution.  Judging by
the recent flames, I see that no one else does either.  The work on object
style programming in LISP will effect the future.  Don't forget, that it is
another mechanism whose stated purpose is similar: namely to allow
development of different programs in the same environment AND development of
the same program by multiple contributors.