Book Review – It’s APL, but not as we know it

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

The authors Gerrit A. Blaauw & Federick P. Brooks use APL, which they describe as a “conversationally executable” high level language, in their book Computer Architecture Concepts and Evolution (Addison-Wesley 1997).

“The prime purpose of our APL descriptions is to describe, although the descriptions are executable and hence can be used to simulate and demonstrate. Clarity is favoured over efficiency. We do not shrink from computing a value twice if this repetition makes the meaning of the description clearer … Although the APL descriptions are intended to be read by many people, they should also be convenient to write and use. A description should be a design tool. As soon as one must make a separate effort to derive a description from a design, the description almost inevitably becomes out of date as the design changes. … The desiderata for reading and writing sometimes conflict. Unabridged names are easier to comprehend than abbreviations, but are also more tedious to write correctly. We have struck a balance….We assume that the reader is familiar with APL.”

Although the book does not contain an APL system (user interface, input/output, error validation etc.), it contains some 650 APL descriptions. These are radically different from the APL I have seen or write.

The APL code is :

1. written in an APL which does not have control structures. However, the code uses the authors’ own (APL) implementations of if … then … else, while … endwhile, repeat … until, case. “… to be read by many people, they should also be convenient to write and use.”
2. listed/presented without line numbers.

An example (from page 258):

“The Grau form selects where possible a zero exponent by taking the exponent’s minimal absolute value. This choice allows the integer coefficient value to be the same as the fixed-point representation of the given number….

grau number
⍝ grau normal form
→IF 0=number
THEN:⍝ exponent for zero
    exponent←zero
    →ENDIF
ELSE: ⍝ Minimal exponent
    exponent←0⊥⌊(1+base⍟|number)+point-(⍴1↓Coef)×base⍟radix
ENDIF:coefficient←number÷base*exponent-point
⍝ exponent with minimal magnitude
→WHILE (exponent<0)∧0=base|coefficient
    exponent←exponent+1
    coefficient←coefficient÷base
    →⍙
ENDWHILE:

”

As the APL code in this book is sequential, this example presumes global variables exist.

Doesn’t the APL look different?

Obviously, the APL the authors have used does not support control structures, and they have implemented their own in order to improve coding and readability. I offer the following illustrations :

Repeat … Until¶

Example: Given a vector, display it dropping leading element until the vector is null. The block of code is executed at least once.

RepeatUntil ⍳5
1 2 3 4 5
2 3 4 5
3 4 5
4 5
5
Continue DownHere

    ∇ RepeatUntil R
[1]   Repeat:
[2]   R
[3]   →until 0=⍴R←1↓R
[4]   'Continue DownHere'
    ∇

    ∇ Z←until R
[1]   Z←R↓Repeat
    ∇

While … Endwhile¶

Example : Display the initial element of a vector, dropping the initial element with each cycle until the vector is null. The block of code is executed only if the condition is true.

WhileEndWhile ⍳5
1
2
3
4
5
Continue Here

    ∇ WhileEndWhile R
[1]   ⍙:→while 0≠⍴R
[2]   ⍬⍴R
[3]   R←1↓R
[4]   →⍙
[5]   endwhile:
[6]   'Continue Here'
    ∇

    ∇ Z←while R
[1]   Z←R↓endwhile
    ∇

If … Then … Endif or If … Then … Else … Endif¶

Example: Determine if a number is odd or even.

IfThenElse 4
Even
Continue DownHere

    ∇ IfThenElse R
[1]
[2]   →if 2|R
[3]       then:
[4]           'Odd'
[5]           →endif
[6]       else:
[7]           'Even'
[8]   endif:
[9]   'Continue DownHere'
    ∇

    ∇ Z←if R
[1]   ⍎(0=⎕nc 'else')/'else←endif'
[2]   Z←0⊥else,R/then
    ∇

Case … Endcase¶

Example: Select a block of code depending on argument.

CaseEndCase 'Coffee'
Coffee
Continue DownHere

CaseEndCase 'Orange'
Unknown
Continue DownHere

∇ CaseEndCase R
[1]
[2]     →case R
[3]
[4]     'Unknown'
[5]     →endcase
[6]     Tea:
[7]     'Tea'
[8]     →endcase
[9]     Coffee:
[10]    'Coffee'
[11]    →endcase
[12]    endcase:
[13]    'Continue DownHere'
    ∇

∇ Z←case R
[1]   R←(0⊥⍴⎕NL 1)↑R
[2]   Z←,(R∧.=⍉⎕NL 1)⌿⎕NL 1
[3]   →if 0=⍴Z
[4]   then:
[5]       Z←⍬
[6]   →endif
[7]   else:
[8]       Z←⍎Z
[9]   endif:
    ∇

Home-built implementations of the control structures, such as the ones above have one serious limitation: the structure can be used only once in any given function. This is because they work by referring to the line numbers on which the keywords appear. If the same labels/keywords appear more than once in a function, they will have the last line value thereby causing incorrect branching. In Computer Architecture Concepts, the authors have overcome this as follows: when the If … Then … Else structure is required more than once in the same function, they use If … Then … Else , If1… Then1… Else1, If2… Then2… Else2 etc. This becomes messy, although it does have the advantage of being able to verify the blocks of code visually.

The interpreter I use supports control structures: I agree that APL code is convenient to write and use with control structures, even with the own implementation variety.

Conclusion¶

Computer Architecture Concepts and Evolution is a book on computer Concepts and Evolution, not one which teaches APL.