New issue: DEFPACKAGE

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

Here are my responses to comments received.  My next message will be a
revised version of the proposal.

    Date: Sat, 12 Mar 88 19:14 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    I support the general idea of this proposal, but have a few nits to pick...
      * I think IN-PACKAGE is broken for being able to demand-create a package.
	It serves two unrelated roles, one of which being selection and the other
	being creation. Extending it to allow more keywords will worsen the problem.
	Given DEFPACKAGE, I would rather see IN-PACKAGE incompatibly changed to NOT
	allow demand creation. This would fix a lot of bugs.

Agreed, but I think that should be a separate proposal.  Added to the
discussion section.

      * There might should be a :SHADOWING-IMPORT-FROM.

Agreed.

      * I think that all options listed as symbol/string should be string-only.
	People should be discouraged from naming symbols before the package structure
	is fully in place. I'll stop short of suggesting that :IMPORT-FROM and
	:SHADOWING-IMPORT-FROM completely replace :IMPORT and :SHADOWING-IMPORT,
	which still muck with symbols.

I disagree because of alphabetic case issues in strings.  Note that in
these symbol/string arguments, the symbol is being used only for its
name, so there are never any package issues.  For instance, in :EXPORT,
if a symbol is given, the symbol that is exported from the package is
not necessarily that same symbol.  It's a symbol with that name in the
package being defined.  After looking at CLtL's writeup of SHADOW again,
I changed all of these to be symbol-only.

      * I'm surprised you left out the Genera :INCLUDE feature, but I guess that
	could always be added later if it was seen to be desired so it's ok.

I was not trying to propose any extensions to the semantics of packages.
(:INCLUDE is a Zetalisp release 4 compatibility feature that allows using
package A to automatically imply using package B as well.)

      * :PREFIX-NAME is mentioned only in the same. To have it in an integrated fashion,
	you'd need a PACKAGE-PREFIX-NAME function and some discussion of that it was
	automatically a nickname if not explicitly in the list of names or nicknames.

This was an editing error.  I didn't mean to propose the prefix-name
extension.  (Prefix-name provides control over which name or nickname of
a package the printer uses when printing a symbol.)

    Date: Sun, 13 Mar 88 16:31:26 PST
    From: Pavel.pa@Xerox.COM

    Just a nit for the moment:
	    ``A keyword standing by itself is an abbreviation for a list (keyword T).''

    This doesn't appear to be very useful, since none of the options will commonly
    want to have an option-argument of T.

Right.  This should have been in the part about implementation-dependent options.
I seem to have been pretty careless in the editing of this proposal.

    Date: Sat, 12 Mar 1988  19:46 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    This looks good, as far as it goes, and the fact that it has actually
    been tested in practice is a big plus -- it tends to give one confidence
    that nothign critical has been overlooked.

Thanks.

    I'm a bit uneasy about the syntax that you propose for the options.  It
    would be more compatible with the rest of Common Lisp to use alternating
    keywords and arguments.  Some users may find the odd syntax of your
    DEFPACKAGE to be confusing.  Is there some real advantage to the syntax
    you propose, or is this just a bit of Zetalisp culture peeking through?

Symbolics has a very large number of macros that work this way, and we have
found it to be easier to use and less confusing than alternating keywords
and arguments.  For one thing, it decreases the common confusion among both
naive and experienced users, in which they think they are supposed to put
in a ' in front of an argument when invoking a macro, as they would when
calling a function.  Another point is that the semantics of duplicated
keywords is different.  In a function call, Common Lisp specifies that
duplicate appearances of a keyword argument after the first are to be
ignored.  In a macro, duplicate options should certainly not be ignored;
either the options should be combined in some way or an error should be
signalled, depending on the semantics of the particular option.  I really
believe that a list of option name and arguments is the best syntax for
macros that take a bunch of options that are really a special-purpose
language for describing something.

With CLOS, Common Lisp will acquire several more macros that use this
syntax for options, which should make it less of a surprise to users who
have not seen this before.

    Date: Mon, 14 Mar 88 01:10:57 PST
    From: Eric Benson <edsel!eb@labrea.Stanford.EDU>

    This syntax resembles that used for DEFSTRUCT options, so it does have
    a precedent in CLtL.

Right.

    Date: Mon, 14 Mar 88 08:59 EST
    From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>

    DEFSTRUCT (which nobody has ever accused of having non-`odd' syntax) also suffers
    from the same non-&KEY-style.

    The saddest things is that this type of syntactical lossage has infected
    CLOS DEFxxx, probably because of the precedent in DEFFLAVOR.  I personally
    dislike the whole style; unfortunately it seems that few others feel strongly
    enough about this issue to raise objections.

I have to strongly disagree with you here, for the reasons alluded to earlier.