Letter to Editor

John Gaboury

Dear Editor:

The continuing controversy over the esoteric functions and difficult readability of APL is caused by a failure to realize the unique combination of (1) a concise notation, (2) an interpreter rather than a compiler, and (3) restricted workspaces has resulted in advantages and disadvantages that cannot be foreseen by considering each characteristic separately.

Using an interpreter means that each time a line is encountered it must be translated into machine language. If algorithms are written in the standard looping fashion, a lot of CPU time is generated just for interpretation. Concise APL notation, however, often permits one to write expressions that eliminate this looping for the interpreter. But the result is an unorthodox expression which is not readily understood.

When this situation is combined with a workspace limitation of 30K or 60K, and perhaps pressure to get results quickly, it is not hard to realize why documenting a function that takes less than 15 characters to express in APL is resisted by APL programmers. This is especially true when the documentation may require over 10 lines of comment within the function, as well as auxiliary explanations. The enclosed function acc is a perfect example.

acc expresses in less than 15 characters what is required. But even 16 comment lines and 25 lines of auxiliary explanation do not give a full appreciation of the power of acc . acc can be used anywhere that you derive an expression of the form f[t]←(f[t-1]×i[t])+d[t] for t taking the values 2, 3, 4, …, and f[1] given. d and i can be vectors derived in very complex ways. Furthermore, acc will also give all values f[t] of the form f[t]←(f[t-1]+d[t])×i[t] simply by writing (d×i) acc i instead of d acc i .

acc was timed on an IBM 370/168 and used less than 15% of the CPU that the standard looping method required for vectors 31 elements long. This saving results from the fact that APL has a concise notation and an interpreter. The saving increases with the length of vectors used and is enough to warrant use by APL programmers.

A programmer must be concerned about three things: (1) base programming time, (2) CPU time, and (3) documentation time. By base programming time I mean the time taken to write and debug programs with no documentation. Base programming in APL is at least 2½ times faster than in any other language and significantly faster still when done by an expert in APL. This is APL’s great advantage and is widely publicized.

CPU time is a concern if you want to maximize resources, have a lot of users, or have a relatively slow computer, and compact functions like acc should be used.

Documentation is APL’s biggest and most vexing problem. There is a greater need for documentation in APL than in languages such as Fortran, simply because functions like acc do not occur in Fortran. Since more documentation is required, more time is required if programs are to be properly understood. However, the limited workspace size deters most programmers from making adequate documentation.

I believe that this documentation problem can be greatly lessened, if not eliminated, by implementing three practices. First, document functions in one workspace while using an undocumented version to execute. Second, have a public library of programming techniques, standards, and gems like acc which are fully documented and can therefore be referred to concisely. This will save duplication of effort. Third, when documenting functions like acc , always show the looping version since this is what is easiest to grasp.

      ∇acc[⎕]∇

    ∇ z←d acc i
[1]  ⍝accumulated∆values ← deposits accumulation 
                                one∆plus∆interest∆rates
[2]   i←×\i
[3]   z←i×+\d÷i
[4]  ⍝    does the same thing as
[5]  ⍝ n←⍴d
[6]  ⍝ z←,d[t←1]
[7]  ⍝over:t←t+1
[8]  ⍝ z←z,d[t]+i[t]×z[t-1]
[9]  ⍝ →(t<n)/over
[10] ⍝
[11] ⍝     a general function which gives every value f[t] of 
                                f[t]←d[t]+f[t-1]×i[t]
[12] ⍝     where
[13] ⍝            d is a vector
[14] ⍝            i is a vector that cannot have any element 
                                equal to zero except the last
[15] ⍝              element since ×\i would make every following 
                                element equal to zero.
    ∇

      acc∆how

     Let d[1] d[2] d[3] d[4] be a vector of savings account deposits at various times t[1] t[2] t[3] t[4] and let i[1] i[2] i[3] i[4] be one plus the interest earned between deposit times. For example, if interest is 3 percent between t[2] and t[3] , then i[3] is 1.03 . We also need a dummy value for i[1] in order to make i and d of equal length. i[1] can be any value except zero. The following shows how acc calculates the answers.

If d is 2 1 3 4 and i is 1.01 1.02 1.03 1.04 then d acc i gives 2 3.04 6.1312 10.376448