Re: CLARIFICATION: [italics]package arguments.

[John Diamant <diamant%hpfclp@hplabs.HP.COM>]

> Contrary to what John Diamant suggested, I think that very few functions
> fall into category (1).  The vast majority seem to be in category (2).

After looking through several pages of CLtL, I see that you are right that
only a few fall in category (1).  However, it is still a major leap to
conclude (2) simply because the "must" is not listed for the function.  If
that were the intended interpretation, then a statement at the beginning
of the section should say that.  This is comparable to taking a word and
saying in this sentence it means "A" and in this other sentence it means "B."
It is still true that package means package, and not package name, so what
you are talking about is still an extension, not something that can be
concluded from the text.

> There wasn't a lot of discussion back then about these points -- certainly
> there was no serious objection to them.  Probably the HP folks weren't
> receiving the mail then?

Well, that's probably true.  I certainly wasn't, as I wasn't with HP 2
years ago.  Even if the mailing list was being received, it could have been
missed.  However, when interpretations like that are "added" to CLtL, we
need to be careful to record them for inclusion in further standards.
Standards don't do us any good if people decide to reinterpret them beyond
what is stated, simply because they don't like the standard.

Note that I have no objection to your proposed enhancement, but it requires
a clarification to the standard, not just a joint decision from some of
the implementors.

Regarding David Moon's comments: we will have to agree to disagree.  I believe
that any extension to CLtL should be clearly delineated or not included.
I would be much happier if CLtL stated how this delineation must occur
(explicitly requiring extensions to not be in the LISP package, possibly
shadowing symbols that are, for instance).  Portability is probably the
most important feature of Common Lisp, and I hate to see such a lack of
committment to it that if something isn't convenient because of portability
issues, we just ignore the portability issue.

	John Diamant