Re: LOOP macros.

[Chris Riesbeck <Riesbeck at YALE>]

I'm all in favor of merging the two LOOPs and am as happy to compromise
as Bob Nix appears to be.  A few points are not clear.

Given (LOOP (INITIAL (v1 e1 inc1) (v2 e2 inc2) ...)  ...), which behaves
like (DO ((v1 e1 inc1) (v2 e2 inc2) ...)  ...), shouldn't the expanded
form be

             (LET ((LOOP-EXIT (LAMBDA () -result code-)))
             (LABELS ((LOOP-TOP
                       (LAMBDA (v1 v2 ...)
                           ...
                                   -increment and step code-
                                   (LOOP-TOP inc1 inc2 ...))))))
                  -before-code-
                  (LOOP-TOP e1 e2 ...)))))

That is, LOOP-TOP needs arguments for parallel incrementing.  This
can't be done with the -increment and step code-.

Actually only those variables that are given explicit increment forms
need be included with LOOP-TOP, so that if we have (INITIAL (v1 e1)
(v2 e2) ...)  then LOOP-TOP will indeed have no arguments.

While I'm here, a style question.  Why is it better to define the
LOOP-EXIT separately, rather than with LOOP-TOP in the LABELS?  The
only difference I can see would be if result-code referred to some
other function called LOOP-TOP, but problems like that can still arise.


        3.  The TLisp AFTER clause makes up for a deficiency in TLisp's RESULT
        clause-- that it takes just one expression, rather than a list of
        expressions.  The F/E Loop doesn't have this problem, so there is no
        reason for the AFTER clause.  I find (LOOP...(AFTER e1 e2) (RESULT e3))
        much harder to understand than (LOOP...(RESULT e1 e2 e3)).  For this
        reason, I would rather not implement AFTER.  You could take care of
        this in the TLISP_TO_T conversion.

Actually, that was a feature not a bug.  It's trivial enough to handle
(RESULT e1 e2 e2), and the first version I did in T did so (it may
still do so).  I thought (and still think) that it's clearer to separate
out what's done at the end of the loop from what's returned.  For
example, I think that (LOOP ...  (AFTER e1 ...)) with no RESULT clause
should have an undefined value.  The current implementation of TLisp's
LOOP in T guarantees NIL, I believe, but I'm softer-hearted than the
T implementors.

I vote that AFTER be left in, along with multi-expression RESULTs,
so that various religious fanatics can take their choice.
-------