Sec.11.7 [italics]package arguments.

[vrotney@vaxa.isi.edu]

In the spirit of making CLTL a slightly  better   specification,  what
about the following extension?

On page 182, extend the statement

	"Any argument described as a package name may be either
	 a string or a symbol."

 to

	"Any argument described in this section as a package name
	 or package may be either a string or a symbol."

--------------------------------------------------------------------------------
Post Script:

After sending the above message I realized that someone may  interpret
it too  literally.   My original  message on this  indicated  that the
functions in Sec.11.7 created a  "misinterpretation  portability trap"
or what  ever you want to call it. The  above is a  suggestion  for an
extension  that  means  that all  arguments  in  this  section   named
[italics]package,  be allowed to be a string or symbol, as they can be
in some implementations.   I suppose the extended sentence above could
be worded better to help define what something described as a "package
name"   means. For example,

	"Any argument described in this section as a package name
	 may be either a string or symbol. Any argument designated
	 as [italics]package may be a package, string or symbol."

In other  words,  reqardless  of what most of us think CLTL says these
package  arguments can or can not be, a good future extension might be
to specify exactly that all of these package  arguments  (except for a
few) be allowed to be a package, string or symbol.


Bill Vrotney USC/ISI
-------