[phantomics]

Since the video's quite long, here are some basics on April.

Repo: https://github.com/phantomics/april

April compiles APL to Common Lisp. It has almost all of the lexical functions and operators featured in Dyalog APL, the leading commercial APL interpreter and the most featureful APL implementation. It has many more features than the FOSS GNU APL, which is based on the old IBM APL2.

Dyalog APL's source code is about 500KLOC according to Dyalog's staff. GNU APL is over 100KLOC per its homepage. April's .lisp files currently stand at 6350LOC.

APL interpreters have traditionally been hard to connect to external data sources. Because APL is typically implemented as an interpreter, any connection to a database or other external system needs to be built into that interpreter as a plugin. April is called from within a Lisp program and you can pass it any array-formatted data. You can use CL libraries to read from any database or other source, format the data as an array and pass it to April for processing.

April takes some features from the k language, including ($[oneorzero;1;0]) if-statements and (g←{[a;b;c]a+b×c} ⋄ g[1;2;3]) n-argument functions.

April is extensible - you can easily create an extension to the language with more functions and operators, and you can also re-implement the utility functions that are used to parse and compile the language. The language is designed from the ground up to support extension. There is also a framework to extend the compiler to optimize common idioms, for instance ⊃⌽,200 200 200⍴⍳9 is optimized to just fetch the last row-major-ordered element of the big array instead of actually taking the time and memory to ravel and reverse it.

The second half of the video features a preview of a hardware startup called Bloxl that's powered by Common Lisp and April. Bloxl is a big transparent block wall with LEDs inside the light up to create pixel graphics. April was used to build the animations that run on Bloxl.

[kazinator]

> any connection to a database or other external system needs to be build into that interpreter as a plugin.

Guess: that could be the general area where Dyalog is burning most of its alleged, monstrous 500 KLOC.

[jonahx]

> Dyalog APL's source code is about 500KLOC according to Dyalog's staff. GNU APL is over 100KLOC per its homepage. April's .lisp files currently stand at 6350LOC.

What accounts for this discrepancy?

[mlochbaum]

A ways into the video it says the core Dyalog interpreter is about 100KLOC, with the rest being GUI code and interop such as file handling and formats, cross-platform support, .NET interop, and so on. If the 100k figure surprises you then what you are missing is just how deep array optimization is. For example, searching through an array will use an SSSE3 table lookup for 1-byte elements, a different table for 2-byte elements, and several different kinds of hash tables for other types. I tried to give a sense of the scale of this sort of thing in the first slide of my Dyalog '19 talk on Reductions (https://www.youtube.com/watch?v=TqmpSP8Knvg). You can write pages and pages of code and still there will be a way to speed up a common operation substantially.

By working on multidimensional arrays, APL expands the range of computations that are accessible to optimization. I think the writer of a scalar compiler like C would generally be happy making a single loop as fast as possible. APL immediately makes the implementer think about what happens if there are many axes (each of which is equivalent to a nested loop) even if the later axes (inner loops) are small.

[Avshalom]

-Common Lisp vs C/C++

-April implements the language and just punts to CL for all the I/O and system level stuff. Like it doesn't have to implement a REPL, or a line editor or APL workspace files/array stores.

[jonahx]

Thanks. I'm guessing (based on my knowledge of J and all its optimizations/special forms) that Dyalog APL would still be more performant too? I didn't see it mentioned on the GH README.

[phoe-krk]

Yes, the talk mentions that Dyalog is still much more performant, given how much time and effort has been spent on optimizing it.