[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
THROW, and MAP
- To: Common-Lisp@SU-AI.ARPA
- Subject: THROW, and MAP
- From: JonL.pa@PARC-MAXC.ARPA
- Date: Tue, 27 Sep 83 15:51 PDT
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
If before, then the syntax of THROW is merely that of 'function'. If
then that must be spelled out, so that side-effects in the 'result'
won't occur when there is a tag-search failure.
All the recent discussion about "what happens if the mapped function
the list it is mapping over" points up the non-primitive nature of the
series of "functions". Admittedly, the WhitePages aren't the place to
distinguish a truly-primitive kernel from the common, portable subset,
a simple change from [Function] to [Macro] on the map entries would
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
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
MacLisp DO just doesn't "cut the mustard". DOTIMES and DOLIST are
too-late. LOOP in its current definition (p93) seems to preclude the
MacLisp/LispM LOOP macro. Foo. Having used Interlisp's I.S.OPRS for
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
Nor should the objection be that old "cop out" that its syntax isn't
enough [or, as the last paragraph on page 99 almost says, "... as if
impossible to write programs without