[comp.lang.lisp] namespaces

jwz@spice.cs.cmu.edu (Jamie Zawinski) (03/08/89)

> From: johnson@csli.STANFORD.EDU (Mark Johnson)
> 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.

I think that having one namespace for functions and variables is an
incredibly big lose.  When using languages with only one namespace, I
constantly have to think about what I can call things...  It's an
unnecessary burden on the programmer.

Besides, functions and variables are *different*.  :-)

> 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.

When I was first learning Lisp, it took me forever to understand macros and
backquote.  That doesn't make them any less useful.

Jamie
-- 

jeff@aiai.ed.ac.uk (Jeff Dalton) (03/11/89)

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:

   <form> ::= ... | (<function> <argument>*) | ...

   <argument> ::= <form> | (FUNCTION <function>)

   <function> ::= <function name> | <lambda expression>

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 <form>) 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