LOOP :INITIALLY clauses and scope of initializers

Bug #309095 reported by Nikodemus Siivola on 2008-12-17
Affects Status Importance Assigned to Milestone

Bug Description

  reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
  test suite, originally by Thomas F. Burdick.
    ;; <http://www.lisp.org/HyperSpec/Body/sec_6-1-7-2.html>
    ;; According to the HyperSpec, in for-as-equals-then, var is
    ;; initialized to the result of evaluating form1. says that
    ;; initially clauses are evaluated in the loop prologue, which precedes all
    ;; loop code except for the initial settings provided by with, for, or as.
    (loop :for x = 0 :then (1+ x)
          :for y = (1+ x) :then (ash y 1)
          :for z :across #(1 3 9 27 81 243)
          :for w = (+ x y z)
          :initially (assert (zerop x)) :initially (assert (= 2 w))
          :until (>= w 100) :collect w)
    Expected: (2 6 15 38)
    Got: ERROR

Changed in sbcl:
importance: Undecided → Medium
status: New → Confirmed

This issue has two independent parts. The first one is connected with the wrong order of 'initially' clauses and variables initialization. At the first sight it is easily fixable with the attached patch, which resolves the problems in the very similar case:

 (loop :for x = 0 :then (1+ x)
          :for y = (1+ x) :then (ash y 1)
          :for z :across #(1 3 9 27 81 243)
          :for w = (+ x y z)
          :initially (assert (zerop x))
          :until (>= w 100) :collect w)

This patch works fine when applied to the already running system (using chill.lisp), and loop tests pass, including the example from this post. However, it breaks the build on the late (post-cross-compiler) stage. As for now I have no idea why it happens, so I leave this patch here with the hope that more experienced developers could continue this work, or at least give me some advices.

The second part of the issue is connected with the fact that for-as-across lives completely in the loop main body, without any relation to the loop prologue. Extracting the initialization value from it is a non-trivial task, which should be considered only after the first part of the issue - the wrong order of initial and initialization clauses - is fixed.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers