Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]

[Dan Carnese <CARNESE@SPAR-20.ARPA>]

My fault for dropping the ball on this discussion.

The two principal objections that have been made are:
	1) [RAM] Some uses of the proposed construct would not have
well-defined behavior under the current definition of Common Lisp.
	2) [JonL] Readability concerns argue that package structuring
should occur in a standard place.  This might be a special non-code file,
such as Mesa's module definitions, or at the start of each code file.

The response to 1) was:
	3) The new construct simply maps to existing ones.  Thus, if you
can define the correct behavior for existing constructs, the new one will
behave properly as well.

Although not explicitly stated, the response to 3) from Rob seems to be:
	4) Allowing package-related operations to occur anywhere in a file
is itself problematic and perhaps will be removed as part of a solution.
Since the proposed constructs will result in such operations, the constructs
should not be added to the language.

Here's where I pick up the ball again.  Suppose the language is changed so
that package operations are determinable without evaluating forms.  The
obvious ways to do this are compatible with the new construct.
	5a) The langauge could be changed so that a set of special forms
evaluated at read time would perform the package operations.  This might
involve changing existing functions (e.g., in-package and export) to have
read-time semantics, or introducing new functions which have such
semantics.  In either case, the proposed constructs would macro-expand into
a read-time export followed by the standard definition.
	5b) The langauge could be changed to require a standard header
which would not consist of forms to be evaluated, i.e., the file attribute
list approach.  Then the standard behavior for the proposed constructs
while reading a file would be to verify that the symbol being defined has
in fact been exported.  Of course it should also be possible to have the
constructs export the symbol rather than signalling an error, based on the
value of a global variable.

Under either of these approaches, the use of the proposed constructs can
allow the programming environment to help the user in the construction and
maintenance of export lists.  Editor commands such as "create export
declarations from exports of package", "compare export declarations with
current exports for package", and "undefun and unexport symbol" could be
defined.  Their availability would mean that the tedious task of keeping
the export declarations up to date could be largely automated.

The proposals involved objection 2) are similar to those described in 5b),
so the same line of reasoning applies.
-------