Co-dfns compiles a parallel, deterministic extension of the dfns dialect of APL

A compiler for a dialect of APL, not another APL interpreter

Co-dfns is described as a high-performance, high-reliability compiler for a parallel extension of the Dyalog dfns programming language. That single sentence contains most of the scope. The dfns language is a functionally oriented, lexically scoped dialect of APL, so the input is not plain APL but a specific restricted and modernised subset, and the output is a compiled program rather than an interpreted expression stream. The stated mission is to deliver scalable APL programming to information and domain experts across many fields, expanding the scope and capabilities of what you can effectively accomplish with APL. The audience is therefore narrow and identifiable: people who already write APL in the dfns style, typically with a background in mathematics or a quantitative domain, and who have hit the point where array expressions alone are not enough. For anyone arriving from a mainstream language, the compiler matters less than the language, and the project says so by pointing new users to its documentation folder, installation guide and FAQ before anything else.

dfns is lexically scoped and functionally oriented

The base language choice shapes everything downstream, so it is worth being precise about what dfns is and is not. It is a dialect of APL, which means array expressions and rank operations are available, but it is functionally oriented and lexically scoped, which changes how a program is organised compared with traditional APL where a function is defined with headers and control flow is expressed with branch and go-to style primitives. The dfns model gives you nested functions with local scope, and Co-dfns inherits that model rather than bolting parallelism onto the old style. That choice has consequences for adoption. Code written for dfns cannot be assumed to drop into a Co-dfns project, and code written for Co-dfns will not run in a plain APL environment without the parallel constructs being removed. The compiler source tree reinforces that this is a language implementation rather than a tool wrapper: the repository holds directories named cmp, rtm, ime and ws, alongside tests, tests_old, attic and docs, which is the layout of a full front end, backend and runtime.

Explicit task parallelism with implicit synchronization

The central language extension is explicit task parallelism with implicit structures for synchronization and determinism. Those two words carry most of the technical weight. Explicit task parallelism means the programmer states that independent work happens concurrently, rather than leaving a runtime to guess which expressions are safe to run together. Implicit synchronization means the compiler inserts the coordination points itself, so the programmer does not hand-write barriers or locks. Determinism means the result of a parallel program does not depend on the order in which the tasks happen to finish, which is what makes the approach usable for programs whose output must be reproducible. This combination is the answer to the classic complaint about parallel array languages, where a correct program becomes hard to reason about because correctness depends on timing. A design in which concurrency is declared but ordering is enforced by construction trades a small amount of expressiveness for programs that can still be formally checked. The language is designed to enable rigorous formal analysis of programs to aid in compiler optimization and programmer productivity, as well as in the general reliability of the code itself.

Formal analysis is a design goal, not a documentation topic

Most language projects treat formal analysis as something a separate tool does later. Here it is stated as a goal of the language design itself, which changes where the complexity sits. If synchronization and determinism are implicit, then a static analyser can reason about a program's parallel behaviour without reconstructing a thread schedule, and the compiler can use the same analysis to justify optimizations that would otherwise look unsafe. The public record shows this is a serious research direction rather than a slogan. The project links a static analysis talk on APL tooling and compliance from DYNA in autumn 2025, an arXiv paper comparing parallel functional array languages on programming and performance, and earlier work on a data parallel compiler hosted on the GPU. A visitor who wants the substance should look at those publications and at the compiler architecture write-up rather than at the README, which is largely a signpost to documentation, installation notes and talks. The practical consequence for an adopter is that a formal method that works on sequential dfns may need rechecking against the parallel extension's rules.

Getting started means reading the installation guide first

There is no short install recipe in the project's own overview, and that is a deliberate choice rather than an omission. The stated guidance is to make sure to read the installation guide, docs/INSTALL.md, carefully to get a clear picture of how to get the compiler installed and avoid common pitfalls, and there is also a FAQ in docs/FAQ.md covering some of the most common questions. So expect to spend real time in the documentation before you have a working toolchain, and treat the FAQ as part of the install path rather than an afterthought. General documentation on Co-dfns lives in the docs/ folder, and the project acknowledges that APL and Co-dfns can look different at first: the author invites questions about either language by email and points people with general Dyalog APL questions to Dyalog's own support channel. The message to a prospective user is clear. Bring your APL experience, but plan on reading rather than guessing, because the documentation exists precisely because the setup has sharp edges.

Contributions need a pull request, a dual licence and a copyright transfer

The contribution policy is unusually explicit about legal terms, which matters for anyone planning to send code. The project is dual licensed, and any contributions must use the same dual licensing model to be accepted. A copyright transfer is also required to enable the team to work effectively with the codebase from a legal standpoint, and a pull request is treated as an acknowledgement and acceptance of those terms. The repository is licensed AGPL-3.0, with LICENSE.txt and COPYING.txt at the top level, so a derived compiler carries copyleft obligations that many commercial organisations will need to review before they can use the output. On process, the internal team primarily works old school via email and patches, and diffs sent by email are welcome, but the most visible credit comes from submitting a pull request against the master branch. Using a pull request is optional and exists mainly for credit and easier attribution. Funding is also part of the model: the project is seeking an open funding model through user and patron contributions, and directs supporters to the author's Patreon page.

A compiler in active use, with a research agenda and two derived projects

The maintenance picture is healthy in the narrow sense that matters for adoption. The last push to the repository was on 2026-10-09, and the release list shows v4.1.4 on 2025-10-03 alongside v5.7.1 on 2024-07-16 and v5.7.0 on 2024-07-10. That sequence is worth reading carefully rather than as a version history, because the v4 tag is dated after the v5 tags, which means the tags do not follow a simple monotonic scheme and you should pin to a specific tag rather than assume the newest number is the newest code. Two sibling projects are built on the same technology and show what the compiler is for in practice: Mystika, described as a high-level, high-performance cryptographic stack, and apixlib, described as programmable, easy to use image processing. The published record includes a talk on a U-Net convolutional neural network in APL, exploring zero framework and zero library machine learning, If you are evaluating the compiler for numeric or tensor work, those talks are the closest thing to a worked example, since the README itself stays at the level of project identity.

Editorial conclusion

Co-dfns suits APL specialists who already write dfns and need a compiler that adds explicit task parallelism while keeping programs deterministic, plus the static analysis that formal methods work requires. It does not suit teams looking for a general purpose parallel language, and it should not be adopted without reading docs/INSTALL.md, because the project states that installation has common pitfalls. Verify first that your dfns code fits the parallel extension's model of implicit synchronization, that you are comfortable with the AGPL-3.0 terms and the copyright transfer that contributions require, and that the version you pick from the release list matches the documentation you read.

Frequently asked questions

Official sources

1. Co-dfns/Co-dfns on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases