Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!brutus.cs.uiuc.edu!apple!bbn!bbn.com!barr
From: barr@bbn.com (Hunter Barr)
Newsgroups: comp.lang.lisp
Subject: Re: FUNCALL question
Summary: In my own humble way, I sum up this thread for good. :-).
Message-ID: <2247@papaya.bbn.com>
Date: 1 Feb 90 16:23:47 GMT
References: <3277@accuvax.nwu.edu> <1990Jan28.175437.19293@hellgate.utah.edu> <1990Jan29.224305.20803@hellgate.utah.edu> <385@forsight.Jpl.Nasa.Gov>
Organization: BBN Systems and Technologies Corporation
Lines: 78

In article <385@forsight.Jpl.Nasa.Gov> gat@robotics.Jpl.Nasa.Gov (Erann Gat) writes:

...

>Scheme has a FUNCALL only insofar as its semantics for calling functions
>are the same as the semantics of funcall.  Scheme does not have a
>function which does what FUNCALL does.  This may seem trivial, but my experience
>has been that the existence of FUNCALL (and FUNCTION and FLET and #', etc.)
>is the source of a great deal of confusion for beginning programmers,
>a great deal of frustration for experienced ones, and a lot of wasted time
>and effort implementing compilers which are more complicated than they
>need to be.  If anyone knows of a good reason to have an explicit FUNCALL
>(which is to say, a good reason to distinguish between a symbol's function
>binding and value binding) I wish they would point it out to me (preferably
>via E-mail).
>
>As long as I am picking on Common Lisp, let me air another of my pet peeves:
>There seems to be no way to undo the global special declaration performed
>by a DEFVAR.  Once a symbol has been DEFVARed, there is no way to use that
>symbol as a lexical variable ever again short of rebooting the environment.
>You can really screw yourself over with a careless DEFVAR.  This can be the
>source of some EXTREMELY subtle and frustrating bugs.
>
>-Erann Gat  (gat@robotics.jpl.nasa.gov)


The whole discussion of FUNCALL boils down to this: Erann doesn't like
Common Lisp overloading symbols by allowing separate value and
function cells.  Erann deserves no criticism for that.  I myself agree
that Scheme's scheme is much prettier in many ways.  But in my actual
work I usually find it more convenient to overload symbols.  (Keep in
mind that this says more about my personal style of programming and
thinking about problems than about anything else.)  But some problems
*are* harder to untangle if you let your symbols get overloaded, while
other problems are harder if you are forced to spend time thinking up
different (but related) symbol-names for variables and associated
functions.  Neither paradigm works best in all situations.

Now, about your pet peeve.  DEFVAR is intended to be quite permanent,
and there should not be an approved way to undo it.  If you need
something to be special, but you don't want to screw up your global
toplevel environment, don't do a DEFVAR.  Instead, just declare it to
be special inside the toplevel function of your system.  Give it the
customary stars to make it clear that you intend it to be special.
Try this:

<cl> (defun peeve-test ()
       (let ((*peeve* 'pet))
	 (declare (special *peeve*))
	 (peeve-1)))
peeve-test
<cl> (defun peeve-1 ()
       (describe '*peeve*))
peeve-1
<cl> (peeve-1)
*peeve* is a symbol
  It is unbound
  It is internal in the user package
<cl> (peeve-test)
*peeve* is a symbol
  Its value is pet
  It is internal in the user package
<cl> (peeve-1)
*peeve* is a symbol
  It is unbound
  It is internal in the user package
<cl> 

See?  Special variables with no mess left over.  Even if you use
DEFVAR, if you follow the star-tradition you can avoid trouble by
never trying to use *<foo>* as a lexical variable.  You wouldn't want
to (UN-DEFVAR *PRINT-BASE*) would you?  Now that *would* cause some
problems. 

Thanks for reading this far, everyone.
-- 
                            ______
                            HUNTER