Unicode

The advent of Unicode solved many problems with dealing with APL characters, however there was still some wiggle room as to which Unicode codepoint were to be used in a Unicode implementation of APL, and different implementors made different choices. This article, which documents these differences, is adapted from an original paper by Bob Smith that attempted to raise awareness of these issues because the differences impede transfer of information.

The relevant document for the APL character set is the APL Character Repertoire (ACR). For whatever reasons, that document never became a standard, but it does provide some guidance, and is better than each implementor making separate choices.

Introduction
There are a surprising number of similar APL characters in Unicode and in several cases some implementors went one way, others the other way. The following table lists the characters in question, along with the way APL2, Dyalog, GNU APL, NARS2000, ngn/apl, and dzaima/APL behave. APL2000 states that Generally the default codepoint scheme for the VisualAPL product follows the IBM APL2 workstation scheme. Please edit the table if you believe there are other characters that should be included in the table, or to add another dialect.

When there are differences among APL implementations, users can become confused. They type something into one APL system, copy it to another and are greeted by a SYNTAX ERROR or the like.

The whole basis for the confusion in a lengthy thread on comp.lang.apl entitled caret vs and was that in some implementations the symbol for the logical And function was U+005E only, in some implementations it was U+2227 only, and in some both characters worked. The original poster encountered some APL text from the APL Wiki that had been produced by a system that supports U+005E and copied it into a system that used U+2227 only and failed on U+005E.

When systems differ in the set of acceptable characters for the same function, it serves only to confuse the end user to the detriment of the community. The cautious APL programmer can avoid such problems by choosing symbols that work across dialects. Note that in the below table, there is exactly one universally accepted codepoint for each symbol (these have been indicated by a single "Universal" cell stretching across the row), except for And where APL2 doesn't recognise the otherwise universal U+2227. However, APL2 does not have And extended to Least Common Multiple, so it is equivalent to Times which can therefore be used instead for truly portable code.

Comparison of implementations
The following characters are included have been encountered in APL code displayed somewhere on the Internet or in a PDF file. Blindly copying them into an APL session can produce an error which might well confuse the user.

Functionality
The following statements can be used to test the functionality of the symbols: Note that the last four lines will not work on a system that doesn’t support dfns.

Atomic Vector
If the Atomic vector has no room in which to include these new characters, an implementation can translate them on entry to the corresponding symbol that is in. NARS2000 even has a means of translating symbols on the way out via Copy ( Ctrl + C in Windows) to various other APL systems that don't support the same set of principal characters NARS2000 uses for the functions in the above table.

Considerations
Unicode was a great start to enabling APL characters to be used, however in order for there to be interoperability, implementors have to agree upon which characters are functional. It doesn't matter if one's system can change the mapping of glyphs to codepoints as the vast majority of users won't change from the default behavior. Implementors therefore have to decide if it is worthwhile to support the above codepoints.