I-APL: History & Achievements
Vector 4:3, page 89
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 89
Paper given in the Education Stream of the Danish APL Association Meeting September 1987
Printed by permission of the APL group of the Dansk Databehandlingsforening
Introduction¶
Those who have had to teach subjects, such as maths stats and physics, involving many mathematical evaluations, have regretted that computers have been so little used in teaching. Those of us who know about APL are always surprised how little it is used in schools because it seems to overcome some of the difficulties admirably.
Paul Chapman added another ingredient to this dissatisfaction and surprise – the proposal that it would be possible to write an APL interpreter small enough to run on school and home machines. This addition catalysed a reaction and at APL 86 a committee was elected to raise money and execute the project. That was in July 1986 and as you know execution is a slow function. We have just (Sep 87) begun some beta-testing. This paper is to tell you something about the I-APL project, its history and the I-APL interpreter which it has produced.
The fund raising¶
I don’t want to say anything about this except that it was difficult: we are still very short of money and will need to pay for the printing of manuals soon. Any contribution you can make will be very welcome.
The Organisation¶
Five people were elected to the original committee: Ed Cherlin and Anthony Camacho to be a chairman each side of the Atlantic, Howard Peelle and Norman Thomson to manage education each side of the Atlantic and David Ziemann to act as technical controller. Dave was at school with Paul Chapman and has been friends with him for many years. A Limited Company was formed in the UK with these five people as directors. We did this because a company has to report its accounts each year and we wanted to give contributors confidence that their money would be well and publicly accounted for. In addition to the committee Garry Helzer, Linda Alvord, Sylvia Camacho and many other people have given a great deal of time to the project.
Objectives¶
The five directors declared that the object is to write and issue, together with appropriate supporting documentation and workspaces, an APL interpreter for which there will be no charge. The project may have to charge for copying and materials but prices will be judged to break even rather than make a profit. The directors have undertaken never to pay any fees to directors nor to pay any dividends to shareholders. Most of the expenses that people have incurred have not been claimed. Any surplus funds are to be used for the promotion of APL. Note that the project is to promote APL – not I-APL which is just a means to the end and not an end in itself.
Free, standard and without commercial bias¶
One of the obstacles which deter educational establishments considering the use of APL is that every version of APL is a proprietary product and it would be wrong for a school to promote a particular vendor. None of the vendor APLs completely conforms to the ISO standard. It was a piece of good luck for us that the standard was in draft when we began and that we were able to make I-APL conform to it.
We decided that not having a vendor (because the product is free) was a great advantage which we could double by sticking to the ISO standard. Paul Chapman used the standard as his guide during the design of the primitive functions. He found several places where the standard was not well expressed but as David Ziemann is chairman of the ISO APL committee the problems were solved.
I-APL can be used with current introductions to APL. An APL which would be free, standard-conforming and impartial between vendors would be ideal for the educational world but if that meant it would have to begin life without being able to use the current world stock of APL texts and software nobody would be able to use it. Many of the best texts use direct definition: the ISO standard includes the Del editor. We felt we had to implement both. Dave Ziemann has started on the road to establish compatibility by writing a workspace which transfers APL*PLUS/PC workspaces to I-APL/PC form.
Product documentation¶
We also needed documentation to go with the product. A reference manual, an introduction to APL and an installation manual seemed to us to be the minimum. The first two could apply to any version of APL. Everything which was specific to I-APL or to the machine implementation could be put in the installation manual. Garry Helzer has written the reference manual. It is called “An APL Encyclopaedia”. Norman Thomson has written the APL Tutorial, using some material supplied by Linda Alvord. Both these are finished and almost in camera ready form. All we have to do is find a publisher or pay to print them ourselves.
The installation manual¶
The third text is being worked on. To be acceptable to people who have become used to the facilities of their machine, any new piece of software must give access to the graphics, colour and sound of the native machine, allow printing of APL on the common printers and provide means for owners of uncommon printers to patch their machine so that even they can be used. This work cannot be done before the beta testing: the last part of the manual writing cannot be done until this work is finished. For this reason we expect not to issue any free APLs before December at the earliest.
Messages in any language¶
To justify the slogan “The Free International APL” we had to build the interpreter in such a way that it would be easy to change the messages into any other language. Our original method caused some difficulty for porters producing versions for languages which had word orders different from English. Paul has revised this part of the interpreter with Kim Andreasen’s advice and there should now be no difficulty in producing all the messages in any language which uses the roman alphabet.
Easy porting¶
To make the interpreter easy to port, Paul decided to write the APL in an intermediate language. This language was to be as simple as he could make it and so would not require much work to implement or much space in the machine. The language is called DE which you may think of as standing for Development Environment or as being two better than ‘C’. The I-APL interpreter is written in DE and compiled into a fixed final form which will be exactly the same in all machines (a file of a little over 25K). It passes all messages to the screen or printer via the DE interpreter which nowadays is usually called DEGO. The double interpretation, once as DE and once as APL inevitably means that I-APL is slow. However to port it to another machine all that is required is an appropriate DEGO. As we now have versions of the interpreter running on the 8086, 80186, 6502, Z80 and 68008 CPU chips the amount of work to be done for another machine using one of these chips is quite small. The largest task is to rewrite that part of DEGO which handles the links with the native operating system.
Workspaces are compatible between all I-APL machines¶
Another consequence of building I-APL as a fixed file interpreted by a DEGO is that the fixed file controls all the formats of the objects and of the whole workspace. All workspaces )SAVEd in one version of I-APL can be )LOADed into any I-APL. There is only one single machine dependent function. It is called quad-MC and is the machine code call. If a workspace does not use this function then it will run and produce the same results on any machine. We believe that this will be particularly valuable in education because if a school in Italy produces some good geaography workspaces they can easily be used in Japan or anywhere else even if the machines there are totally different.
Cover functions for graphics and colour¶
Educational workspaces would benefit greatly from imaginative use of colour and graphics and it seemed a pity that we could not find a way to help transfer of good work between incompatible machines. Paul hopes to find time to specify an approach to doing graphics and colour work in I-APL so that even if quad-MC is used to produce pictures, the graphic functions for machine 1 can be erased from the workspace and replaced by the graphic functions for machine 2. When this is done the workspace should run giving the nearest that machine 2 can manage to machine 1’s display. We do not expect to have this facility ready this year (1987).
The features of I-APL¶
The demonstration of any good APL interpreter should be boring because everybody knows what it should do. Demonstrations of I-APL are now beginning to be as boring as they should be. It is a complete ISO-conforming APL. It has 21 scalar dyadic, 13 scalar monadic, 22 dyadic mixed and 11 monadic fixed functions. It has three dyadic operators and four monadic operators. Quad and quote-quad can both be used for input and output. It includes indexing and indexed assignment, a suitable selection of system commands and system variables and functions. The main enhancements are replicate and the direct definition feature.
Replicate¶
In standard APLs the left argument of compress must be a boolean with as many values as the appropriate dimension of the right argument. The result consists of just those items from the right argument corresponding to the ones in the boolean. Replicate allows integers as well as booleans in the left argument and gives as many copies as the left argument requires of the selected items from the right argument.
Direct definition¶
All directly defined functions are “ambiguous”: they may have one argument or two. When a directly defined function is called it must be given a right argument. Typing the function name alone followed by
There are two forms of direct definition. One includes a condition which can be used to select one of two expressions to execute, the other does not and consists of a single expression. The simple form consists of a name, a colon and an expression. In the expression alpha stands for the left argument and omega for the right argument. If any assignments are made in the expression the variables assigned are automatically localised. The result of the function is the result of whichever expression is evaluated.
Examples¶
In the examples below I have stuck to APL symbols available in ASCII and used lower case a and w for alpha and omega.
Here is the function LEV which returns its left argument unchanged:
Functions can call themselves or other functions. Here is a recursive factorial function:
Functions which contain a condition or test are of the form:
The test expression is evaluated first and should give a boolean result. If the result is one then the succeed expression is executed and its result becomes the result of the function. If the result of the condition is zero then the fail expression is executed and gives the result of the function.
Display and editing of directly defined functions¶
In the display of )FNS (but not of quad-NL 3) the directly defined functions are shown with a colon after their name. To display a direct definition function just type its name and return. The function will be displayed and control will then be returned to the keyboard. To edit a direct definition function type its name and a colon and it will be displayed with the cursor at the end of the line ready for you to amend it. If there is already a direct definition of a function and another definition with the same name is entered it simply overwrites the previous version.
Benefits of direct definition¶
People used to writing long functions with the del editor or a full screen editor find that recasting their thoughts to fit direct definition form is quite an effort. I suggest you try it. You don’t need I-APL. In Linda Alvord’s book “Probability in APL” or in “A Source Book in APL” (both published by APL Press) there are functions to allow entries to be made using the direct form. When you find a good way of fitting a task into the direct definition form it is extremely satisfying. I suspect that the use of direct definition encourages clearer thinking about the structure of an algorithm than is necessary when it is possible to write long functions with a screen editor. It is possible to write an APL imitation of spaghetti BASIC with a good screen editor but I doubt whether it could be done with direct definition.
Porting¶
The work is going on at this moment. There are over 25 people at work in USA, UK, Denmark, Canada, Sweden, Australia, Switzerland, Finland and Germany. Prototypes are running on IBM/PC, XT, AT and clones, Piccoline, BBC‘B’ and Master, CBM64, Amiga, a homebrew Z80, Sinclair QL and ARM or Archimedes. Two of these, the PC clone and the BBC B version are on beta test. We are also working on Sinclair Spectrum, Apple II, Nokia, Microbee, Atari ST, Wicat, Luxor, VAX, Wicat and IBM mainframe.