What can you do in LISP that you can't do in Python
mikel evins
himself at mikelevins.com
Thu May 24 10:49:07 EDT 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