[Openmcl-devel] How abour top-level setf = REPL-lexical variables? (was Re: Compiler warnings)

Kevin Reid kpreid at mac.com
Tue Oct 20 02:00:27 UTC 2009


On Oct 19, 2009, at 21:34, Ron Garret wrote:

[in a long thread about the behavior of top-level setf]

> Yes.  I'm doing some testing, so I want some place to stash an
> intermediate result.  I do:
>
> (setf x ...)
>
> Later, after I'm long done with that and the fact that I once created
> a global variable named X, I do this:
>
> (defun make-closure (x) (lambda () ... x ...))
>
> I then expect MAKE-CLOSURE to return a lexical closure.

IMO, the best way to make this DWIM (which as far as I know is  
conformant (in that the REPL is mostly unspecified) but not currently  
done by any CL implementation) is to make x a *lexical* variable which  
is managed by the REPL. Your example would then do exactly what you  
meant.

That is, when you evaluate the expressions in the REPL it behaves *as  
if* every free variable is a lexical variable established by an  
enclosing LET.  (This particular semantic explanation gets weird if  
you do, say, (list x (setf x 1)), but this doesn't seem to me to be a  
large problem whether it is rejected or just returns (NIL 1).)

There could also be functions to display the current set of REPL  
variables and delete them.


I think this facility would have the following benefits:

   - Saves typing when playing around at the REPL, since there's no need
     for *special* markers.


   - Reminds you what you created as an interactive temporary vs. what  
is
     global state of the application, both syntactically and because you
     can get a list of them.


   - Fits what a lot of beginners expect, because they're
       - coming from Perl/Python/PHP/whatever
       - using ancient tutorials/samples with top-level setq/setf

     (This isn't just a beginner thing -- *I* would greatly like to have
     this feature to save me inventing special-variable names while
     repl-ing.)


And it's AFAIK fully conformant with CLHS.


-- 
Kevin Reid                                  <http://switchb.org/kpreid/>







More information about the Openmcl-devel mailing list