What can you do in LISP that you can't do in Python

mikel evins himself at mikelevins.com
Thu May 24 16:49:07 CEST 2001


"Paul Foley" <see at below> wrote in message
news:m2k837nkjb.fsf at mycroft.actrix.gen.nz...
> On 24 May 2001 07:58:21 GMT, mikel evins wrote:

> > Here's the Common Lisp code:
>
> > (let* ((count 0)
> >        (incrementer #'(lambda () (setq count (1+ count)))))
> >   (defmacro counting-setq (var val)
> >     `(progn
> >        (funcall ,incrementer)
> >        (setq ,var ,val)
> >        ,count)))
>
> > What it does is this: it defines a new version of SETQ called
> > 'counting-setq'. This new operation does the same thing that SETQ does:
it
> > sets the value of a variable. But it does something else, too: it counts
how
> > many times you call it and saves the current count in a variable that
nobody
> > but counting-setq can see or affect. When it sets a variable it
increments
> > the current count and then returns it.
>
> No it doesn't; it returns the number of times it got called prior to
> this particular expansion.  I.e., the result won't be easily
> predictable.  It *may* do something like what you say it does in
> interpreted code, if the expansion isn't being cached somewhere; it'll
> certainly return constant (but probably not very easily predictable)
> values in compiled code.  Constant zeros if you just compile code
> using this thing in a fresh Lisp image.

I checked the compiled code in Corman Lisp, Lispworks, ACL 6.0, and MCL 3.9.
Apparently all the compiler writers are under the same mistaken impression I
am. Should we file bug reports? :-)







More information about the Python-list mailing list