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.