Wyvern: a research language built around capability-safe modules

The stated goal is assurance, not productivity

Wyvern is described as a new general-purpose programming language designed to support adaptation and assurance, and the pair of words in that sentence is the whole project. Adaptation is the idea that software should be able to change shape without breaking the guarantees around it, and assurance is the idea that the guarantees should be checkable rather than assumed. That framing comes from the research origin of the project rather than from a product roadmap, and the README says so by pointing at the manifesto first, with the note that the best starting point for understanding Wyvern is the Wyvern manifesto, Wyvern: A Language for Usable Design-Driven Assurance. The key features listed are a simple object model with good support for both object-oriented and functional programming, static type safety, extensibility with domain-specific syntax via libraries written within the language, a simple but powerful capability-safe module system, and support for various aspects of software architecture within the running system. Read together, those are the ingredients of a language designed to make architectural constraints part of the type system rather than a matter of team discipline, which is what the capability system does and why it is the feature the rest of the design serves.

The rest of this article looks at what is in the repository, how the language is taught through its examples, where the documentation lives, what the capability system changes, and where the project is a poor fit for production work.

What the repository actually contains

The top level of the repository reads like a compiler rather than an application, and the directory names tell you how the implementation is split. There is a frontend/ and a backend/, which in a language implementation usually means the type checker and the evaluator, a jsgen/ directory for JavaScript generation, a native/ directory for the native back end, a stdlib/ for the standard library, a bin/ directory for the executables, a tools/ directory for the supporting tools, a selfhost/ directory, a docs/ directory, a releases/ directory and an examples/ directory. The primary language of the repository is Java, which fits a design that was built to be readable and to be studied, and it also fits a language project whose artefacts are expected to include a running system rather than only a compiler. The distribution is GPLv2, with the licence file named COPYING.TXT, which is the older and more restrictive of the two GNU licences. There is no homepage project page beyond wyvernlang.github.io, no release history, and the repository has no GitHub releases, so the version of the language you get is whatever the master branch happens to contain.

The examples directory is the curriculum

The examples directory is where the language is actually taught, and its layout is the most informative thing in the repository. There are introductory/ and a pong/ directory, which is the traditional first program, a REPLexmple/ directory, and directories for each language feature area: capabilities/, modules/, effects/, dataTypes/, dataStructures/, ffi/, architecture/, an io-lib/ directory alongside an io-lib-redesign/, a multiLambda.wyv example, an optionType.wyv example, an AlexTalkDemos/ directory, and directories for bugs/, obsolete/ and onward20/. The individual .wyv files include asciiToText.wyv, commandLineArguments.wyv, dirTest.wyv and llist2.wyv, so the examples are short, single-purpose programs rather than a large application, which is what makes them readable as a specification of the language. The fact that there is an obsolete/ directory and a bugs/ directory is itself a signal about the state of the project, since both are where a working implementation accumulates the history of what it got wrong. The presence of an io-lib-redesign/ next to an io-lib/ suggests the standard library's input and output layer was being reworked, and a demo-ideas.txt file suggests the language's designers were still collecting candidate programs to write in it.

Three documents, and no install command in the README

There is no build or install command in the README, and that is not an omission so much as a pointer. The README says that for information about how to build and run the Wyvern tools, and about the Wyvern tools architecture, you should see a tool architecture document hosted in the separate docs repository, at a raw GitHub URL ending in wyvern-tool-architecture.mdk. It also points to a language guide PDF in that same docs repository for an introduction to the key concepts of the language, and the contribution instructions confirm the workflow by telling you to read that tool architecture document to get the system to build on your machine before you do anything else. The build system itself is Travis CI, with a .travis.yml at the top of the tree, and there is a .vscode/ directory, which suggests the language has editor support configured for VS Code. If you want to see the design reasoning rather than the code, the README points to the manifesto in the project wiki and to the Wyvern web page for research papers and related reading. The contribution process is unusually specific for a research project: find an issue marked Starter, comment that you are working on it, and then submit a pull request, with questions directed to a named academic address.

Why a capability system is the interesting part

The capability-safe module system is the feature that distinguishes Wyvern from a general-purpose language with nice syntax, and it is worth understanding what the README claims about it even without the manifesto. In a capability system, authority is not granted to a whole program or a whole user but is attached to specific references, so a component that holds a reference to a resource can use exactly that resource and nothing else, and the permission structure travels with the values rather than with the code. That is the mechanism by which a program can be given a limited view of the filesystem, the network or the database without the operating system having to trust it. The examples directory has a capabilities/ directory, which suggests the language is where the interesting demonstrations live, and the modules/ directory and a capabilities/ directory together point at a design where the module system and the capability system are the same story rather than two separate features. The static type safety claim then does more work than it would in an ordinary language, because with capabilities the type of a reference carries what it is allowed to do, and a mismatch is a type error rather than a runtime refusal. The design-driven assurance phrase in the manifesto title is the summary of that idea, since the architecture is expressed in types and the compiler checks it.

Where Wyvern is the wrong choice

The first limit is the most obvious one, that this is research software with no releases and no stable interface, so if you adopt it you are adopting a moving target on the master branch of a research repository, and there is no upgrade path to manage because there is no version to upgrade from. The second is the toolchain burden, since the README routes you to a separate repository for the build instructions, the language guide is a PDF rather than browsable documentation, and the architecture of the tools is described in a document with an unusual .mdk extension. A language you cannot install in one command from a single README is a language for people who will read the papers first. The third is ecosystem, and it is decisive for anyone hoping to use the language rather than study it, because there is no package index, no library ecosystem beyond the bundled standard library, and the domain-specific syntax feature works by writing libraries in the language itself, which is powerful precisely because it assumes you will. The fourth is that the implementation is in Java, so a project wanting to embed Wyvern in a Java system has an easier path than one wanting to use it from Python or Rust, and a project with no Java anywhere in its stack is starting from behind. The honest summary is that Wyvern is a serious attempt at a language where architectural constraints are checked by the compiler, published as a research artifact, and its value is as a design to study and a teaching vehicle rather than as a tool to deploy.

Editorial conclusion

Adopt Wyvern only if you are doing language research or teaching, or you specifically want to study a capability-based module system in a statically typed language with no runtime privileges. Skip it if you need a language to build production systems with, since there are no releases, the toolchain is documented across three separate documents, and the language is still described as new and evolving. Verify first which interpreter and tools you need and how to build them from the tool architecture document, and that the examples directory covers the language features you intend to study.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Project website
4. README
5. wyvernlang/wyvern on GitHub