APL and GKS

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

… with the emphasis on the word Standard.

It is well known that standards imply:

• some reduction in facility.
• poorer performance.

… but at least your applications are portable. Of course this leads to an ambivalent attitude on the part of suppliers (notably IBM) who find it much harder to lock people in to a ‘standard’ system. APL itself is highly standard (and hence APL systems are very easy to move), but the same is not true when you start doing graphics. This problem also applies to FORTRAN, PASCAL etc., so it was from here that the motivation for GKS first came.

What is GKS?¶

GKS is an abstract model covering around 300 graphics concepts (e.g. ‘POLYLINE’). In many ways it is similar to GDDM, and in the same way one finds that different languages get at the facilities in different ways (called the ‘language binding’ in the standard). Outside the standard are various agreed bindings for FORTRAN, PASCAL etc. … what is needed is an agreed binding for APL (just as AP126 is the default standard for access to GDDM).

Why bother? There are several good reasons for defining such a standard:

• it will persuade software developers to take APL seriously. In particular anyone developing
• graphical software will be encouraged to include APL in their list of target languages.
• it will make APL more independent of particular hardware.
• the hardware itself is becoming increasingly GKS oriented.

So, having decided that the whole exercise is worthwhile, what kind of APL binding should we use?

What is the Form of the Binding?¶

There are essentially three options, none of them a clearcut winner. Firstly, you could use quad-functions. The snag here is that there could be around 300 of these! Even with some cunning use of dyadic calls to rationalize things, this is still a whopping patch to the interpreter.

Secondly, you might go via an auxillary processor and shared variables. This has the benefit of familiarity (at least to regular GDDM users), and is potentially very efficient. It resides outside the APL interpreter, so space is much less of a problem than in option-1. However the ISO standard for APL does not specify shared variables! This pretty well rules this one out, as it would be very illogical for an ISO-conforming APL to be unable to access a standard GKS binding!!

The third option is to leave it all to user-defined functions (which are part of the ISO standard!). The merit of this approach is its universality, and the fact that no patches are needed to the APL interpreter. However it is likely to be much less efficient, and you will probably end up with rather a lot of functions. GKS is extremely comprehensive, and covers all sorts of CAD/CAM requirements as well as more familiar graphics.

Underneath the covers these functions will doubtless consist of incomprehensible strings of quad.ARBOUTs and quad.WPUTs; the point is that they can be written once, and then forgotten about. As with GDDM there will probably be at least two levels of APL software buffering the application developer from the real guts of the GKS binding.

Where Next?¶

A good start would be a UK initiative to get things going; hopefully Seattle will provide a forum to start real discussions on GKS. VECTOR is always available to publish reactions to this proposal; for more details see VECTOR (Vol.1 No.2) or any of a range of literature on GKS. Beware - some of this is not for the faint-hearted!