Path: utzoo!attcan!uunet!mcvax!ukc!etive!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: namespaces Message-ID: <251@skye.ed.ac.uk> Date: 10 Mar 89 18:01:10 GMT References: <6859@phoenix.Princeton.EDU> <52880@yale-celray.yale.UUCP> <7931@csli.STANFORD.EDU> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Organization: AIAI, University of Edinburgh, Scotland Lines: 86 In article <7931@csli.STANFORD.EDU> johnson@csli.stanford.edu (Mark Johnson) writes: >Too much Scheme! Someone else just sent a message on the net asking >why CommonLisp uses different name spaces for variable and function >definitions. Personally, I think that this is one of the worst >features of CommonLisp. It makes my programs look like fields of #' >symbols and funcalls. It is also one of the hardest things for >students to learn - they get continually confused between the use of >LIST as a function and a variable. (I know it's bad programming >style, but people do do it). Return of the Style Wars! The use of separate name spaces goes back to Lisp 1.5, so it's not just Common Lisp; most Lisps have been that way. In many ways, Common Lisp is a traditional Lisp, albeit a big one. Whether FUNCTION and FUNCALL are good or bad depends, in part, on how often they're used. If they're relatively rare, they can be useful as signs that something unusual is happening. For example, FUNCALL indicates a call to a non-constant function. But if you adopt a more functional style, so that FUNCTION and FUNCALL are used all over the place, the resulting clutter may make the code harder to read. It's not too hard to explain FUNCTION as a syntactic marker, if you say, as CLtL does, that Lisp programs "are organized as forms and functions". The Lisp 1.5 syntax went more or less as follows:
::= ... | ( *) | ... ::= | (FUNCTION ) ::= | So FUNCTION is a way to write a function as an argument (or, better, as a form). FUNCTION used to be more than "just syntax". It was often sort-of like QUOTE but sometimes an operation that made a closure, sometimes a marker for the compiler (saying there was something to be compiled and not just a list there). But it was still reasonable to think of FUNCTION as syntax. The issue of name spaces, or multiple meanings for identifiers, is more difficult. Some people might say it is always wrong to use LIST as a variable, others might say it's almost never wrong and, indeed, extremely convenient. Again, this may depend on the sort of code they write (or want to write). If functional arguments are rare, most functions are, in effect, constants; and it's not unreasonable to think, for example, that (COS ) should always call the cosine function. Indeed, that's more or less what one has to think when writing a macro. If I write (defmacro cosine (x) `(cos ,x)) I expect (COSINE x) to return the cosine of x. But I don't really know that no-one will locally redefine COS. If there is a separate function namespace, I have to worry about local functions (FLET) only; but with one name space I have to worry about every variable too. E.g., (defun cosine2 (x) (let ((cos (cosine x))) ;ok (cosine cos))) ;not ok In practice, though perhaps not in principle, a single namespace makes such problems more likely. The macro would work as intended in the function above if there were a separate function name space. The example above may not be very convincing by itself, but it should be clear that such things can happen. And historically that has been one reason why some people have been reluctant to adopt a single name space. --- For an informative discussion of the two namespaces in Common Lisp, see "Technical Issues of Separation in Function Cells and Value Cells", by Richard P. Gabriel and Kent M. Pitman, in Lisp and Symbolic Computation, Volume 1, Number 1, June 1988. For a discussion of macro problems and how they might be solved, see "Syntactic Closures", by Alan Bawden, in the Proceedings of the 1988 ACM Conference on Lisp and Functional Programming. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton