April compiles a subset of APL into Common Lisp, and the demo function is the best way in

APL array primitives compiled down to Lisp forms

April compiles a subset of the APL programming language into Common Lisp. The stated idea is that APL has always been numerically expressive but sealed away inside monolithic runtime environments, and that Lisp is the great connector of the software world, digesting and transforming semantic patterns much the way APL works on numeric patterns.

Put differently, April is not an APL interpreter bolted onto a Lisp process. It is a compiler that turns APL source into Common Lisp code, using Lisp's macros and numeric processing faculties. The claimed payoff is the one every APL user eventually asks for: replacing hundreds of lines of number-crunching code with a single line of APL, while staying inside the Lisp ecosystem where databases, streams and binary files are just a few lines of code away from array processing.

The argument for a subset is worth taking seriously rather than reading as a caveat. The project lists which APL functions and operators will not be added because they do not make sense for April's design as a compiler from APL to Lisp, with a separate list of what is not planned for implementation. Deciding in advance that some primitives will never exist is a design position, and it means the language you are learning is the language you will have.

The primary language of the repository is Common Lisp, and the licence is Apache-2.0.

Two entry points, april and april-f, and what the difference buys you

Evaluating an APL expression is straightforward once the reader function is loaded. The simplest form evaluates a string and returns a Lisp value:

* (april-f "1+2 3 4")
3 4 5
#(3 4 5)

The output is worth reading carefully. APL's arithmetic on arrays is vectorised, so 1+2 3 4 applies addition elementwise across the three numbers, and the result comes back as a Lisp vector, printed in the #(...) notation. The `*` in the example is the REPL prompt, not part of the code.

There are two entry points, april and april-f, and the project documents both under the heading of basic evaluation. The distinction, in broad terms, is that one path compiles and evaluates APL code while the other does so with a more functional, expression-oriented shape. Both take APL text and both give you results you can keep working with in Lisp, and the practical difference is in how you compose them in a larger program.

The compiler has a deferred evaluation story as well, which was the subject of a PLDI 2023 presentation on April's deferred evaluation features. That is one of the more interesting properties of an APL in Lisp: because APL is array oriented and the compiler works on Lisp forms, the project can defer evaluation in ways a traditional APL interpreter does not.

The repository layout backs the compiler claim up. There is a grammar.lisp file, a spec.lisp file, functions.lisp, novelties.lisp, utilities.lisp and package.lisp at the top level, alongside directories named aplesque, aprepl, cape, varray and vex. The grammar and spec files are the compiler's front end, and the separate directories are the pieces that make APL behave like Lisp code once compiled.

Installing through Quicklisp, and the manual path with a symbolic link

April is supplied by the Quicklisp library manager, and the easiest installation route is through it. In a Common Lisp REPL you evaluate:

