Re: Iteration in lisp

lisp1.3.CalRobert@xxxxxxxxxxxxxxx (Robert Maas, http://tinyurl.com/uh3t) writes:

From: Kent M Pitman <pit...@xxxxxxxxxxx>
[...]
I have recently remarked that I don't like the default CL
treatment of SETQ and that I tend to program in a non-portable
fashion.

I haven't seen that, and now that you mention it I'm very curious.
[...]
I can only guess that maybe you don't like the way that
interpretation or JIT-compilation of a SETQ form of an undeclared
unbound symbol automatically declares it SPECIAL? If not that, I
can't guess at all.

No, that's annoying, but I consider that almost a bug. Not a
violation of spec, just bad design, since having such things happen in
a pervasive way without users requesting it seems bad to me.

I was talking more about the notion that

(progv '(x) '(3)
(eval '(+ x 1)))

is not portably well-defined without doing

(progv '(x) '(3)
(eval '(locally (declare (special x)) (+ x 1))))

which I think is a bit silly and makes use of EVAL altogether too cumbersome.

I also think the inability to do

(setq x 1)

in a textbook is a travesty because it forces people to get into the
discussion of DEFVAR way too early. You want to be able to talk about
and test program fragments, and the inability to do that "portably" is
silly. I consider it unreasonable that an implementation ever
complain about this. Even if it only does a lexical assignment
instead of a special assignment, which I suppose one could do, it
still ought not complain. But if it doesn't do ANYTHING and it just
complains out of neurotic concern that somewhere there's an
implementation not supporting assignment, I think that's not useful to
the community.

But that's all just my personal opinion as a consumer of CL.

OK, I have a riddle for everyone to brainstorm about.
You want to build a list (the usual, CONS-cells CDR-linked),
where each element is either a tree or a list or an alist,
and you want to call (mapcar #'COPY-DO-THE-RIGHT-THING thatList),
where it does copy-list or copy-cons or copy-alist as appropriate.
Obviously it won't work the obvious way, as Kent's essay explains.
So how can you design things so that this *will* work??

I guess you could just avoid conses and use some other struct type of
your own that kept the info. My question for you would be: what are
you REALLY trying to do? Why would you need to do this? I don't know
that I believe you that there is a well-defined case where you can
want this.
.

Relevant Pages