[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CLARIFICATION: [italics]package arguments.
- To: email@example.com
- Subject: Re: CLARIFICATION: [italics]package arguments.
- From: John Diamant <diamant%hpfclp@hplabs.HP.COM>
- Date: Fri, 17 Apr 87 11:16:15 mst
- Cc: firstname.lastname@example.org
> Would you please show us where in CLtL it says that accepting package
> names is forbidden, and required to signal an error?
"Must" means "must." This means that it "is an error" to do otherwise.
Whether it signals an error or attempts to interpret what the user meant
is at the discretion of the implementation. That means, at the least
that the program was not a correct CL program. However, the second
point applies here (see below).
> Or they can provide a "mode" in which extensions are
> disabled as much as possible, to help users assure portability of "pure
> CL" code. Conformity with the standard only means that an implementing
> will correctly run correct CL programs.
O.K. I stand corrected. It is not a violation of the standard per-say
to provide such an extension. However, to do so without a mode like
what you describe or a flag that provides warning messages when
extensions are used is doing a grave disservice to the user. This is
really the same issue as the list of exported symbols from the LISP
package. Nowhere in CLtL does it say that extra symbols can't be
exported, but you make portable code virtually impossible to write
unless you require that. I believe the same is true for any extension.
It must be clearly delineated either by being in a separate package
(possibly shadowing the symbol in the LISP package) or it must provide
some kind of feedback that the operation just performed is not Common
Lisp. That CLtL does not discuss issues like this is, I think,