Essays/History of I-APL

History and Aims of the I-APL Project

(From: Camacho, A., Chapman, P., Clark, I., Ziemann, D., IAPL/Mac Instruction Manual: I-APL for the Apple Macintosh, Version 1.0, I-APL Ltd., 15/2/91)

At the International APL conference in Manchester in July 1986 an idea of Paul Chapman's was taken up by a group of enthusiasts. The idea was that it would be possible to write a full ISO-compatible APL interpreter in 25K which would run on school and home computers.

The I-APL Project was founded with a committee of five: Ed Cherlin, editor of APL Market News, and Anthony Camacho, then secretary of the [British] APL Association, were to be joint chairmen; Norman Thompson and Howard Peelle were to be education officers and David Ziemann was the technical expert. Fundraising began that summer and by October there was sufficient to authorise Paul to begin work.

Project aims

The project aims was to write and issue an APL interpreter which would run on as many school and home computers as possible, and be available in any part of the world. There would be no charge for the software but there would have to be some charge for the medium and for copying and also for the books which would go with it. The project and its supporters believe that if APL is to grow it must be made available in schools. Experience has taught us that efforts to interest school teachers cease to be effective as soon as the teachers discover that APL would be very expensive for them to try. By removing the cost barrier it was hoped that many people could be persuaded to try APL and that many APLers would be encouraged to introduce APL to teachers. The project has always seen the production of the interpreter as the first step and probably not the hardest step in the difficult job of getting APL into widespread educational use.

Progress

Paul Chapman finished the interpreter on 4 July 1987 and debugging, optimisation, improvements and customisation to the PC occupied the next six months. Version 1.0 was issued in January 1988 and we sold out of manuals in August 1988. Version 1.1 was completed in October 1988 and cures all the V.1.0 bugs reported to us as well as adding some new facilities. The most important of the new features is the option to send output to the screen through the BIOS; this allows PC clones whose display is not hardware-compatible to scroll the display correctly, though slower than the standard version.

The job of porting I-APL requires intimate knowledge of the operating system and reasonable competence at producing machine code programs for the chosen machine. What a porter has to do is to write an interpreter for the specially invented language DE in which the APL interpreter is written, and link it to the operating system of the machine for input from keyboard, for output to screen, printer, etc. and to give at least )SAVE and )LOAD access to the filing system for workspaces.

In addition to the porting job we like to have some workspaces which use the ⎕MC feature to give access from APL to the machine's filing system, graphics, colours and sound.

If you would like to have a go at a port please contact the project at the address below. If there is already someone working on your chosen machine we will put you in touch. They may give you a flying start or you may find you have just a knowledge which is holding things up. There is 8086, Z80, 6502 and 68008 machine code already available for most of DEGO.

(This invitation is of course antiquated.)

The Interpreter

The I-APL interpreter was written to take the minimum program space. This is necessary so that it can be used on the small computers generally in use in schools. Four example addresses are held in 16 bits, so a BBC "B", a CP/M machine (Z80), a CBM 64 or a [Sinclair] Spectrum can use all its directly addressable memory.

If your computer has more than 64K of memory I-APL will not be able to use the extra for the workspace itself. A clever porter may be able to store fast machine code routines in such memory and access them from within APL by a far jump; this is why the PC version uses 256K of memory - the DFILE, PGRAPH, FSCREEN workspaces are very small and most of the code is outside the 64K range. In the Apple Macintosh version, all extended code facilities are held in separate machine-code resources, which are read-into memory as needed. Whenever there was a choice whether to make I-APL fast or small we chose to make it small.

Variations between versions

Because the interpreter is itself interpreted, the APL is exactly the same on every machine. The only things that vary are the keyboard, the screen, the operating system (and the access to it), the details of how one can write machine code within APL and the method of dealing with printers and other peripheral devices. The porter writes the interpreter for DE in the machine code for the CPU chip at the heart of your machine. This program is called DEGO.

Workspaces are compatible

When you save an APL program, what is saved is the complete workspace. A workspace contains functions (the program), variables and all the APL system settings. If your program needs a print width of 192 you can set it to that, save the workspace and when it is reloaded the print width you set is also reloaded. A saved workspace will also contain the APL stack, so a program that has been interrupted by an error or your intervention can be saved and then, when reloaded, can be restarted at exactly the point where it was stopped.

Apart from use of the machine code call function [⎕MC], all I-APL workspaces will run on any I-APL machine. All you have to do is transfer the complete file from the disk or tape format of one machine to that of another (note that the first two bytes in the file give the length in bytes of the rest of the file). For example if the total file is 15 bytes long the first two bytes will be 0D 00. If your file transfer mechanism pads the length you will have to readjust it.

Thus a group of people using quite different computers can still use exactly the same APL, loading the same workspaces and getting the same results. The only difference will be in the keys they have to press and in the display and perhaps the print they get.

Books

The essential books for the project are as follows:

• This instruction manual.

• A tutorial for total beginners in APL. Norman Thompson produced the Tutorial and Linda Alvord and others helped with material.

• An APL reference manual, known as An Encyclopaedia of APL by Garry Helzer. Garry had been considering the desirability of producing an APL encyclopaedia with the primitives arranged in alphabetical order and the project provided the need and incentive to do it.

There are already several I-APL workspaces. These are available from the British APL Association Software library. For details see a recent copy of Vector, the Association's magazine. Some may be available through the CIX or other bulletin boards (join the APL conference).

I-APL can be used with any of the many APL books. In particular it includes both the Del editor which is part of the ISO standard and Direct Definition which is used by many of the best textbooks on APL. APL booklists are offered by the [British] APL Association, and by Renaissance Data Systems.

(The address is antiquated.)

For a British source of APL books see Vector (ibid.).