Subject: Re: Lisp's unique feature: compiler available at run-time
From: Erik Naggum <>
Date: 31 Jul 2002 18:44:53 +0000
Newsgroups: comp.lang.lisp,comp.object
Message-ID: <>

* Software Scavenger
| How would it be useful for a macro expansion to refer to the lexical context
| of its definition?

  If you have only one namespace for everything, which is a design flaw of
  Biblical proportions, you have to solve the problem that you have introduced
  to your programming environment by preventing a programmer's function and
  variable bindings, type definitions, etc, from clobbering the same referenced
  and required by the macro for its proper operation.  The point with all this
  hygiene and referential transparency is to defend the misguided notion that
  one namespace is not only sufficient, but superior to multiple namespaces.
  But rather than solve the problem with a fairly simple "rules" that functions
  are global and that you never clobber functions from a package you do not
  control, you now how to solve the problem of ensuring that clobbering
  functions does not cause massive damage to your entire system.

  For instance, if you have a macro that makes its caller call a "foo" when
  expanded, you have a dependency on the binding assumed by the macro.  If
  "foo" is a symbol in the Common-Lisp package, and if we momentarily ignore
  the rule that programmers may not clobber symbols in the Common-Lisp package,
  you would want the macro to refer to the binding assumed by the macro even if
  a programmer clobbered its binding with a lexical definition of "foo".

  You see that this is a non-problem in a properly designed language, and a
  major issue in a maldesigned language that introduces problems because it
  _believes_ in counterproductive principles of "simplicity".  The more you
  believe in something, the harder you push despite serious setbacks and
  concomitant problems.  Remember the belief in the simple assumption that the
  earth is the center of the universe and how it spawned immensely complex
  computations of planetary travel.  The right solution was to adopt a much
  simpler model that had the drawback of reducing the importance of humans to
  the Universe.  This was considered very threatening by those who believed
  very firmly in the universal importance of humans.  The same kind of failure
  to grasp that a single namespace causes problems is at the root of a number
  of very complex problems.

  Most of these problems evaporate if you adopt a perspective more conducive to
  the actual task of programming.  Insisting on the single namespace has caused
  a slower progression in computer science than we could have achieved with a
  deeper understanding of natural language grammars and of how people actually
  think in the design of artificial languages.  For instance, we have developed
  an excellent machinery to deal with context, yet define context-free grammars
  and think them superior to more complex grammars because they are simpler to
  implement.  This, sadly, causes people who struggle to get away from the bad
  design principles of programming languages to define much worse languages
  than they would have if there had been more theoretical support for better
  language design methodologies.  I would argue that the single namespace and
  the context-free grammar combined provide the worst possible foundation for
  the design of a programming language.

Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.