Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.lisp
Subject: Re: SETQ vs DEFVAR at the top level
Summary: about what LET is doing
Message-ID: <4434@medusa.cs.purdue.edu>
Date: 1 Jul 88 16:10:27 GMT
References: <4431@medusa.cs.purdue.edu>
Organization: Department of Computer Science, Purdue University
Lines: 37


     Since my post yesterday I have figured out the answer to parts my own
questions. The answer lies in that LET does a Dynamic shadowing of variables.
That is, (LET ((X -3))) will only make a new binding of X if X is not dynamic
in the calling environment. Otherwise it just gives the old binding of X a new
value for the body of the LET clause.

     for example:

(defvar x 6)

(defun mc ()
  (let ((x 2))
    #'(lambda () (print x))))

     The x in (print x) is the same x as in the (defvar x 6), which is also
the same x as in the let.

     It seems like a lot of code I see just uses DEFVAR to declare all global
variables as though that is what it is there for. In fact, I ran into this 
problem because that is what I was doing without really thinking about it.
I thought, and it sounds to me from reading this group that others think that
one should always use DEFVAR to declare global variables. Just recently I
have read "setq does not make a binding" and "it may be bad style to make
globals with setq". This is one of the reasons I made this post.
I now hold that it is safer to use SETQ to declare global variables
because it can be hard to track down this type of error in your closures.
Does someone have problems with using SETQ thus?

     Also, I still want to know if anyone has a way to force a new binding
of a variable in front of making a closure. Is there a way to declare x to
be non-special before the LET?

     Can anyone tell me why the CL designers chose to have LET behave in 
this manner?
-- 
Bill <bouma@medusa.cs.purdue.edu>  ||  ...!purdue!bouma