GKS – Opportunity for APL

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

Introduction¶

Traditionally, APL has been out of the mainstream of computing. A lofty disregard for most of the things which DP professionals regard as important has characterised the world view of APLers, although in many cases this disregard has been justified by subsequent events. The result of this has been that APL has continued on its own course, with little recognition of the good things which the non-APL computing world has been doing. Even today, you come across APL ‘experts’ who seem oblivious to the power and simplicity of spreadsheets such as Visicalc and Lotus 1—2—3. It is illuminating to look through the proceedings of the annual APL conferences, where you find surprisingly few papers which look outside the confines of the APL workspace.

Probably the greatest step forward in overcoming the insularity of APL has been the introduction over the past few years of versions of APL for microcomputers. Many of the micro implementations of APL have included good ‘hooks’ to the outside world to allow easy integration of, for example, word processing with APL applications. APL users are becoming more aware of the advantages of this kind of synergy, and this is certainly progress. Another very significant move is the current work being done on the ISO standard for APL; most industry commentators now feel that the main concern of users is moving away from the performance of their computer systems, towards issues of portability, standardisation, and links between different software suites. The forthcoming ISO standard for APL seems to me to be strong evidence for the argument that the APL community is taking these trends seriously.

It is surprising, therefore, that there has been so little interest in the APL world in the GKS or “Graphical Kernel System” standard. This is even stranger when you consider that APL has for a long time been quite closely associated with graphical applications (admittedly usually of the business graph variety, rather then animated or CAD/CAM graphics). I feel that it is time that the APL community considered its response to GKS.

What is GKS?¶

For many years, computer graphics has evolved in a very hardware-dependent way. Major manufacturers such as Tektronix and Calcomp have produced graphical devices with their own interface protocols and conventions, and of course with different capabilities. As usual, IBM has gone its own way, and has remained incompatible with any other supplier, whereas smaller manufacturers have often tended to emulate the protocols of the main vendors, by for example, selling equipment which is ‘Tektronix 4010 compatible’. On the software side, the routines to access graphics devices have also been highly diverse in the way they have handled graphic instructions. The net result of all this has of course been that applications software which makes use of graphics has tended to be much more machine-specific than software which uses only text input/output.

In keeping with the overall trend in the computing industry towards a greater emphasis on international standards, various influential groups and individuals have been working since 1975 on a graphics standard which would remove this ‘Tower of Babel’ style of graphics development, and substitute a clear, well defined and above all flexible standard protocol for interfacing computer software to graphics devices. The initial work was done by the German standards institute (DIN), and later taken up by experts from 16 countries, including a strong UK team. The final result of all this is an ISO standard, which is now complete, and which has international support from most major suppliers of graphics devices. In addition to its International status, GKS is expected to be adopted as a national U.S. standard by ANSI, although another rival graphics standard (‘Core’) has its supporters in the States.

What does GKS look like?¶

Because of the need for the GKS standard to be comprehensive, as well as free of dependencies on particular hardware or programming languages, it is expressed as a rather abstract model, expressed in a number of levels. Some VECTOR readers may be familiar with one vendor’s low-level graphics system, namely IBM’s GDDM, and so I will illustrate the features of GKS by reference to GDDM.

GKS defines a number of a logical graphics functions such as ‘POLYLINE’ (draw a series of lines) and ‘FILL AREA’ (fill arbitrary polygons with specified colours and patterns). These are low-level commands, and correspond roughly with GDDM’s low-level concepts. The most basic GKS commands (which nonetheless are sufficient to implement very good graphics systems) are defined as Level 0a, and are intended to be suitable for business graphics, as well as providing the low-level support for higher level commands. Level 0a defines only graphics output, without any digitising or interactive graphics capability. An implementation of GKS might, therefore, restrict itself to being an implementation at Level 0a, and ignore the more sophisticated features.

Levels 0b and 0c are the same, except that they add input facilities for interactive graphics applications.

Moving up to Level 1 of GKS, further features are added, including support of multiple workstations, display of several pictures simultaneously, manipulation of parts of pictures, etc. Level 1 (again subdivided into 1a, 1b and 1c) would generally be used for simple Computer Aided Design or interactive simulation software.

Finally, Level 2 adds features such as copying whole graphs, or ‘segments’ of graphs, between workstations, use of pre-defined picture segments, etc. This level is aimed at sophisticated CAD and graphical editor applications.

Provision is made at each stage for the application to query whether or not a particular feature is supported by the software and/or the hardware in use.

Language Binding¶

The GKS concepts described above are defined in an abstract fashion. For example, POLYLINE is defined as a GKS function for drawing a series of straight lines, and it takes a set of parameters consisting of the number of points (needed for crude languages which have not heard of the APL ‘shape’ primitive), and the XY coordinates of the points through which the series of straight lines should be drawn. The line is drawn using a preselected linetype, width and colour.

The jargon ‘language binding’ is used to describe a standard way of interfacing a given computer language to the abstract GKS functions. Associated with the ISO standard is a ‘language binding’ for Fortran. This specifies, for example, that the GKS function POLYLINE should be accessed by a Fortran subroutine called GPL, using the syntax:

CALL GPL (N,PX,PY)

where N is the number of points, and PX and PY are two arrays of the coordinates, expressed as real numbers.

As well as the Fortran binding, there is also a semi-standard Pascal binding, although this has not been incorporated in the GKS ISO document.

To understand this more closely, consider GDDM again. GDDM defines a set of graphics functions which can be accessed from a number of languages. In APL, the interface (‘binding’ in GKS jargon) is AP126, whereas other languages have their own IBM-defined methods of accessing GDDM.

