This makes sense, but I guess I don't see, still, how this might get the beginner into too much trouble. Pedagogical methods and statements will always not quite stay true to the letter of the spec. When we teach, we say one thing "is like" another, or you "might understand this by comparing it to foo," knowing well that the concept isn't actually foo. This is never meant to confuse the student, but to help them get in the right position to actually understand something.
But still, I get your point. Certain diligent students might read that statement and, rationally, read a lot into the terms "namespace" and "binding," and then get confused when they look up those terms in the hyperspec. It does come across careless in this way. But I just don't think, in itself, this would lead to a confusion about what packages are good for, or why they are used. Whether a beginner wrongly considers a package a namespace, or something like a namespace, wouldn't affect the way they would decide to actually use a package in their work. (Not to disregard how an experienced, real-lisp-understander might use their precise knowledge of the way packages work to make even better/cleaner/organized code.)
But either way, thank you for the thoughts, and please take my thoughts with a grain of salt.
The problem is not so much with the use of the word "namespace" per se, but with saying that packages are name spaces for symbols. That's just wrong, and is in direct conflict with the definition of things that are actually talked about as name spaces for symbols, most notably, variable and function bindings. The difference is that the domains of these "name spaces" are disjoint. The domain of packages is the set of strings, but the domain of (say) lexical variable bindings is the set of symbols. So, for example, lexical environments and dynamic environments are name spaces for symbols because their domains are symbols. If you insist on thinking about packages as name spaces (which no one actually does, which is another reason the sentence is misleading) then they are name spaces for strings, not for symbols.
I get the impression that the original quote from the book is using "name space" as it's used in other languages outside of CL, except that the book is from 1992 so not sure if that usage was widespread yet - maybe in C++? But it's almost like they wanted to say "a package is analogous to a name space as it's used in [algol-derivative]." Definite potential for confusion there, since "namespace" has a very specific meaning in CL and in general helps explain the difference between Lisp-1 and Lisp-2 (Lisp-n) varieties.
The quote is in the Preface, which is outside of the book itself. The same paragraph acknowledges that "packages can be very confusing for Lispers who have not learned about them in an organized way" and that the author has "seen experienced, Ph.D.-level Lispers hack away, adding qualifications to symbol names in their code, with no understanding of the organized structure of the package system." Furthermore, he adds that "[t]he reasons that packages are even more confusing in Lisp than in other, compiler-oriented languages, such
as Ada, is that in Lisp one may introduce symbols on-line, and one typically stays in one Lisp environment for hours, losing track of what symbols have been introduced. A symbol naming conflict may be introduced in the course of debugging that will not occur when the fully developed files are loaded into a fresh environment in the proper order."
After that, nobody in their right mind should be hanging on to any preconceived notion that they might have spun out of the earlier phrase "multiple name spaces of symbols", and should be reading the actual book.
> nobody in their right mind should be hanging on to any preconceived notion that they might have spun out of the earlier phrase "multiple name spaces of symbols"
Except that "namespace" is a term of art which is actually defined in the Common Lisp standard, and so it is not unreasonable to suppose that this is the intended meaning in a book on Common Lisp.
namespace n. 1. bindings whose denotations are restricted to a particular kind. ``The bindings of names to tags is the tag namespace.'' 2. any mapping whose domain is a set of names. ``A package defines a namespace.''
So if "the bindings of names to tags is the tag namespace", that means that a set of bindings of names to symbols is a symbol namespace!
According to the Common Lisp Glossary, the values of the dictionary define what the namespace is of. Of course the keys are always names; that's what makes it a namespace.
Also, look: "a package defines a namespace" (and it must be one of symbols).
You're not catching crafty old Shapiro red-handed in anything here.
> So if "the bindings of names to tags is the tag namespace", that means that a set of bindings of names to symbols is a symbol namespace!
No, that does not follow. Even if one were to admit the parallel construct here, the result would be "the symbol namespace" which is clearly nonsense.
Neither "tag namespace" nor "symbol namespace" is a term of art, so here we are in the domain of natural language, and natural language is irregular and ambiguous. In natural language usage, a "namespace for symbols" is one where symbols are the domain, not the range. In particular, the most common usage is to distinguish between Lisp-1 and Lisp-2, where the former has a single namespace for symbols and the latter has at least two, one for values and one for functions.
But still, I get your point. Certain diligent students might read that statement and, rationally, read a lot into the terms "namespace" and "binding," and then get confused when they look up those terms in the hyperspec. It does come across careless in this way. But I just don't think, in itself, this would lead to a confusion about what packages are good for, or why they are used. Whether a beginner wrongly considers a package a namespace, or something like a namespace, wouldn't affect the way they would decide to actually use a package in their work. (Not to disregard how an experienced, real-lisp-understander might use their precise knowledge of the way packages work to make even better/cleaner/organized code.)
But either way, thank you for the thoughts, and please take my thoughts with a grain of salt.