I-APL Technical Specification

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

0 Introduction¶

This document is the technical specification for I-APL, a full function, portable, freely available public domain APL interpreter for small computers.

As the design and development of I-APL progresses, the technical specification will become more detailed. There are a number of issues which have not yet reached conclusion, and as they become concrete, so subsequent specifications will reflect this.

The specification consists of five parts; an overview followed by hardware, language, environment, and exclusion sections. The hardware specification includes details relating to target machines. The language section contains the specification for the I-APL language itself, and in particular how it relates to the text of the Draft International Standard for APL. The last section contains technical information relevant to aspects of the APL environment, as distinct from the language. Finally the exclusion section includes a checklist of features which are not planned for implementation in I-APL.

1 Overview¶

I-APL is designed to be a standard-conforming portable APL interpreter for small computers. The standard referred to here is the English text for the Draft International Standard for the programming language APL, or DIS 8485, ISO document number ISO/TC 97/SC 22/WG 3/N55.

Furthermore, I-APL is designed with the education market strongly in mind – full standard-conformance and the minimisation of interpreter size are the twin goals which subordinate execution speed and productivity features. Therefore I-APL is not to be considered a commercially viable product. In particular, there will be no file system or full-screen i/o, and the maximum theoretical workspace size will not exceed 64K bytes.

Effort will not be spent on ‘smart algorithms’. For example, the naive bubble sort will be used where required, and symbol table searching will be strictly linear. Additionally, the more esoteric algorithms necessary for a conforming implementation (Eg matrix inverse, matrix divide, dyadic transpose and the transcendental, gamma, and binomial functions) will be candidates for ‘magic functions’, ie they will be implemented using APL itself, in a manner transparent to the user.

The implementation language will be Forth-like, and the generated object code will be a universal intermediate language which is executed by a small machine-code interpreter. Porting will therefore consist of rewriting a small number of routines particular to the processor and environment of each target machine. The development environment will be initially developed on a PC clone. Paul Chapman will develop the implementation language, the APL interpreter and a small compiler, written in C, to tranlsate to the target machine’s language.

2 Hardware specification¶

I-APL will be implemented for use on the following target machines:

Apple II
BBC model B
Commodore 64
CP/M-based micros
IBM PC and clones
Sinclair Spectrum

Every effort will be made to make it as easy as possible for I-APL to be ported to other small machines. We hope to encourage rather than discourage this activity by providing hooks, handles and documentation wherever they are appropriate.

The size of the interpreter will not exceed 30K bytes, and it is hoped that a final size of 25K bytes will be achieved.

3 Language specification¶

I-APL will include all the defined facilities and implementation-defined facilities required by the ISO standard, and will achieve a very high level of conformance with the standard. This phrase is used not because it is planned to skip over certain features, but because we recognise that in practice complete conformance is unlikely.

The optional facility ‘trace and stop control’ will be included, but the shared variable protocol and statement separator facilities will not. A number of consistent extensions will also be made.

3.1 Specified facilities¶

The following is a list of standard-specified facilities currently planned for inclusion in I-APL:

3.1.1 Functions, operators and variables¶

All primitive functions, operators, system functions and system variables specified as defined facilities in the standard. That is:

Primitive functions

Also, the ‘with axis’ forms of the following:

Operators

Also, the ‘with axis’ forms of the following:

System functions

System variables

3.1.2 Miscellaneous¶

Assignment, branch, parentheses, quotes, labels and end of line comments, as specified.

3.1.3 Quad and quote-quad input and output.¶

3.1.4 Stop and trace¶

The ‘stop and trace control’ optional facility for querying and setting function trace and stop control.

3.1.5 System commands¶

It will probably not be possible to provide )COPY on machines which are tape cassette rather than disk-based.

3.1.6 Function editor¶

A del-type line editor for defining and editing functions. Blank lines will be allowed in defined functions.

3.2 Consistent extensions¶

The following list of consistent extensions is planned for inclusion in I-APL:

3.2.1 Replicate¶

The left argument of compression will be extended to the domain of positive integers.

3.2.2 QuadCALL¶

A facility for executing programs written in the machine language of the host computer.

3.2.3 QuadPW¶

A facility for querying and specifying a printing width parameter.

3.2.4 Scalar extension¶

Dyadic scalar extension will be less strict than described in the standard, and will be behave as implemented on most APL systems. That is, a single element array of any rank will conform with any other array.

