[Openmcl-devel] LOOP parallel for/as termination eval order issue.
j-anthony at comcast.net
Mon Oct 18 12:30:04 CDT 2010
Might this be a bug in their (CLisp) loop invariant hoisting code? What
happens in the expansion if you use a non-constant invariant?
On Mon, 2010-10-18 at 09:32 -0700, Kaz Kylheku wrote:
> On Mon, 18 Oct 2010 05:56:47 -0600 (MDT), Gary Byers <gb at clozure.com>
> > On Sun, 17 Oct 2010, Kaz Kylheku wrote:
> >> Look at that! CLISP's loop assiduously performs
> >> all the assignments, prior to the first iteration,
> >> and only then evaluates the termination conditions
> >> associated with the clauses prior to the loop
> >> body.
> > No it doesn't. If you don't believe me, macroexpand your
> > example in CLISP and look at what actually happens.
> You are right. The behavior differs based on the nature of the
> forms involved.
> For instance:
> > (loop for x in nil for y = m2 finally (return y))
> > (loop for x in nil for y = 2 finally (return y))
> > m2
> > m1
> (m1 and m2 happen to be symbol macros denoting function
> call forms, which may not matter).
> It looks like CLISP moved the assignment ahead of the
> termination test because of Y being initialized with a constant,
> which being what it is, cannot depend on any of the other
> But in the real code I don't have such a trivial constant;
> I think I have not uncovered the real root cause of the
> portability issue.
> Furthermore, I am seeing a problem problem in which
> the list being walked isn't empty (a stepping issue, not
> an initialization problem).
> > that your model will remain inaccurate.
> Would it be fair to say:
> The de-facto correct model (say, by implementation popularity)
> seems to be that the iteration control clauses are somewhat
> like statements and are performed in order, and that includes
> triggering early termination, pre-empting subsequent
> termination clauses (this not being spelled out in the
> spec). Termination testing is not factored out into a separate
> termination testing phase.
> Furthermore, if any initializations are skipped by an
> earlier termination tests, the values of those variables
> are unspecified.
> CLISP may be implementing that model, but changing some
> aspects of it by moving things around when it seems
> innocuous to do so that it in those cases it seems as
> like a different model.
> Certainly, the treatment of the y = 2 versus
> y = m2 above is inconsistent. The difference is allowed
> by a model which allows y to have any value at all if its
> initialization is skipped.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel