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., 'domino' [matrix division]) saved as a single token, or as the three-character sequence quad,backspace,divide (or the reverse)?


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.

  • 2
    Man, I really miss the simplicity of APL for a variety of problems... – Jon Custer Mar 27 '20 at 16:31
  • 3
    @JonCuster - APL was great. You could do most undergraduate statistics problems with simple one liners. When I was at HMC in the 70's and living in Pitzer dorms I used to amaze Pitzer students by doing their homework that way. Didn't help get me a single date though. Still don't know why. – davidbak Mar 27 '20 at 17:52
  • 1
    @JonCuster - between APL for numeric calculations and SPITBOL for text handling - you could do nearly every ad hoc problem you came across ... – davidbak Mar 27 '20 at 17:59
  • 1
    @davidbak - indeed. I did various parts of my thesis in APL (Fortran for some serious heavy duty calculations). Learned SNOBOL and SPITBOL in an algorithms course. Good times. – Jon Custer Mar 27 '20 at 18:08
  • 2
    @davidbak Especially the setup for printing on the backside as well - they couldn't simply tun the page, so two pf thes garden shed sized printers were setup in 90 degree with the output of the first feeding the second after being tuned over a 45 degree shaft. Timing was critical - it even measured the stretching o paper to adjust printing speed. One customer has three of these combinations - each several times the value of the controlling mainframe setup. They did replace 40 high speed chain printers. Needless to say that it was a government agency. – Raffzahn Mar 27 '20 at 18:25

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).

  • 1
    APL came up with a similar scheme too if you were using certain kinds of impoverished systems. The APL-deriviative language J adopted the technique in full and never used a special character set. – davidbak Mar 27 '20 at 18:01

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.


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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.