One of the defining features of the APL language is the ability to denote numeric vectors directly through juxtaposition — separating the elements by spaces, as in 0 1 1 2 3 5 8. The notation for character “vectors” is similar to that for “strings” in most other languages, using quotes to denote the start and end of a list of characters. When generalised arrays were added to the language in the early 1980s, the most popular APL dialects extended the vector notation to allow nested arrays to be written using so-called strand notation, allowing the juxtaposition of sub‑expressions producing arrays to form a one-dimensional array — as in:

      (2+2) (FOO 42) MAT

Strand notation works well for small, relatively simple one-dimensional arrays. As soon as arrays are too large to be represented on a single line of code, deeply nested, rank greater than one, or (in APL systems that support them) contain namespaces or objects, APL requires the use of primitives or system functions to assemble them from simple components.

The flexibility of the APL language has allowed many APL programmers to work around the issue, either by implementing custom array notations or by using the ability of most APL interpreters to simply store arrays within saved workspaces without having an actual source form of the data. Within specific applications, domain specific notations can be very successful, but readability is poor for anyone not trained in the specific variation used — or who is missing the tooling required to interpret them — as well as sometimes having significant run-time cost.

Recently, the need for a better notation for arrays has grown within the Dyalog APL community:

• The switch to text-based sources means that arrays that represent constants, enumerations or initial values — that arguably constitute part of the source of an application — need a textual representation if they are to be managed using the same tools as functions and operators.
• The increased use of namespaces and name/value pairs as arguments to both user-defined and system functions makes the lack of a good notation for namespaces painful.

Dyalog Ltd intends to implement core language support for a notation that makes it possible to write most arrays literally, without requiring the use of primitive functions, over multiple lines of source where this increases readability. It can be used to write nested arrays, and arrays of rank greater than one. The notation also describes many namespaces/objects, providing both inline and anonymous definitions.

Acknowledgements

Although I used the word “recently” above, the foundations for the notation which gradually evolved into the proposal that we are publishing today were laid by Phil Last at Dyalog’15 in Sicily. At Dyalog, Adam Brudzewsky has been the torch bearer and is the author of the current proposal. We would also like to recognise the contributions of Marshall Lochbaum and dzaima, who have acted as sounding boards and have implemented notations similar to that proposed here in the APL-derivative BQN and in dzaima/APL respectively.

Download the full proposal document

Experimentation within Dyalog APL

Experimental implementations using APL models are available within some tools in the Dyalog eco-system, such as the Link tool (which supports the representation of code and data in Unicode text files) and the functions Serialise and Deserialise within the namespace ⎕SE.Dyalog.Array. You can also try it out in the interactive online sandbox.

Providing feedback

Dyalog Ltd is keen to have feedback from the array language community on the notation proposed here, so that we can feel confident about the design before we proceed with our implementation. Our hope is that we will be able to keep the differences between future array notations within the family of array languages to a minimum.

You can leave feedback below or in the APL Orchard chatroom, the APL Farm’s #apl channel, the r/apl and r/apljk subreddits, and the comp.lang.apl newsgroup, all of which we will monitor. (See APL Wiki for information about these forums.) In addition, we have created a topic in our own forum. If you prefer not to comment publicly, then please send comments by e-mail. We will update the discussion page for APL Wiki’s Array notation design considerations article to contain a record of significant feedback.

Follow