Package solution "motivation"

[wile@ISI-VAXA]

I was afraid of that.  Everyone jumped on the complaint and ignored the
proposal.  I'll complain more succinctly in a separate message.

The problem I am trying to solve, as a producer of software that
manipulates program specifications and implementations, is to allow my 
users to be as unconcerned with packages as possible.

I have written a system, called Popart, which takes BNF grammars extended
with regular expressions and operator precedence, a produces a parser,
lexical analyzer, pretty printer, pattern matcher, (old style) structure
editor, and transformation system for the language written in that grammar.
Of course, I have tried to integrate the facility consistent with Common
LISP conventions, rather than just deeming packages "red herrings" to be
ignored.  Generally, our use of Popart will be to allow users to specify
the functionality of their application in a language we call Gist,
transform that specification into a language we call Will, which will be
automatically compiled into Common LISP.

Yesterday's comment that "the user must have a firm model of the package
structure" is right on.  Consider the packages involved in the scenario
above:

  Grammar parse tree structures
  Grammar constants
  Grammar grammar parse tree structures
  Grammar grammar constants
  Transformation definition language parse tree
      "     "      "   "      "  "   constants
  Transformation definitions themselves (their names, like
     divide-and-conquer, duplicate-arm-motion-removal, ...)
  User Gist symbols (Gist application package, e.g. relation names, 
     agent names)
  User Will symbols (e.g. demon names, type definitions)
  LISP and below

Obviously, creating the right defaulting mechanism is very important here.

The first major decision was to put all grammar constants (begin, end, +,
etc.) in the keyword package for all grammars.  I would prefer to put them
into the uninterned symbol (non)package, but I don't know how to read into
that package.  The reason I would prefer to do this is partially an
efficiency issue.  If I could read symbols that way, I could decide to put
the (few) symbols whose packages matter (names of functions, defined
entities in the users' languages) in that package.  The only option I seem
to have is to read everything into the user's package and change them into
grammar constants when I see that that name has been used in the grammar.
Perhaps I could read everything into the keyword package, but I had visions
of creating lots of garbage keyword symbols.  I don't know...  Reading the
symbol uninterned and then deciding where to intern it seems conceptually
the right hook.  Thus, the proposal to allow read an optional functional
parameter to decide where to put the symbol.

[Incidentally, the other defaults:

  Grammar grammar parse tree structures are in the parser's package.
  Transformation definition language parse trees are in the transformation
     system's package.
  Transformation definitions themselves are in the grammar's package for
     which language they are transformations.
  User Gist and Will symbols are in packages defined (used) by the user
     (just as function definitions, variable definitions, etc., are in
     Lisp)
]

Sorry for the vitriolic attack.  (I'd tried to make it many times before,
with no proposed solution, so I'd resisted.  I thought I was being positive
with my proposal.)  Perhaps now you understand my frustration...

   Dave Wile