On namespaces

Motto : i suppose the question of lisp standardization, soon to be visited upon our fair republic, will be one helluva burning flame.

Here's some preparatory work, then, by means of adnotation upon an old Naggum email.

Subject: Re: Which one, Lisp or Scheme?
From: Erik Naggum
Date: 1997/02/03
Newsgroups: comp.lang.lisp,comp.lang.scheme

* Steve Austin
| I'm very much a newcomer to Common Lisp, and I naively assumed that the
| originators of Scheme used a common namespace to simplify the syntax of
| higher order functions. What advantages do separate namespaces provide?

as others have observed, there are (at least) two schools of thought here.

however, I'd like to approach this issue from a natural language point of view, instead of a formal language point of view. clearly, if you define a formal language to have only one namespace, you can argue all sorts of things from there, but the question is not ex post facto arguments, but rather the genesis of the idea.

I suspect this is the earliest statement of "causes ; not purposes" in Naggum's work. Certainly the earliest I so far found.

in natural languages, we are used to context. indeed, contextual meaning is what makes natural languages natural. we have `list' as a verb, and we have `list' as a noun. we have `listless' as an adjective describing something (like a programming language) that does not have lists, and an adjective describing someone who is sort of permanently tired. when we need to disambiguate, we do so with more words.

This actually misses the all-important mechanism. "When we need to disambiguate, we add more words such as to contradict one of the two possible solutions the string could eval to". Natural language is nothing beyhond "add a_ixⁱ terms until P has only one real root." and in this vein we could introduce for instance the only viable model to evaluate poetry : how deep is the space explored, and how precise the sliver of interest chiseled out ?ⁱ

in Common Lisp, I can call some temporary variable `list' without having removed my ability to create new lists with the `list' function. like the natural language equivalent, `list' is both a verb and a noun, both a function and a variable. I find that this rhymes very well with me, and I also find that I would have severe problems if I could not use a word in a natural language just because it was "used up" by another part of speech. English is more prone to this than many other languages, but I happen to like English, too.

Except the argument for "multiple namespaces" has not been made. In point of fact what is being described is that in the sole namespace ever possible CL regards function.list as different from variable.list, even though some CL IDE some guy was at some point using opted to elide all the "variable." headers of all the variables as not contextually relevant. The fact that my penis isn't relevant to the discussion right now doesn't mean I don't have one ; and the fact that you don't need to see variable. in front of all your variables similarly doesn't imply it's not fucking there.

why is just one namespace bad for you? first, name space management is difficult. it is made more difficult by the lack of packages or other means of creating new namespaces. it is made more difficult by any means that artificially increase the collision rate of names. most languages that try to scale have had namespace manipulators added to them. e.g., in K&R C, struct members shared a single namespace, which nevertheless was different from that of variables and functions. ANSI C made each struct a separate namespace. C++ introduced the pervasive typedef, which not only made class names a new type, but also a reserved word, which leads me to the second reason. by having one namespace only, you effectively create a new reserved word every time you name something globally. in Common Lisp, you can't redefine the functional meaning of symbols imported from standard packages, but you can use them in (almost) any other way, and you can (must) declare that you intend to shadow symbols. in Scheme, you need to be careful that you don't redefine symbols you will later need in their global sense.

The collection of inherited kludges is not necessarily all that interesting in the direct. Obviously incorrect exposure of the path, not just to the eyes but also to the mind, is dangerous to the mind in question, as it's liable to start taking the local for general and "filenames" for identifiers.ⁱⁱ

various counter-measures are necessary if you have only one namespace. e.g., in C, the standard prescribes certain prefixes as belonging to the compiler and the rest are up for grabs among modules that you might want to link with. of course, using lexical scope, you reduce the impact of this problem. still, you can't use reserved words where they have no other use than to make the compiler barf. `default' is a perfectly reasonable variable name. then, some compilers will introduce new reserved words just for fun, like `try' and `catch'. Scheme, lacking both a package system and a useful number of namespaces, open up for namespace management problems that we know so well from large C programs (C being slightly better than Scheme in the namespace division). a single namespace in the linker also forced C++ to include a gross counter-measure appropriately called "name mangling". lacking packages, lacking symbol types, lacking everything, a C++ name as seen by the linker is some _implementation-specific_ junk that makes life "interesting" for everything that wishes to talk with the C++ modules. as a counter-counter-measure against the collision-avoidance that you need in one namespace, C++ has C linkage (extern "C") as an option to make names visible in a predictable namespace.

