issue DEFPACKAGE

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Comments on comments received.  I'll keep it as brief as I can.

    Date: Thu, 13 Oct 88 14:34:04 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    A question was raised at the meeting about having macros signalling
    errors during expansion at compile time.  Macro expansion time is the
    obvious time for signalling a syntax error for an unrecognized option
    and I think that should be made clear in the standard.

Sure, but I hope we don't have to address this separately for each and
every macro.

    I presume it's the intention of the proposal that the expansion of
    DEFPACKAGE should be wrapped with an (EVAL-WHEN (EVAL COMPILE LOAD)

I don't know about mandating that specific implementation, especially
when the definition of EVAL-WHEN is in flux, but certainly the idea is
that writing a DEFPACKAGE form at top level is sufficient to inform
the compiler of what you mean.  It's usually good practice to put
DEFPACKAGE forms into separate files, in which case the issue does
not arise, but I don't think we need to forbid putting a DEFPACKAGE
form in the same file as a program.

    Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?

What is the motivation for not having DEFUN call the function?
That's not a joke, my point is that the two operations of defining
a package and switching the current package have little to do with
each other and are rarely done together.

    Date: Mon, 17 Oct 88 17:19:14 -0700
    From: peck@Sun.COM

    I suggest that the :INTERNAL option be renamed :INTERN.

Right, that was a mistake on my part.  :INTERN is right.

     Please verify for me that if there is no :USE clause, whether
    the created package will use....

The default for DEFPACKAGE is the same as for MAKE-PACKAGE, and is
the subject of a separate cleanup issue.

    Clarify that the order of the clauses in the source code has no effect.

Right, good point.

    Date: Fri, 21 Oct 88 18:52:57 PDT
    From: Jon L White <jonl@lucid.com>

    re: I presume it's the intention of the proposal that the expansion of
	DEFPACKAGE should be wrapped with an (EVAL-WHEN (EVAL COMPILE LOAD)

    This should be covered the "normal" way, like any other defining form

Right.

    Date: Fri, 21 Oct 88 19:10:42 PDT
    From: Jon L White <jonl@lucid.com>

    I'd prefere to see the :EXPORT option renamed to
    be :EXTERNAL rather than introduce a gratuitously new keyword [note
    that symbols present in a package must be either :INTERNAL or :EXTERNAL.]

I strongly object to removing the analogy between the names of these
options and the already existing package functions.  :INTERNAL instead
of :INTERN was a typographical error on my part.

    re:                                            . . . Like all USE'ing
	this should be deferred until after the shadowing is done, no?

    Ooops, I guess you're right.  Shadowing that creates new symbols isn't
    important; but shadowing that in effect "blocks" the inheritance of two 
    different symbols with the same name must be done before the "using".

That's correct.  It's not hard to figure out in what order the options
should be processed, but part of the idea of having DEFPACKAGE is that
only implementors have to figure that out.

    I guess the more clear way to say what was intended here is that the
    evaluation of a DEFPACKAGE form does not change the value of *package*.

Right.