Language engineering through ia-toolset and BahnDSL

A domain-specific language is justified only when its concepts and guarantees are clearer than the general-purpose code or configuration it replaces. Our evidence for making that tradeoff is inspectable: ia-toolset and BahnDSL are open-source language-plus-tooling projects, not portfolio abstractions.

ia-toolset: semantics that can be investigated

ia-toolset supports Interface Automata for Shared Memory, a formalism for describing component behavior and reasoning about how components interact. Its textual language is connected to composition and refinement checking, simulation, and debugging. The point is not simply to parse a model. The toolset makes the model’s semantics executable so a user can inspect incompatibility and follow the behavior that produced it.

The project also demonstrates why editor work is part of language design. A language server and VS Code extension bring parsing, validation, and domain feedback into the authoring loop. The web application makes the same ideas easier to access. For a formal method to be useful beyond a paper, error states and execution paths must be visible in the tools where models are written.

BahnDSL: one model, several useful artifacts

BahnDSL describes model-railway configurations in domain terms and compiles them into artifacts used by the surrounding system. The public project includes Eclipse-based and VS Code tooling, with generation targets including YAML, SCCharts models, and C code. That path — from a domain model through validation to multiple outputs — is a practical example of model-driven engineering.

Generation creates leverage only if meaning stays consistent across targets. Constraints belong in the language and validators rather than being rediscovered independently by every generator. Generated files also need clear ownership: either they are reproducible build artifacts or they have an explicit extension mechanism. Silent manual edits to generated output make the model cease to be the source of truth.

The hard boundary is semantic, not syntactic

A grammar can make configuration pleasant to read, but syntax alone does not justify a DSL. The substantial work is agreeing what a model means, which invalid states can be rejected early, how references and types resolve, and what users see when a rule fails. Simulation and debugging matter when static validation cannot explain dynamic behavior. IDE features matter because rapid, local feedback determines whether specialists can use the language confidently.

When this work is a reasonable fit

These projects do not support a claim that every complex business process needs a new language. A DSL becomes plausible when a stable domain vocabulary exists, specialists repeatedly express the same structures or rules, mistakes are expensive, and outputs or analyses can be derived consistently. If ordinary typed code, a schema, or a form is sufficient, it is usually the smaller and safer choice.

Automata keeps language engineering deliberately specialist and limited. ia-toolset and BahnDSL show the actual scope: language design tied to validation, executable semantics, generation, and usable IDE support. They also let a prospective collaborator inspect the work directly before deciding whether that depth matches the problem.