Re: THROW, and MAP

[Guy.Steele@CMU-CS-A]

Your point about THROW is well-taken, and I will try to improve the prose.
I think that THROW was made into a special form because, although all
arguments are evaluated and thus from that point of view it could be
treated as a function, THROW has some bizarre side effects (namely
transfer of control) and most program-processing programs will probably
need to treat it as a special form anyway.  (Maybe that's wrong; maybe
it just happened somewhat accidentally as we gyrated through various
versions of throws and catches.)

As for MAP, I honestly don't see what being a macro or a function has
to do with pinning down its behavior when a list being mapped over is
modified; either a macro or a function could have the surprising behavior,
and in either case the desription must be more precise.

Now, the question of whether MAP should be a function or a macro is in
itself an interesting and debatable question.  It doesn't need to be
a macro for the sake of compiled code, because a compiler is free to
compile it inline unless specifically directed not to do so (with a
notinline declaration).  MacLISP does this kind of inline compilation
already.  As you pointed out, the RETURN-FROM technology allows
Common LISP to avoid some of the PROG-capture anomalies that occurred
in MacLISP.

I will point out that in some styles of programming it is useful to
be able to APPLY MAP (or even to MAP a MAP)!

Concerning LOOP, the Common LISP LOOP construct is compatible with the
LISP Machine LOOP construct.  There is a sentence which carefully makes
the semantics of Common LISP's LOOP undefined if any form in the
construct is a symbol (it should say atom).  So every valid Common
LISP LOOP must contain only non-atomic forms, and in this case the
LISP Machine LOOP has the same semantics as the Common LISP LOOP.
So any implementation is free to implement the entire LISP Machine
LOOP stuff and claim it is compatible with Common LISP; it just
won't necessarily be portable if you use the hairier features.