[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
What should we DO?
- To: BUG-LISP at MIT-MC, NIL at MIT-MC, BUG-LISPM at MIT-MC
- Subject: What should we DO?
- From: "Guy L. Steele, Jr." <GLS at MIT-MC>
- Date: Tue, 15 Apr 80 05:40:00 GMT
- Cc: KMP at MIT-MC, H at MIT-MC, HENRY at MIT-MC, RMS at MIT-MC, MOON at MIT-MC
- Original-date: 15 April 1980 00:40-EST
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.