How was the APL character set represented on IBM mainframes?

Question

The APL language used a unique set of characters, and additionally allowed overstriking of some characters on the terminal to form characters that were used in the language. When an APL workspace was saved, or a function with an overstrike was executed, were overstruck characters (e.g. ⌹, matrix division) saved as a single token, or as the three-character sequence quad, backspace, divide (or the reverse)?

Answer 1

It's important to keep in mind, that there weren't that much symbols using overstrike in basic (IBM) APL. By using an 8 bit codeset they all could be integrated. The most common charset on the mainframe side was Page 293 which extends EBCDIC with all (at that time) legal APL codes.

With APL2 code handling became more complicated and Page 293 was replaced by a combination of an arbitrary base Page (nowadays Page 037, the EBCDIC equivalent of ISO8859-1) used for text and a separate page for APL symbols, Page 310. Page 310 holds all original APL symbols at the same encoding as Page 293, but replaces the letter blocks with 'new' APL symbols as well as making the decimals superscript. Page 310 is, despite its alike organization, not an EBCDIC page, but a strict graphical supplement, not usable on it's own. Keeping the (APL1) codes at the same place simplified loading and conversion of older programs.

Answer 2

IBM had several different APL mainframe implementations, and they where updated and modified over many years to support different types of hardware and I/O equipment over their life time. The source for one of the earliest APL implementations for System/360 is available from the Computer History Museum. As far as I can remember they assign unique codes to the overstrike combinations when they are identified in the input buffer, before processing by the actual interpreter. One obvious reason for this is that you do not want the encoding to depending on the order of the overstruck characters. Another reason is that different terminal types provide the characters in different ways. Some types of 3270 (APL) terminals would let the user perform a kind of overstrike operation on the keyboard, but only store and transmit the composed character from its buffer.

Answer 3

I was once writing an APL compiler (never finished, having figured I could single-handedly write a compiler in a 10 week undergraduate programming project), and the choice I made was to have an internal 8-bit character set where each composite symbol was a single character. This seemed an obvious choice to me, since that way you're separated from how that symbol is represented on any particular external device.

The thing was supposed to be portable, but my development system was on ICL 1906A, with an impoverished 6-bit character set, and accessed through teletypes with a standard typehead. So my pro tem external representation used two-letter abbreviations preceded by dot. I might have picked .MD for the matrix-divide operator, for example. But only the lexical scanner needed to know about that. If I had ever had a better terminal, I would just write an alternative lexer.

I see your title explicitly asks about IBM implementations, but I think a description of alternative system might shed a little light. Fundamentally this feels like the same solution as the IBM one -- define the character set you need, and then translate to/from the devices you've actually got (which, if you have a fancy terminal that I did not, might be done by installing extra character sets in your fancy terminal).

Answer 4

This is a late answer but I hope that it might to some small extent be useful.

I've not delved into the original IBM APL to any extent other than to adapt my 2741 emulator to handle it, but have gone moderately deeply into other applications in particular derivatives of Ken Thompson's APL/11.

I can't remember whether the source of IBM APL was ever made available, my recollection was that after the Silverberg(?) brothers reconstituted it from tape nobody in IBM would authorise the release of anything other than a binary.

In the general case, I don't think an implementation saves an APL workspace etc. as the characters as entered, since this would mess up compatibility between different types of terminal (e.g. IBM printing terminals such as the 2741, and CRT-based terminals in the 3270 range).

I don't believe that an implementation saves a compound (overstruck) operation as a single character, since ultimately the number of potential compound operators comes close to exhausting the free codepoints in EBCDIC.

I don't believe that an implementation trivially tokenises. I think that in general what happens is that it reads the input into a buffer (where it can still be edited to some extent character-by-character), parses left-to-right (saving operations in numeric form, i.e. + becomes a single number, antilog becomes a single number and so on), and then evaluates right-to-left.

Finally, I agree that APL is great and can be spectacularly efficient... provided that one doesn't look too closely at storage requirements (there are plenty of stories of elegant APL programs sending a mainframe into a paroxysm of thrashing, and taking months to complete).