APL and Graphics Standards

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

Now that the bang of your head on the table (reaction to the word “standards”?,) has woken you up again, there are some things to be said about linking APL to the computer graphics world and doing it sensibly, so that we can take advantage of what other people are doing, and they have less of an opportunity to think of us as a bunch of iconoclastic weirdoes.

What’s APL Got To Do With Graphics?¶

Quite a lot, I think; on two bases:

a)

Graphics offers the same sort of productivity to users that APL offers to program developers. Taking the view that one major attraction of APL for the program writer is the ability to see what’s going on as it happens, there is a symmetry to also being able to provide visualisation to the end user at a similar level of immediacy. You just can’t tackle this by filing data away and logging on to another system every time you want to draw a picture; graphics have got to be immediately accessible from within the APL environment (I recognize that there are recent developments on some implementations which do, in principle, offer very flexible access to non-APL facilities).

b)

More seriously, taking graphics at a more abstract level than piecharts and histograms, what is being manipulated by a graphics program is objects. Now what are objects but collections of coordinates in n-dimensional space? At a simple level, in 2D space we could have a square defined as a set of four pairs of x—y values. We would then like to be able to move it, rotate it and magnify it. The obvious approach is to handle the square as a 2x4 or 4x2 array. One would think that a language which handles arrays implicitly would be at something of an advantage over scalar languages.

What Has The Computer Graphics World Been Up To?¶

Once upon a time graphics were a hideously expensive business to get into (particularly interactive screen-based graphics) and you needed all the computational power you could get. Graphics programs were written to operate with specific hardware: inside your graphics program you would be specifically incrementing the pen of, say, a Calcomp pen plotter.

Gradually, an evolutionary process occurred in which falling entry costs and device diversity led to increasing recognition of the problems associated with customisation of application programs to specific items of hardware. For example:

i)

Calcomp software — many other manufacturers supplied software to permit their hardware to emulate Calcomp pen plotters.

ii)

Manufacturer packages — stemming from the wider introduction of hardware with more extensive features (e.g. graphics input); a prime example being the Tektronix PLOT10 package.

iii)

Independent standards — the SIGGRAPH Core proposal, the ISO GKS, or “Graphical Kernel System” standard. There are two immediate points of comparison between Core and GKS; Core is intrinsically a 3D standard, while GKS is 2D. GKS nevertheless looks closer to becoming an accepted standard in the ISO-BSI meaning of the word.

There is good reason to suppose that graphics standards which emerge from a wider base than individual manufacturers or users will achieve some stability and widespread recognition. Already in the world of FORTRAN programming you acquire leper status if you persist in writing graphics applications without due regard for either Core or GKS. Equally, manufacturers are beginning to produce graphics terminals which are themselves bound to the standards (note this reversal of direction).

One other aspect of GKS which is worthy of note is that the standard introduces a concept of language binding; implementations of the standard which are invokable from a particular programming language must all use exactly the same calling protocol — even to the extent of using the same subroutine names.

Something else about GKS should strike a familiar note; the main line-drawing primitive is the “polyline” — it draws a line through a set of points. In other words, GKS treats single points as a special case of multiple points.

What’s The APL World Been Up To?¶

So far as I can tell, the APL community has been its usual independent self; often invoking the cry “we don’t need to worry about that, we’re too busy being productive”. I don’t want to detract in any way from the excellence of some of the work that’s been done in APL with graphics as its end-point; the IPSA graphics which lie behind packages like SUPERPLOT spring immediately to mind, as does the achievement of IBM in making the 3279 display screen combine graphics with text dialogue. There have already been proposals for implementing the Core standard in APL (1,2).

Nevertheless, I get a distinct flavour of low-tech when I look at the general approach to graphics in the APL world; devices like Anderson-Jacobson paper terminals seem to be the norm, with few applications stretching beyond the business graph.

Equally, I am interested to note that the “leader” among APL graphics software is probably IBM’s GRAPHPAK (3), at least in terms of market penetration. If GRAPHPAK has a philosophical stance, it certainly isn’t one of alignment with either Core or GKS.

Looking to the future, I predict that we’ll be seeing a lot of the APL*PLUS/PC graphics functions (4); but you don’t design a graphics package by copying Microsoft Basic: anyone intending to work seriously with this system is going to do themselves a long-term favour by creating a set of appropriately-designed cover functions.

Can We Do Anything About It?¶

The first step we have to take is to recognize that there is indeed a problem.

As a next step, we should begin to familiarize ourselves with what the rest of the world is doing. Both GKS and Core have complete (if dry) descriptive documents (5,6); there’s also a quite readable textbook about GKS (7). Further background reading on computer graphics is plentiful, (8) being a recommended example.

I would suggest also that anyone planning to work in the graphics area makes a conscious decision to implement functions at the level defined within either Core or GKS, building up in classic fashion to the levels needed within the application. Even if you initially intend only to produce the usual business graphs you’ll have laid a foundation for the more imaginative displays exemplified by (9).

One could do worse than adopt GKS as a standard for two reasons:

a)

GKS looks like beating Core to the status of being an accredited standard as opposed to a draft proposal;

b)

2D systems have limitations, but they should be easier to produce and have a pragmatic advantage that the most useful (if not the prettiest) business graphics are 2D. Most graphics terminals also are 2D.

Having homed in on GKS, we then note it as concerning itself with language bindings; if we want to be taken seriously we’d better get down to at least agreeing these among ourselves. Multiple contradictory APL implementations of GKS, all with differing function names, are not going to go down well with the rest of the graphics world.

Is Anyone Out There Working on an APL GKS Implementation?¹¶

APL has a lot to offer the graphics world. Non-APL graphics users are beginning to show some signs of recognising that they have needs for the sort of solutions that APL offers. It may be hard for you to accept, but the majority of them have never even heard of APL.

We can make ourselves known, but before we do this there has probably got to be some element of setting our own house in order. I suggest that we begin to dialogue with the GKS people to see whether a GKS language binding for APL is a viable proposition. The British APL Association could provide a platform on which we might base an approach, but there’s no point doing anything unless we can agree amongst ourselves what we want to do. Any such proposal would in no way remove incentives for individuals to produce packages as they see fit.

References¶

1. Faconti and Palamides; Practicing on the Core Graphics System; APL82 Proceedings, pp105—109
2. Freiden; A Core Viewing System For APL; Computer Graphics, March 1979, pp55—77
3. VSAPL GRAPHPAK: User’s Guide and Reference; IBM SH20—9199
4. APL*PLUS/PC Programmer’s Reference Manual Release 3.0; STSC
5. Status Report of the Graphics Standard Planning Committee; Computer Graphics, August 1979
6. Functional Description of the Graphical Kernel System Version 7.2; ISO/DIS/7942
7. Hopgood, Duce, Gallop, Sutcliffe; Introduction To The Graphical Kernel System — GKS Academic Press, 1983
8. Foley and Van Dam; Fundamentals of Interactive Computer Graphics; Addison Wesley, 1983
9. Robertson; A Graphic Vision of APL; VECTOR, June 1984