(ql:quickload 'april)

That single call downloads and installs April's dependencies, and the package is then built and ready.

The manual route exists for people who want the repository version rather than the Quicklisp release. You clone the repository to a location on your system, and the example used by the project is a directory called ~/mystuff/april. Then you enter your Quicklisp local-projects directory, usually ~/quicklisp/local-projects, and create a symbolic link to the cloned directory:

cd ~/quicklisp/local-projects
ln -s ~/mystuff/april

After that you start a Common Lisp REPL and evaluate (ql:quickload 'april) again, which pulls in the dependencies and builds the package.

The symbolic link arrangement is the standard Quicklisp local-projects pattern, and it means your working copy is what gets loaded, which is what you want when you are reading the compiler source alongside running it.

Two details deserve attention. First, April is a Lisp system with an asd file, april.asd, so it is built by ASDF like any other system, and a source checkout means you are compiling a compiler at load time. Second, the difference between the Quicklisp version and your checkout is the usual one: the release is what other people have run, the checkout is what you have changed.

Seven Lisp implementations, and two with known compatibility gaps

April puts the numeric and array processing capabilities of Common Lisp to the test, and the project publishes the results per implementation.

It has been verified to work with SBCL, CCL, ECL, ABCL, Clasp, Allegro CL and LispWorks. SBCL and CCL are considered fully compatible, with no special provisions made in order to function. ECL and Clasp pass all tests with the help of some specific provisions addressing their differences from other CL implementations. ABCL passes all main tests with the help of some specific provisions, and all the dfn tests except those in the tree library, which cannot be loaded due to limitations of the underlying Java virtual machine.

Then there are the two with problems. Allegro CL and LispWorks both have a few compatibility issues causing failures of dfn tests, and the project links a document listing all differences in functionality between implementations, in compatibility-notes.md at the top of the repository.

That table is the single most useful piece of the project text for an adopter, and it deserves to be read before anything else. If you develop on SBCL and deploy on Allegro CL, the compatibility notes are the difference between a smooth rollout and a debugging session, and the failures are in the dfn tests, which is where the language semantics are exercised hardest.

The ABCL row is also worth understanding rather than skipping. The failures are not in April's logic but in the Java virtual machine underneath, and a language implementation that leans on the host's numeric behaviour will always have some edges like that.

The demo function prints what the compiler actually supports

Learning APL is the barrier to using April, and the project addresses it directly with a runnable tour.

If you would like a quick tour of the language, April includes a function that will print demos of all the commands and many APL syntax features. You enter:

* (april (demo))

The project warns you to prepare for a long read. The demo content tells you the name or names of the operations that correspond to each symbol, and gives you some idea of what each one does. Since APL uses single characters to represent its primitive functions and operators, and most of those symbols are not part of the standard ASCII character set, the demo doubles as a printable reference for the glyph set.

That last point is the practical reason to run it. The project points to a lexicon document listing the complete APL lexicon April supports, and to a separate list of features not implemented. Between the demo, the lexicon, and the unimplemented list you have a precise map of the language, generated from the compiler rather than written by hand, which is more reliable than either.

For learning the language itself rather than April, the project links out to a high level introduction hosted on the Vector site, a detailed language tutorial covering most of the functions and operators in April, and Ken Iverson's original paper detailing the language's underlying philosophy. So the reading path is: read the original paper for why APL exists, use the microAPL tutorial for the details, then use the demo output to confirm what this particular compiler supports.

APL glyph input is an editor problem before it is a compiler problem

There is a practical obstacle before any APL code runs. In order to write APL programs you need a way to use the language's special character set, and the project links to three separate guides for that.

One is for enabling APL input within Emacs, one for enabling APL input within Vim, and the third is for enabling APL input universally within GNU/Linux, which is the route that matters if you are not in a single editor. On Linux this usually means a compose key or an input method for the glyphs, since the symbols are outside ASCII.

This is worth taking seriously when planning an adoption. The APL character set is not decorative, it is the syntax, and an editor that cannot type it is a hard blocker for a team whose people are used to a normal keyboard layout. Since the project links editor specific instructions for the two most common Lisp-adjacent editors, it is clearly a problem the author hit and solved, but you will still need to configure it per machine.

A related point: the APL language uses single characters for primitives, so any tooling around your code, from review to diffing, has to handle glyphs as well. That is a workflow cost that does not appear in the language's own project text but shows up on day one.

Maintenance pace, release age, and where discussion happens

The maintenance picture is mixed and you should read both halves.

The last push to the repository was on 2026-05-29, which is inside the last six months, so there has been recent work. The tagged releases are much older though: v1.0, labelled April 1.0, from 2022-02-03, preceded by v0.9.55, labelled April Beta Revision 1, from 2019-02-02, and v0.9.5, labelled April Initial Beta, from 2019-01-12.

So the honest description is a project with commits after its last release tag. If you install through Quicklisp you are likely getting the 1.0 release from 2022; if you clone the repository you are getting something newer and unreleased. That difference matters for a compiler, because a change in the grammar or in how a primitive compiles is exactly the kind of change that a version number is supposed to signal.

Discussion happens on the ##phantomics channel on irc.libera.chat, for the time being. That is where design decisions and questions about the implementation go, and it is also where you would raise a bug if you were not using the tracker.

The project is funded through Patreon, and the project describes April as making fast and steady progress toward being a full-featured and professional APL implementation. The publication record backs the serious intent: a PLDI 2023 paper on deferred evaluation, a European Lisp Symposium 2022 paper titled April: APL Compiling to Common Lisp, an APL Seeds '22 presentation at Dyalog's conference, a LispNYC presentation, and an ArrayCast developer interview. Whatever the release cadence, the design work has been through peer review and conference scrutiny.

Editorial conclusion

April fits a Common Lisp developer who has a data processing problem that APL's array primitives solve better than hand written loops, and who wants to keep that code inside a Lisp application rather than shelling out to a separate APL runtime. It does not fit someone who needs the whole APL language, since the unimplemented list is published with the project, nor someone on Allegro CL or LispWorks where compatibility gaps cause test failures. Before adopting it, read the compatibility notes for your implementation and run (april (demo)) once, because the printed demo tells you which symbols the compiler actually accepts.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. phantomics/april on GitHub
4. README
5. Releases