The fact that C grew "from the ground up" and they tried to retrofit it with a namespace rather than design one from the beginning is very poor an argument. Yes the linker need-driven namespace recreation looks exactly like Norma Bates (yes, arguably scheme's version looks more like Norman Bates' mom -- so ?).

now, C and C++ are language we love to hate, and the more we know the more we hate them, partly because of these problems, but my point is that Scheme is even _less_ scalable because of its severe restriction on names, and doubly so because Schemers, like most Lispers, like descriptive names, not cryptic naming conventions in somewhat less than 8 characters, which means that artificial naming in Scheme looks a lot worse than artificial naming in C.

it is often said that small is beautiful. now, anything can be beautiful when it is small. the ugliest person you can think of was probably a quite pretty baby.

This is patent nonsense. Most babies are ferociously ugly, and very often exactly the ones that'll in time grow into the prettiest girls. In any case about half of the real knockouts were not good looking during puberty. There's really no good relation here -- and I'd know, I looked.

it doesn't take much effort to find a beautiful 16-year-old girl, either. in fact, our modern notions of beauty and elegance are _defined_ in terms of size and maturity, so the chance of anything small and immature being beautiful is vastly higher than anything big or mature. now, despite all the marketing that seems to be aimed at telling me that I should dump a girlfriend when she becomes 25 and get a new 16-year-old (or even younger), I plan to stay with mine partly because of her ability to grow older in a way I like.

I can't begin to imagine who is the membership of that "our" ; but I expect an approximation of "nobody". Yes this sexuate species is sexually oriented towards geting the cap off the young girls ; but that anyone likes them is a whole 'nother matter, one that needs a little more thought given than a superficial scratch.

In any case -- nothing new has yet been beautiful, nor could it ever have been. Just like idiots can't have ideas, beauty is a function of familiarity not immaturity.

consequently, I take exceptions to the pedophilic attitudes to beauty and elegance that our societies have adopted over the years. this is why I don't like the "small is beautiful" model of aesthetics.

The model is misstated : simple is beautiful.

That simplicity in the description of ideal objects is readily conflated with shortness ; and that shortness of a thoroughly different type is readily conflated with immaturity in a completely disjunct namespace (which is just another word for "context", in context, isn't it) leads the misfortunate intellect down a path steeped in nonsense -- and you know exactly what I mean by the cracks and tears the simpler representation of namespaces I proposed above left in your previous "understanding" of the subject.

The relation between simplicity and shortness is slight ; the relation between simplicity and novelty entirely absent.

this is why I think that almost anybody could make something small and beautiful, but only a few can create something that grows from small to huge and still remains beautiful.

Like, for instance, a cell. Yes ? Is it beautiful ? Could you make it ?

but then again, look at interior architecture -- with huge spaces come a need for size-reducing ornamentation. the scaling process _itself_ adds "junk" to what was "clean surfaces" in a small model. Schemers refer to Common Lisp's "warts", and prefer to think of Scheme as "clean". now, I wonder, would Schemers prefer to live in small houses with nothing on their walls? would they still prefer this if the walls were a 100 feet high and 200 feet long, or would they, too, desire some ornamentation that would have looked _very_ bad if it had been on a 10 by 20 feet wall?

Yes.

I don't personally live in any space with ceilings at 30 meters. This is by choice, if I wanted to live in a railroad depot I very well couldⁱⁱⁱ. I don't. I do however own and operate spaces that fit his description. They are industial properties applied towards industrial uses, and no, a chunk of solid concrete suddenly protruding from a wall is not acceptable -- even recently serious expenditure was approved to cut the damn thing out, lest who knows when in the future someone's caught with their pants down in between unexpected circumstance and the "wall decoration".

The walls of large spaces are smooth for very good reasons, specifically that accidents on their surface would break the faculties for summation of the human brain in exactly their most vulnerable spot, and conceivably with dire consequences ; but even without this the "interior decoration" line falls apart, something that was to be expected from the onset -- I don't think there's many fields in worse a shape than this misfortunate catchall where all the women dumb enough to marry the sons dumb enough to pursue a career in politics end up vomited.

Scheme's single namespace is a function of its size. Scheme with more than one namespace _would_ have had bags on its side -- it would be very inelegant. however, as applications grow and as Scheme environments grow, the single namespace becomes disproportionately _small_. therefore, people resist a growth path that would have been natural, because their notion of beauty forbid it. Common Lisp with a single namespace would be confined and forbidding, for the same reason. an analogy may be in order. in very small towns, houses may have unique names. as the town grows in size, this becomes too hard to even imagine working, and houses are instead numbered, and the number space is managed by a street name. as the town grows more, streets in neighboring towns it merges with may have the same name. but towns have names, too, and states may have many towns. the United States has lots of towns with the same name. there are even towns that bear the name of countries in the global namespace. some people may still wish to name their house, but it would be foolish to hope that that name would be globally unique.

Yet if I mention in the opening lines of a new novel the Tribune tower you know the action's taking place in Chicago, right ?

Look how fucking beautiful it is :

• geoloc.usa.texas.paris != geoloc.france.ile-de-france.paris
• geoloc.usa.illinois.chicago.tribune-tower =
  geoloc.usa.illinois.chicago.n-michigan-ave & geoloc.usa.illinois.chicago.e-illinois-st

Problem ?

all over the place, we invent namespaces to manage the huge number of things we deal with.

"Inventing" namespaces is a little like inventing gods : only inenarrable imbeciles engage in the activity.

"Inventing" namespaces is a lot like inventing "feelings" or "academic disciplines" or "genders" : the sure mark of the antisocial failure busy at work trying to destroy the world.

in Scheme, there are few things to deal with, so few names are necessary. in Common Lisp, there are many things to deal with, so means to keep names apart is _necessary_. in consequence, Common Lisp has packages and symbol slots and namespaces.

Yes, means to keep them apart are necessary in the general ; but this doesn't imply the proposed means are meaningful, or useful.

why is a single name space bad for you? in addition to the reasons given above, I'd like to add

If he were honest, he'd confess it's because the pantsuit in him takes issue with the implications of authority and control that flow from there, even if that flow is purely in the manner and of the substance of dreams. He just dun like monotheism, what! Africa 4 eva!

a problem as a conclusion: nothing restricts your growth path more than a restricted ability to name your inventions or creations. the psychological factor known as "cognitive load" imposes a very heavy burden on our design, namely by having to avoid excesses in that load. a single namespace is good if you have few names, and more than one namespace would be bad. at some size of the set of names, however, a single namespace becomes bad because what you once knew (namely, what a symbol meant), _ceases_ to be rememberable. namespaces introduce context to a language. I think communication without context is a contradiction in terms, so naturally I applaud such introduction.

#\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.

No body of work is larger than Trilema ; and Trilema uses a single name space to name all my creations (all the way down to the character level : http://trilema.com/2018/on-namespaces/#selection-335.144-335.145) without impediment. Does it seem my growth is all that restricted ?

1. In this view machines fail at natural language because it is a combinatorically intractable problem, strictly speaking -- much like drones fail at being dragonflies. Quick, which kind of drones did I mean ? And how did you know that ? And how would have perl known that ? And how many watts ? [↩]
2. Have you noticed, incidentally, how insistently repeated the errors central and typical of UStardianism are, in UStardian practice ? "Here is everywhere" doesn't just ridicule the fucktarded middle class girlie of "upper class ideals" or the equally fucktarded working class girlie of "I myself sing". A lisp hacker from Oslo (who "mysteriously" prefers English) has the exact same fucking problem, he sees "list" and thinks that's all that's there! Just like they do it in Paris!

   Yes, yes, you like Naggum. So do I -- probably more than you. But I don't like the bits of nonsense embedded in the nougum, and if you "don't care" you may be well served by doing some thinking as to where they led him. [↩]

3. Understand, the world is full of obsolete ones to be had for cheap. For this reason it wouldn't even be expensive, to me, technically speaking, so it's not an idle "I could", it's a very factual "I grind ten tons of potatoes a week for pulp, if I wanted to eat some I very well fucking could". [↩]