BQN, an APL descendant that starts from the ground up

What BQN provides now, and what it still plans to

The README draws an explicit line between what the project now provides and what it will provide, and the second list is short enough to be the most honest part of the page.

BQN now provides a simple, consistent and stable array programming language, with a stability document linked for that claim. It provides a low-dependency C implementation using bytecode compilation, with installation instructions in running.md. It provides system functions for math, files and I/O, including a C FFI. It provides documentation with examples, visuals, explanations and rationale for the features. And it provides libraries with interfaces for common file formats like JSON and CSV, hosted in a separate bqn-libs repository.

BQN will provide state of the art array performance, and the phrasing is careful: CBQN beats the fastest array languages much of the time, but not always. And it will provide a standard system to install and use libraries and packages, and support for package managers.

So the honest reading is that the language and the implementation are done and stable, while the packaging story and the performance story are both explicitly in progress.

The author's own framing of who it is for is worth quoting, because it is narrow and specific. BQN is a good choice for learning and enjoying array programming, scripting, prototyping, and number crunching at a single-CPU scale. That last qualifier is a real constraint rather than a hedge, since the whole design leans on tight array primitives and the implementation is a single-threaded C program with a bytecode virtual machine.

Two of the proofs of the implementation are in the repository itself. It holds the self-hosted compiler, src/c.bqn, and the friendlier markdown processor, md.bqn, used to generate the site. The other files in the tree, bqn.bqn, rt.bqn, vm.bqn, wc.bqn and svg.bqn, are more of the same: the language's own tooling written in the language. That is a meaningful statement about a language, and it is also a statement about how much you can verify by reading the repository.

The APL inheritance, and what was thrown away

BQN aims to remove irregular and burdensome aspects of the APL tradition and put the great ideas on a firmer footing, and it maintains many of the ideas that made APL 360 a landmark in 1966.

Three of those are the core. Human-friendly infix notation has no precedence rules to remember. Built-in array operations handle any number of dimensions easily, so there is no separate treatment of matrices. And higher-order functions allow basic functions to be applied in more powerful ways.

Then there are the concepts developed over years of APL practice. The leading axis model means simpler primitives span the same functionality, so a primitive that works on rows of a matrix works the same way on a table with more dimensions. Trains and combinators enable tacit programming, which is the APL tradition of writing a function without naming arguments, and it borrows the idea of a function as a value. Lightweight anonymous functions, like dfns in the APL wiki, borrow some power from Lisp.

And then the redesign, which the README says is from the ground up with many features new to the array paradigm.

The based array model eliminates the surprise of floating arrays and the hassle of explicit boxes, which are the two most famous complaints about APL. Dedicated array notation does away with the gotchas of stranding, the APL convention where a list of adjacent values could be read as a strided array rather than a list. The context-free grammar makes it easier for machines and humans to understand code, and naturally leads to first-class functions, which can even be used to reinvent control structures. New symbols for built-in functionality make the syntactic role of every primitive instantly visible. And no-nonsense namespace syntax encapsulates data and even allows for a little object-oriented programming.

The new symbols are worth a moment, because they are the most immediately visible difference to someone arriving from APL. BQN assigns each primitive a distinct character so that the role of a symbol is legible at a glance, which is the kind of change that sounds cosmetic and turns out not to be.

The character set is the first obstacle, and the README has the fix

Any APL-like language faces the same first problem: you cannot type the code. BQN's answer is documented in detail, and the documentation is the first thing you should read if you are evaluating it.

Right at the beginning, in the online REPL, you can use the bar above the editor to enter BQN code, and hovering over a character shows a short description, with a click to insert it. That solves the problem for a demo, and the README is clear that you will soon want to skip the clicking.

The author's own method is a backslash escape. Typing a backslash and then z writes the character ⥊, for example, and the backslash character itself is not used by BQN. The online REPL supports this method out of the box, and the editor plugins include or link to ways of enabling it for editors, browsers and shells.

The font issue is the other half, and it is more consequential than it sounds. The font comparison page shows several fonts that support BQN, including BQN386 which is used on the site. Most other monospace fonts are missing some BQN characters, such as the double-struck letters, and those characters will be rendered with a fallback font and may have the wrong width or look inconsistent. The double-struck characters also require two bytes in UTF-16, which breaks rendering in some Windows terminals. Windows Terminal itself fixed this in 2023, and VS Code and wsl-terminal also support them with an appropriate font.

That last detail is the kind of thing that determines whether a language is pleasant to use on a given machine. A language whose glyphs fall back to a proportional font is a different experience from one that renders cleanly, and the difference is entirely in the font you install.

The repository has a fonts/ directory and an editors/ directory, and a keymap.md at the top level that documents the new symbols.

Trying it, and the specification as the reference

The README is unusually practical about how to get a first look. You can view the file with a real REPL linked from the top of the README, and there is a try.html page, and the author has a chat forum.

For offline use the README points at CBQN, with details in running.md. The implementation directory in the repository has the implementation README, and the C source is in src/.

The documentation structure is one of the better ones you will find in a language repository, because it separates the layers. The doc/ directory holds the reference documentation, with separate files for the primitives and their modifiers, the leading axis model, the based array model and array representation, the context-free grammar, the functional and control structure material, the namespace syntax, the object-oriented programming material, the trains, the tacit programming material, the block and anonymous function material, and the FFI. The spec/ directory holds the specification, which is a separate artifact from the documentation, and the tutorial/ directory is the tutorial. The commentary/ directory holds the author's essays, including the why BQN outline the README points to for what the features add up to in terms of programming power, and the stability document.

That separation between specification and documentation is a real quality signal. A specification is a contract that an implementation can be checked against, and the presence of one means the language has a definition rather than only a description of what the reference implementation happens to do.

The community pages cover the forums, and the README points at a Discord server and Matrix rooms, with the note that they are bridged together so that a message in one appears in the other. It says most discussion happens on these and that they are quite active, and it also points at awesome BQN repositories and examples on RosettaCode for further reading.

The examples/ directory in the repository holds fifty.bqn, and the test/ directory holds the test suite, and there is a docs/ directory alongside doc/ for the generated site.

Editorial conclusion

BQN suits someone who wants to learn array programming properly rather than by accretion, since the language keeps the APL ideas that work and redesigns the parts that did not, and it suits anyone who wants an unusual language with a real implementation and a real specification. It is the wrong choice if you need a large package ecosystem, because the README lists a standard system to install and use libraries and package manager support under what BQN will provide rather than what it now provides. Before evaluating it, read the why BQN commentary, since the README points there for what the features add up to, and try the online REPL in the browser before installing anything, because the character set is the first real obstacle to writing any code at all.

Frequently asked questions

Official sources

1. Issues
2. License: ISC
3. mlochbaum/BQN on GitHub
4. Project website
5. README