[Openmcl-devel] LOOP parallel for/as termination eval order issue.

Kaz Kylheku kaz at kylheku.com
Mon Oct 18 06:01:16 UTC 2010


On Sun, 17 Oct 2010 20:22:15 -0600 (MDT), Gary Byers <gb at clozure.com>
wrote:
> On Sun, 17 Oct 2010, Kaz Kylheku wrote:
> 
>>
>> Hi all,
>>
>> The following for returns nil in CCL and Allegro, but (1 2 3) in CLISP.
> 
> It also returns NIL in the versions of LispWorks, CMUCL, and SBCL that
> I have.  It's possible that the behavior that you expect is correct and
> that CLISP is the only implementation that gets it right, but I don't
> think that that's the case here.

The AND parallel construct is a red herring, it turns out.
Let's eliminate it:

  (loop for x in nil
        for y = 3 finally (return y))

  #+clisp -> 3
  #+clozure -> NIL

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.

That's exactly what the spec says (6.1.1.6).

But the workaround is obvious for the above. You can get
both implementations to return 3 if you rearrange the
forms:

  (loop for y = 3
        for x in nil
        finally (return y))

In my code I did the same thing: dropped all the
removable AND's, which enabled me to massage
the order.

This is a kludge. It should not be necessary to
manipulate the order of the
clauses in order to delay a premature
termination test.

This seriously violates the whole loop abstraction.





More information about the Openmcl-devel mailing list