3.2.5 Base value shape requirements¶

The shape requirements for the arguments of the base value function will be less strict than described in the standard. That is, a unit dimension in the last axis of the left argument or in the first axis of the right argument will be replicated to match the length of the corresponding axis in the other argument

3.2.6 )PCOPY¶

The )PCOPY system command will be provided in disk-based versions of I-APL.

3.2.7 Join on empties¶

Joining (catenating) two empty arrays of different type will produce an empty result, rather than the error signalled in the standard.

4 Environmental features¶

The following list of features related to the APL environment is planned for inclusion in I-APL:

4.1 Atomic vector¶

A 256-element single character atomic vector will be implemented. All the ASCII characters will be included and will appear in their usual positions. A full range of APL special symbols will be included.

4.2 Character representation¶

There will be no difference between the internal and external representation of characters in the system.

4.3 Provision of APL characters¶

APL special characters will be provided on at least one target machine. For other target machines which permit a programmable character set, the APL characters will be provided in a form that will easily allow a porter to install the set. The target machines known to include a programmable character set are the BBC model B, the Sinclair Spectrum and the PC (with colour card). The target machines that are not known to include a soft character set are the Apple II, the CP/M-based machines and the PC with monochrome graphics adapter.

4.4 ASCII representation of APL¶

All the target machines will allow APL to be entered and displayed using an ASCII representation. The details of this are currently being worked out, and a proposal will appear soon. A keyword or mnemonic approach is considered less desirable than a direct transliteration scheme, although this may not be possible.

4.5 Alphabet¶

The upper-case alphabet will be available for constructing identifiers, comments and character constants. The lowercase alphabet will not, if as expected it is reserved for use in the ASCII transliteration of APL symbols.

4.6 Internationalisation¶

All I-APL error messages and system command names will be stored in special tables at identified locations so that alternative language versions of I-APL may easily be created.

4.7 Porting and upgrading¶

Porting hooks will be provided whenver possible to encourage the transfer of I-APL to other machines, and to facilitate the provision of extra features. For example, hooks will be provided to permit the development of full-screen I/O and arbitrary output translation.

4.8 Numeric representation¶

The internal representation for the numbers has not been finally decided. There are two possibilities; either a single representation will be used for all numbers, or a multiple representation will be used. If a single representation is chosen it will be a single precision floating point representation of either 4 or 5 bytes. If a multiple representation is chosen, a three-fold split is likely; the floating point representation, 2 byte integers and 1 bit booleans. Note that the advantage of the bit booleans would be purely one of space – no boolean processing optimisations are planned.

4.9 Printing¶

A facility to echo the current session to a printer will be provided, as will the capability to print the contents of a character array.

5 Exclusion¶

The following list is a checklist of features that are not currently planned for inclusion in the I-APL base product. It is here to indicate that the features were considered for inclusion and rejected rather than not considered at all.

5.1 A filing system¶

Other than the transparent one required to save workspaces in a library.

5.2 Shared variables¶

5.3 Graphics support¶

5.4 QuadPEEK and QuadPOKE¶

5.5 A statement separator¶

5.6 Complex numbers¶

Complex numbers and complex arithmetic will not be implemented. Also, raising a negative number to a fractional power will produce a DOMAIN ERROR, even when a real result is possible.

5.7 Generalised arrays¶

5.8 Extensions to upgrade and downgrade¶

5.9 A defined function locking mechanism¶

5.10 )RESET¶

)SIC will be implemented.

5.11 S-delta and T-delta¶

The S-delta and T-delta mechanism for setting handling stop and trace vectors will not be implemented. The corresponding system functions will be present.

5.12 Change name class of functions on the stack¶

It will not be possible to expunge or fix a function that is pendent, waiting or suspended at a lower level than the top of the SI stack.

5.13 Invalid assignments to system variables¶

An attempt to assign a system variable with a value outside its valid value set will signal a LIMIT ERROR.

5.14 )COPY for tape machines¶

The system commands )COPY and )PCOPY will not be provided for tape-based machines. They will be included in the disk-based versions of I-APL.

5.15 Screen print¶

The ability to print the current screen contents to a printer will not be provided.

5.16 Program execution of system commands¶

System commands will not be in the domain of the primitive execute function.

5.17 Workspaces larger than 64K bytes¶

A theoretical limit of 64K bytes for workspaces will exist, even for machines that could support larger ones.