Typelang: Modular DSL for Type Systems

• Typelang is a family of domain-specific languages designed for modular, reusable type system implementations in language workbenches.
• It decouples type system definitions from technological platforms, automating LSP plugin generation to minimize duplicated efforts.
• Leveraging variant-oriented programming and feature boxes, Typelang achieves significant code reduction and scalable editor support.

Typelang refers to a family of domain-specific languages (DSLs) designed to facilitate modular, composable, and reusable type system implementation in language workbenches. It is specifically architected to address complexity and duplication in developing editing support and type system infrastructure for multiple programming languages and editor environments. Typelang decouples type system definitions from technological platforms and supports per-artifact type system specification, streamlining the generation of language servers and editor plugins via integrated automation workflows. Its approach draws on variant-oriented programming and cross-artifact coordination to manage interdependencies and maximize reuse across language families (Bruzzone et al., 18 Sep 2025).

1. Typelang DSLs and Type System Modularity

Typelang is characterized by a family of DSLs that enable both type checking and type inference, with constructs for explicit type definition, scope management, operator rule declaration, error catching, and modular semantic actions. Each language artifact in a modular workbench is associated with a customizable Typelang variant, allowing the type system for that artifact to be defined independently of others. This design is markedly distinct from traditional monolithic systems (such as those in Xtext or Spoofax), wherein one global type system is either hard-coded or replicated across all languages.

Typelang's modularity is realized by collecting feature boxes—annotated modules encapsulating type roles, operators, or semantic actions—during a collection phase. In the assembling phase, these are composed into a Typelang variant tailored to the artifact’s needs, resulting in an artifact-oriented, locally reusable type system. This mechanism underlies Typelang’s ability to separate language logic from editor integration and promote straightforward composition across DSLs in language families.

2. Modular Language Server Generation

A key objective of Typelang is to automate language server generation in ways that avoid the common bottlenecks of overlapping and duplicated implementations. Rather than generating a monolithic language server, the Typelang framework decomposes server functionality into modular feature boxes annotated for specific Language Server Protocol (LSP) capabilities (e.g., semantic tokens, document symbols, inlay hints). Upon artifact composition, these boxes are assembled into a single language server per artifact, implementing all required LSP functionality. This modularity both enables per-artifact customization and enhances maintainability by maximizing the reuse of functional units across different language servers.

3. Variant-Oriented Programming and Cross-Artifact Coordination

Typelang introduces the variant-oriented programming paradigm, treating product variants (distinct functional modules such as type system components or editor features) as first-class entities. Each variant is defined independently and coordinated via shared contexts, such as typing environments or global LSP graphs. This paradigm ensures interoperability among modules without exposing internal implementation details, and enables coordinated integration of interdependent software variants. Shared contexts abstract away global resources, allowing disparate language modules and Typelang variants to cooperate in implementing cross-cutting semantics (for typing, inference, etc.) without coupling.

4. LSP Plugin Generation and Automation

To further reduce complexity, Typelang includes an LSP plugin generator implemented as a Gradle plugin. Developers specify minimal configuration details and annotated templates (language name, file extension, launcher, etc.), and the generator automatically produces appropriate LSP plugins and syntax highlighters for editors such as VSCode, NeoVim, and Vim. This reduces the editor support combinatorics from manually coding plugins for every editor, $E$, to a single automated process ("100% automation")—a key strategy for scalable editing support (Bruzzone et al., 18 Sep 2025).

5. Quantitative Reductions and Evaluation

Typelang demonstrates marked quantitative improvement over traditional type system implementations. Empirical evaluation shows:

• Approximate 93.48% reduction in characters required for type system implementation per artifact compared to Java-based approaches.
• Average reductions of 82–83% in lines of code (LoC) and about 93% in number of characters (NoC) for per-artifact implementations.
• 100% automation of LSP plugin generation across supported editors.

All metric computations are explicitly presented in the paper; e.g., code reduction percentage as

$$\text{Reduction (\%)} = \frac{\text{LoC}_{java} - \text{LoC}_{typelang}}{\text{LoC}_{java}} \times 100\%$$

and the expression language configuration count as

$$L = \sum_{u \subseteq U, u \neq \emptyset} \left(2^{|O_u|} - 1\right)$$

with $U$ as the set of primitive types and $O_u$ as the set of operators on $u$.

6. Implementation in Neverlang

Typelang is implemented on the Neverlang modular language workbench. Neverlang artifacts (modules that declare syntax, semantics, and Typelang DSL code) utilize annotation processing to collect feature boxes for type system roles and LSP integration. These are injected into corresponding Typelang variants and drive language server and plugin generation, yielding a fully integrated pipeline from artifact specification to editor support. This approach realizes idiomatic modularity and reinforces intra-family type system reuse in practical deployments.

7. Impact on Language Families and Editing Support Complexity

Typelang directly addresses the artifact reuse problem in language families. By enabling per-artifact type systems and maximizing sharing of modular language artifacts, Typelang reduces implementation combinations from $L \times E$ (languages times editors) to $T \times 1$ (type systems times one editor layer), and further to $N \times 1$ (with $N \ll T$), where $N$ is the count of unique type systems after artifact reuse. These reductions yield uniform editing support (highlighting, error reporting, code navigation) and consistent semantics across related languages and dialects, minimizing codebase fragmentation and easing maintenance.

8. Mathematical Formalization of Reuse and Complexity Reduction

Reuse metrics are specifically defined in the paper:

• Normalized Absolute Reuse Degree (NAR)
• Operator Conditional Reuse Degree (OCR)

Both are constructed from set-based fractions over artifacts and operators. The overall framework supports quantifying the effect of reuse, modularity, and variant integration on development complexity using these explicit formulations.

---

Typelang thus represents a systematic DSL-based framework for modular, variant-oriented type system implementation and editing support, with empirical and mathematical validation of complexity reduction, full LSP automation, and scalable applicability to language families as deployed in the Neverlang workbench (Bruzzone et al., 18 Sep 2025).