What should we DO?

["Guy L. Steele, Jr." <GLS at MIT-MC>]

    My personal feelings on this are that we should come up with consistent
    rules about these things. Documentation is much simpler if you could
    generalize in it. So I would prefer flushing old-DO in the longrun but
    it's probably unworkable at present. There's no reason to leave ourselves
    open to future problems of this sort by implementing something now without
    thinking first -- which is why I advocated not allowing (DOTIMES n ...).
    I was not advocating that (DOTIMES lab ...) be installed -- just allowing
    for that contingency.

    I now present my feelings on this issue of how DO/PROG could be done in order
    this haggling, part of which I think comes out of the fact that these return
    tags are tied up in PROG-ness and so on ... Suppose you had the following
    primitives in Lisp:

    (PROG-BODY ...) which evaluated all non-atomic stuff. Atoms were GO-tags.
     Returns () if you fall off the end. RETURN does not work from this form.

    (PROG-RETURN-POINT form name) name is not evaluated. Form is evaluated and
     if a RETURN-FROM specifying name (or just a RETURN) were executed, control
     would pass to here. Returns the value of form if form returns normally or
     the value returned from it if a RETURN or RETURN-FROM is executed. [Note:
     this is not a [*]CATCH because it is lexical in nature and optimized out
     by the compiler. Also, a distinction between NAMED-PROG-RETURN-POINT
     and UNNAMED-PROG-RETURN-POINT might be desirable -- extrapolate for yourself
     how this would change things -- I'll just present the basic idea here.]

    (ITERATE bindings test form1 form2 ...) like DO is now but doesn't allow
     return or goto. All forms are evaluated. GO does not work to get to any form
     in the iteration body.

Seriously, folks, my own position on DO and friends is largely in agreement
with KMP here.  His PROG-RETURN-POINT is simply the lexical catch advocated
by DLW, with allowances for how RETURN could be expressed in terms of that.
It is of interest to note that the S-1 NIL compiler in fact
implements a construct called PROG-BODY with precisely those semantics;
PROG is then turned into a nested LET and PROG-BODY.  This was done
to concentrate all knowledge of variable bindings into one place --
the code that handles LAMBDA.  The original intent was just to use
this construct internally to the compiler, but indeed it may be a useful
building-block for other macros.