Subject: Re: Lisp's unique feature: compiler available at run-time From: Erik Naggum <erik@naggum.net> Date: 31 Jul 2002 18:44:53 +0000 Newsgroups: comp.lang.lisp,comp.object Message-ID: <3237129893567597@naggum.net> * 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.