Skip to content

General Correspondence

Vector 3:3, page 9

APL community standards education

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

The VECTOR working group welcomes correspondence on any topic affecting the APL community. All such letters should be addressed to the Editor and should indicate whether they are intended for the general or technical section. Letters containing APL code will normally appear in the Technical section of VECTOR, and authors are asked to observe the requirements on the inclusion of APL code stated on the inside cover. The Editor reserves the right to edit any letter unless the writer states that the letter is to be published in full or not at all.

APL standards

Sir,

At a recent meeting of the BSI APL Panel, there was a long discussion on how we could best attract new members to join us in our exciting work. I hope that an appeal to the VECTOR readers may result in some volunteers coming forward.

Most of us have moaned because a package that runs on one computer doesn’t run on another. Result: you have to rewrite it!

This problem is now being overcome by the APL Standard. The document is shortly to be published as an ISO (International Standards Organisation) Standard, and this will be followed soon after by the same document appearing as a BSI (British Standards Institute) Standard.

But . . . it won’t cover all the modern facilities of current APL implementations. Both the ISO APL sub-committee and the BSI APL panel are gearing up to work on standardising some of these modern facilities:

generalised arrays, operator extensions, scope of names, file input/output, complex arithmetic, exception handling, etc.

I would like to ask your readers three questions:

Do YOU use these techniques in APL?

Do YOU want to see them standardised?

Are YOU prepared to work in this area?

If the answer to any of these is “Yes”, then you’ll want to participate in the future work of the BSI APL panel. We meet once a quarter, on average, and normally in the London area. There will also be opportunities for members to attend the international meetings of the ISO APL sub-committee.

Further information can be obtained from either of the following:

David Ziemann, BSI APL panel chairman, Cocking & Drury, 01-493 6172

Paul Barnetson, BSI APL panel secretary, IBM, 0705-323054

Yours sincerely,

Paul Barnetson,
Secretary, BSI APL panel,
IBM United Kingdom Ltd.,
P.O.Box 41,
Northern Road, Portsmouth,
Hampshire. PO6 3AU.

(Editor: I am sure we all wish you luck in attracting volunteers for this interesting and important challenge.)

Comparing Languages

Sir,

I have used APL for many years (mainframe) but had to leave it for a while. Coming back to it, I joined the B.A.A. several months ago, and back issues of VECTOR have been most helpful in highlighting recent developments. I enjoy my copies of VECTOR so please keep up the good work.

A book review is enclosed, for the “Handbook and Guide for Comparing Computer Languages”. You will see that I came across it by chance in a local library; Felicity at Mine of Information says it is not on their lists, and she hasn’t been able to find a U.K. supplier yet for me.

I was surprised to find, when talking to people at the Royal Over-Seas League last week, that no-one appeared to have heard of this book. Since I had already made detailed notes, it seemed sensible to make them more widely available to the VECTOR readers.

Yours sincerely,

Peter Branson,
[address omitted]

(Editor: Peter’s review is included in the reviews section later in this issue of VECTOR. Perhaps any reader knowing of a supply of the Handbook could let us know.)

I-APL

Sir,

Please find enclosed a donation towards the I-APL appeal. It’s pleasing to see something so positive and (hopefully) far-reaching being attempted.

My own feelings about the objectives of the I-APL project are rather mixed; partly because it seems that the project is concerned with making APL the new BASIC (although it can certainly live up to being a Beginner’s All-purpose Symbolic Instruction Code); and partly because I feel that a subset of plain old “vanilla” APL will have a hard time competing against full-scale implementations of Fortran, Pascal and some advanced BASICs which are already in wide use.

The area where APL really needs credibility is in the business arena because it is here that a language can grow in stature enough to be taken seriously elsewhere. For this reason, in parallel with the I-APL project, I think there should be a drive to develop powerful, cheap software written in APL to exploit the new icon-driven machines that are filling today’s computer market. Just imagine how popular APL might have been if, say, Lotus 1-2-3 had been written in it.

To this end I salute MicroAPL for taking the initiative and producing APL for the Macintosh, Atari ST and the Amiga, along with all-important run-time versions of the interpreter.

If software developers have got any sense, they will soon realise how easy it is to produce well-specified, full-featured software, quickly, easily and cheaply using APL. The I-APL publicity drive might well help towards this end.

Finally, may I say how much I enjoyed APL86 and how superbly VECTOR Vol 3, No 2 captured the excitement and sheer pleasure of that event.

Yours,

Simon Barker,
[address omitted]

(Editor: Your contribution to the I-APL project has been forwarded to the I-APL committee. Readers might like to note that I-APL is separate from the BAA and that I-APL matters should normally be addressed to the I-APL committee, specifically Anthony Camacho, David Ziemann or Norman Thomson – in the U.K.

Thank you for your comments on last VECTOR; we like to receive comments from readers – even unfavourable ones which give us useful feedback to improve your journal.)