[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Scheme's DO construct



Well, you have constructed a great case based on anecdotal evidence,
which is worth having, but I think you have not even addressed my main
point.  The other constructs you mentioned (FOR, REPEAT, and WHILE) have
what I regard as an important flaw:  a reliance on side effects to
accomplish some part of the iterative process.  There is seldom any use
in stepping just one variable in an iteration; you want to step two or
more.  Because FOR, REPEAT, and WHILE (and for that matter DOLIST and
DOTIMES) each step at most one variable, it is necessary to have some
side effect in the body to get anything done.

DO is the only iteration construct we have (other than LOOP) that
encapsulates completely the notion of iteration: the iterative
transformation of a state (normally a compound state, therefore
consisting of two or more quantities) in such a way that an invariant is
maintained at each step, terminated when the state satisfies some
condition. The problem is not that DO has too many features, but that
each of the other iteration constructs is incomplete in a way that must
be patched up using side effects.

I would be quite happy to eliminate one feature of DO: the body!  If the
body is used, then side effects are necessarily involved.  The most
perspicuous uses of DO have no body.

The other problem with DO is that sometimes there is more than one
reason to exit.  I admit that as a flaw; but then again, sometimes there
is reason to return more than one value from a function, and I believe
SCHEME is not yet addressing that either with explicit features.
(Having a body compensates somewhat for that:

	(defun memq (x l)
	  (do ((z l (cdr z)))
	      ((null z) nil)
	    (when (eql x (car z)) (return z))))

This leads me to propose that a good iteration construct would be
like DO but instead of having a body would have more COND clauses.)

--Guy