THROW, and MAP

[JonL.pa@PARC-MAXC.ARPA]

THROW

Excelsior edition's commentary on THROW doesn't make clear whether the
evaluation of the 'result' form is to take place before or after the
tag-search.
If before, then the syntax of THROW is merely that of 'function'.  If
after,
then that must be spelled out, so that side-effects in the 'result'
computation
won't occur when there is a tag-search failure.

MAP

All the recent discussion about "what happens if the mapped function
updates
the list it is mapping over" points up the non-primitive nature of the
map
series of "functions".  Admittedly, the WhitePages aren't the place to
try to
distinguish a truly-primitive kernel from the common, portable subset,
but
a simple change from [Function] to [Macro] on the map entries would
forclose
a lot misguided babbling.

Given that CommonLisp has RETURN-FROM and named BLOCKs, a macro-
expansion of the mappers need not be concerned with "prog context".  Is
there
any reason for continuing to push the primality of the map series over a
reasonable macro definition?

More to the point, sigh, is the lack of any reasonable iteration control
structure.
MacLisp DO just doesn't "cut the mustard".  DOTIMES and DOLIST are
too-little,
too-late.   LOOP in its current definition (p93) seems to preclude the
nice
MacLisp/LispM LOOP macro.  Foo.  Having used Interlisp's I.S.OPRS for
some
time now, I often wonder how one can get along without it.  The
objection to a reasonable form of LOOP can hardly be that it is "new",
since it is essentially
a modest variant of Interlisp's I.S.OPRS which has had 10-years of
extensive use.
Nor should the objection be that old "cop out" that its syntax isn't
"Lispy"
enough  [or, as the last paragraph on page 99 almost says,  "... as if
it were
impossible to write programs without
Lots-of-Interminable-Silly-Parentheses"]