0

I was wondering if the across structure uses an own cursor or a separated one? does it ensure that cursor hasn't moved and if so how can it be expressed for other examples?

Pipo
  • 4,653
  • 38
  • 47

1 Answers1

1

ITERABLE uses so called external cursors, not internal ones merged with the underlying structure. As a result, iteration affects neither the structure nor any other cursor, created the same way. This is important to support nested or recursive iterations. For example, to find if there are duplicates, one can do the following:

across structure as i loop
    across structure as j loop
        if i.item = j.item then print ("Duplicates found.") end
    end
end

Doing the same with internal cursors, like (note: the code is incorrect)

from structure.start until structure.after loop
    x := structure.item
    from structure.start until structure.after loop
        if x = structure.item then print ("Duplicates found.") end
        structure.forth
    end
    structure.forth
end

does not work, because the inner loop also changes the cursor of the outer loop.

The limitation of the cursors associated with ITERABLE is that the associated structure should not be changed during the whole course of iteration. This is not a theoretical limitation, but a practical one, to simplify implementation and to make it a bit more efficient.

Alexander Kogtenkov
  • 5,770
  • 1
  • 27
  • 35
  • Many thx for your complete answer, could you add something about an ensure statement of unmoved cursor? I was wondering if `ensure cursor = old cursor` is sufficient or if I have to pass through `cursor.index = old cursor.index` – Pipo Jan 26 '19 at 18:35
  • @Pipo All cursors created to run `across` loops on `ITERABLE` are independent and do not affect each other. Expressing the independence in postconditions would require the cursors to "know" each other. This is too much. Moreover, the question arises whether cursor movement can also print to a console, write an entry to a DB, open a user dialog,etc. We would have to express all these things in the postcondition as well. This becomes unmanageable and is known as a [frame problem](https://en.wikipedia.org/wiki/Frame_problem). It is solved with some other means, e.g. `modify` clauses in AutoProof. – Alexander Kogtenkov Jan 27 '19 at 07:38