Subject: Re: Which one, Lisp or Scheme? From: Erik Naggum <erik@naggum.no> Date: 1997/02/03 Newsgroups: comp.lang.lisp,comp.lang.scheme Message-ID: <3063960348777794@naggum.no> * 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. 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. 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. 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. 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. 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. 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. 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. 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. 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? 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. all over the place, we invent namespaces to manage the huge number of things we deal with. 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. why is a single name space bad for you? in addition to the reasons given above, I'd like to add 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.