More on Strands in PLUS II

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 130

Further to my letter on "STSC’s Double Whammy", I have discovered a nasty little bug that seems to have worked its way into the interpreter. In my original letter, I included some discussion of the way in which numeric strands are differentiated from other types of strand during indexing. The bug appears to originate from this dichotomy.

The following session log should illustrate the problem quite nicely:

      a←3
      ⍴1 2 3
3
      1 2 3[1]
1
      1 2 3[2]
2
      1 2 3[3]
3
      1 2 3≡1 2 a
1
      ⍴1 2 a
3
      1 2 a[1]
 1 2
      1 2 a[2]
3
      1 2 a[3]
INDEX ERROR
      1 2 a[3]
      ∧   ∧

All the primitive functions like MATCH and SHAPE appear to consider the numeric strand

1 2 3

to be identical to the strand

1 2 a

as long as

a←3

Bracket indexing however does not. Bracket indexing considers the numeric strand to be a discrete item in its own right, thus for bracket indexing the shape of the vector is 2 items, not 3; the first item is the numeric strand (1 2), the second item is the numeric scalar 3.

The behaviour gets even more bizarre. Consider the following example:

      1 2 a[⍳⍴1 2 a]
INDEX ERROR
      1 2 a[⍳⍴1 2 a]
      ∧   ∧

You cannot index this vector by its own index set! …

      (1 2 a)[⍳⍴1 2 a]
1 2 3

… but simply by placing the strand in parentheses, you can. In fact all the problems are cured as long as the strand is parenthesized before you index into it.

The correct behaviour is given by the parenthesized form, the software that I have written to analyze functions for changes which have to be made to accommodate the evolution levels 1 and 2 assume the correct behaviour, so that parenthesizing the strand before indexing gives the correct results.

D B Piper

P.S. Since writing this letter, I have found the problem to be present in APL*Plus II version 3.5 also.