Loop questions

[Jon L White <jonl@lucid.com>]

William, you have so many comments here that it's difficult to pick any
one to focus a reply around.  But let me pose a straw-man summary of
what I think you are worried about, and address that.

I read the various parts of the LOOP spec as _permitting_ the following
strategy for implementation:

  (1) LET-bind *all* the loop variables first, possibly to harmless
      null values conforming to storage type declarations;

  (2) run all the implicit initial-value forms, in order, setting the
      sequential binding as you go, and possibly "blocking" together
      the parallel bindings as you go, and possibly exiting if any
      end-test condition is satisfied right-off-the-bat;

  (3) run all the INITIALLY clauses, in order (i.e. "left-to-right");

  (4) be aware that some alternation of (1) and (2) can be done while
      still preserving order-of-evaluation semantics.

Now, your first concern was whether one of the initial-value forms would
be executed in a lexical context that has  already established a binding
for the some other variables whose initial-value forms hadn't been run yet.
Right? 

The answer is of course, yes, this is quite permissible; an alternative 
specification would be to try say that *all* the initial value forms should 
be executed before *any* of the bindings are established, but this has a 
fundamental flaw of not permitting sequential initializations.  Trying to 
fix this "fundamental flaw" would immensely complicate the semantics.  An
alternative trying to parallel LET* -- in addition to the complication
issue -- would make the concept of FINALLY clauses impossible.



Now your second concern seems to be with the particular "fix" for the
design that allows all bindings to be established before any initial-value
forms are executed -- that of permitting a binding to a "harmless" value.

First let me point one one of your assumptions that may be wrong:

    But various statements make it clear that *all* variables are initialized 
    with the first value, even if that first value doesn't exist.

It is *not* "THE first value" that is required; only "A first value", which
is allowed to be a "harmless" candidate.  Needless to say, I can't agree with
you that finding a "harmless" value is impossible.  The concern is not 
complete type co-incidence of the declared value and the ephemerally-
invisible initial value, but rather with compilers which notice binding-time
declarations to do storage representation shifts.  At this point in time, I 
know of compilers that do such shifts for declared FIXNUM's and FLOAT's, but 
not for any other datatypes; should any other datatypes be added by a SSC 
(recall the "SufficientlySmartCompiler" syndrome), then it would be up to the 
implementor of that compiler to provide the "harmless" initial settings for 
variables declared of that type.

But the fact is, there has to be some binding; your worry about FINALLY
clauses could imply that you think that the clause can be executed with 
differing lexical environments (bindings) depending on whether or not some 
dynamic event happens (e.g., one of the end-tests punks out before any 
iterations are executed).  Not only would this pose an unaccpatable burden
on compilation, but I don't even think any interpreter writers are 
comtemplating it.  I would not expect a syntactic solution to the kind of
programmer error wherein he references a variable in a FINALLY clause
before any relevant user-code has had a chance to set it up.


Have I grasped in any way the difficulties you are trying to convey?


-- Jonl--