The goal of performing actions statically to save runtime has for decades been at the core of systems programming. Since the accidental discovery of C++ templates as a means for compile-time programming in 1994, the C++ community has been manufacturing incredibly complicated machinery for that purpose, which is collectively referred to as C++ Template Metaprogramming (C++TMP). From Xlang’s point of view, a major contributor to that complication is the inherent inegalitarianism between type-level and value-level C++. Xlang avoids that effort and complexity by treating types as values. This idea is well-versed in dependently-typed languages, e.g., Agda or Idris. Xlang takes inspiration from Idris whilst remaining an efficient systems programming language.

For decades, dependency injection (DI) has been a hot topic in both the theory and the practice of software development. Different languages offer different DI mechanisms. The Xlang unbounds are an efficient and fine-grained DI mechanism with a similar syntax to the ML abstract members (of ML signatures). unbounds are static, entailing negligible runtime overhead. unbound resolution takes place statically and with no late-binding. They are also fine-grained in that they can be used to inject dependencies that are finer-grained than an entire class. The implementation of an unbound can be as lightweight as a hidden argument to calls or as a part of the call contexts.

The Xlang unbounds are like the C++ template parameters but offer more opportunities for code-reuse. Without type arguments, a C++ template is not still a type. But, an Xlang struct (or trait) containing an unbound is already a type, regardless of whether a binding is available for the unbound. As a consequence, given a struct (or trait) that contains an unbound, the code that makes use of that struct (or trait) will need no update when the binding of the unbound is manipulated. unbounds can be bound in any scope (once per scope) – hence, offering finer granularity. unbounds do not impose any runtime or space cost to the instances of their enclosing struct (or those of the impls of their enclosing trait).

Reducing the runtime has always been the holy grail of systems programming. One way to win the holy grail is to move as much of the runtime actions into the compile-time as possible. Xlang takes it beyond compile-time vs runtime by offering a new opportunity for multi-stage programming. The precompute-time is a preamble to runtime, in which parts of the code are executed. Those parts are called precomputable. Executing the precomputable parts might not be possible at compile-time because of the unavailability of the relevant information at that stage. Conceptually, the output of the precompute-time is a new executable, in which the precomputable parts are JITted.

Precomputation can be enforced manually using the known keyword. However, precomputation is mostly performed automatically by the Xlang build toolchain. That is, at precompute-time, in addition to those expressions marked known by the Xlang programmer, the build toolchain analyzes dependencies to identify precomputable expressions and components. The language also provides programmer guarantees as to what will be precomputed even without known decoration based on dependencies, thus providing both fine-grained mata-programming control and the ability for the same code to be reused at both precompute and runtime.

Two major problems with C++TMP or the Scala metaprogramming is that they are almost another language when compared to C++ or Scala and that they require understanding of the splicing semantics. C++TMP takes that to the extreme such that a compile-time regexp library takes an outstandingly genius design that a very small fraction of the C++ programmers can understand. The Xlang precomputability is, on the contrary, accessible to the everyday programmer.