An APL binding for GKS¶

This is where we come to the crunch. Is it possible, or indeed even desirable, to propose a standard interface between APL and GKS?

My own view is that it is highly desirable that there should be a standard APL interface to GKS. The main reasons for this are:

(a)

It will increasingly be the case that mainframes, minicomputers and even microcomputers will be supplied with GKS implementations. It is highly desirable that APL should be able to access these, and it would be a great pity if each vendor came up with its own syntax (again!) for doing what other languages wil be able to do in a standard way.

(b)

It will also be increasingly the case that manufacturers of graphics devices will design the interfaces to their hardware with GKS in mind. If APL is to get the best out of such hardware, access via GKS routines will be both simple and efficient.

(c)

It will add greatly to the international credibility of APL, and further the progress which the APL ISO standard has made, if the APL community is seen to be taking international standards like GKS seriously.

As to the question of whether it is possible to define an APL binding for GKS, my answer is yes.

How would an APL binding for GKS look?¶

It seems to me that there are three possible ways of defining a standard interface between APL and GKS.

Method 1¶

The interface to GKS could be defined by a Shared Variable Processor. This would look roughly like IBM’s AP126 processor which links APL with GDDM. Most probably, there would be a Control variable (CTL) and a Data variable (DAT) which between them would govern the interface to GKS. CTL would be used to indicate the GKS function required, and DAT would be used to pass parameters (such as coordinates) to GKS and receive back data from enquiries to GKS. GKS functions would be indicated by (probably) numeric codes. For example, to draw a polyline, we might enter:

DAT <— LINEDATA
CTL <— 11

In this example, LINEDATA would be a 2 by N numeric matrix of the points through which the polyline would pass, and 11 would be the code which the binding standard had assigned to the GKS function POLYLINE. (This is the number defined by the so-called Metafile format for GKS, so there would be a correlation between the APL codes and the GKS main standard).

If it were felt advantageous to avoid numeric codes, we could use an alternative form:

DAT <— LINEDATA
CTL <— 'POLYLINE'

i.e. We could use text names or mnemonics to indicate the GKS call required (although this could reduce efficiency of execution).

The advantages of Method 1 are as follows:

1. It would be similar to IBM’s AP126, which is already widely used, and it might even be possible to provide partial compatability between applications for GDDM and applications for GKS, using table lookup to translate between the two.
2. It would involve no additions to the APL language.

The disadvantages of using Shared Variables to access GKS are:

1. Shared variables are defined in the ISO APL standard as an optional feature. This means that not all ISO-standard APL interpreters could use this method to access GKS.
2. The use of numeric codes to indicate the GKS function required might be considered rather opaque, although it would have the advantage of being independent of national language.

Method 2¶

A second method of defining the binding is to propose a list of APL function names and syntax definitions for those functions. In other words, access to the GKS system would be via (presumably locked) APL functions, which could internally use any method they liked to get at GKS, but which would have an agreed form. This same example shown above might be simply:

POLYLINE LINEDATA

where POLYLINE would be a locked function. The choice of the names to use for the functions could be as above, although it might be better to use the same names as the Fortran binding standard uses for its subroutines. In this case, the above example would be:

GPL LINEDATA

The advantages of this method are:

1. It could work with any APL implementation, irrespective of whether shared variables were available.
2. It would be simpler for less sophisticated APL users to take advantage of this method, since shared variables are something of a mystery to some APLers.
3. Again, the APL interpreter itself would not have to be changed.

The disadvantages are:

1. Using defined functions would be cumbersome, because there are something like 300 GKS functions defined.
2. It might reduce efficiency in critical applications.
3. It might be considered odd to have user-defined function names reserved for a low-level international standard interface.

Method 3¶

Rather than using defined functions, a more extreme course of action would be to use Quad functions to access GKS. My first reaction to such a suggestion is that it would not be practical to do this, because of the large number of Quad functions required, plus the fact that it would involve major additions to APL interpreters (which will not always be using GKS).

Case Study: one reader’s approach to the GKS — APL connection¶

MicroAPL Ltd is keen to promote a standard interface between GKS and APL. The steps which we are proposing to take are as follows:

(a)

We will probably be implementing GKS on MicroAPL’s Mirage-based range of APL microcomputers. This will be done by an operating-system add-on which implements GKS, at least at the low levels (up to Level 0a initially), and which will be accessible by APL and by other languages, including Fortran using the standard GKS-Fortran binding.

(b)

We will invite interested parties to send comments to us on the best overall method of interfacing APL and GKS, with the intention of being able to submit a paper for APL85 with a suggested language binding. At the same time, we will implement the suggested binding on our equipment, to give those who are interested the opportunity of trying it out. Although we have not reached any firm conclusion on the best form of the binding, our current thinking is that, overall, Method 2 represents the best compromise, with the function names identical to the equivalent Fortran subroutine names (with some minor exceptions in the inquiry functions, to reduce the number of distinct names).

(c)

If there is enough support, we will propose the binding to the various standards committees in the hope that an agreed APL-GKS binding may be incorporated as an international standard.

(d)

We would welcome contact with interested users, and other APL vendors, in making this initiative more widely-based.

Conclusion¶

GKS represents a major opportunity for APL to become associated with standard graphics applications. If a standard binding can be agreed, APL will be a natural choice for many of the graphics packages of the future. If GKS is ignored by the APL community, much of the benefit of international standardization will be lost to APL users. Action is needed to take advantage of this opportunity for APL.