Program

What fascinated me was not merely making a DSL extensible, but making its extension machinery disappear before execution.

UniversalToolchain explores this form of extensible programming on .NET. Language features are independent modules composed into dialects. The pipeline separates frontend-oriented Bytecode, which preserves composed language semantics, from backend-oriented Abstract IR, which provides a stable execution and optimization model. Capability-aware lowering specializes local-variable access, external bindings, control flow, and calls into typed runtime or CIL operations. In six selected arithmetic hot-execution benchmarks, cached Wist CIL artifacts remained within 10% of a no-inlining C# baseline and allocated 0 B during measured execution; parsing and compilation were excluded.

The talk demonstrates a restricted pricing DSL, inspecting its deterministic runtime plan, tracing an expression through Bytecode and AIR into DynamicMethod-generated CIL, and executing it through both the AIR interpreter and CIL backend. It also reproduces a real parity regression involving external bindings and local-variable shadowing, showing how explicit storage semantics, capability contracts, deterministic composition, and cross-backend tests keep one extensible language from silently becoming two.

Project: github.com/Misha1302/Wist2

The recent rise of Large Language Models (LLMs), such as ChatGPT, Claude, and Gemini, has encouraged the automated generation of business-process models from natural-language descriptions. However, translating a narrative directly into BPMN 2.0 entails syntactic, structural, and semantic difficulties, especially when the required output is verbose and deeply nested.

This work proposes an intermediate Domain-Specific Language (DSL) as a more robust alternative to direct BPMN-XML generation. The talk implements a pipeline in which the LLM produces a simplified textual DSL, which is then parsed, validated, and compiled deterministically into a BPMN 2.0 model.

The evaluation compares robustness, structural quality, expected-feature coverage, and stability across synthetic processes and several LLMs. Results show high semantic and rendering success rates, supporting the value of an intermediate representation. An additional comparison with direct BPMN-XML generation further reinforces the advantages of the DSL-based approach, especially for more complex processes. The talk includes a demonstration of the implemented tool and the generated BPMN diagrams.

Demo: bpmn-dsl-demo.vercel.app — Code: github.com/ignagp34/BPMN-DSL-Monorepo

Programming Language One, more commonly known as PL/I, is a programming language first introduced by IBM in 1966 for its mainframe systems. As the saying “the mainframe is dead, long live the mainframe” implies, PL/I development is still very much alive. Advances in IDEs and the Language Server Protocol over the last decade have made it easier than ever to bring modern workflows and quality-of-life improvements to PL/I users. With that in mind, the speakers decided to build a language server and an accompanying VS Code extension for PL/I.

In this talk, we first introduce the landscape of mainframe programming languages and explain why there was a clear need for a PL/I language server. We then dive into the technical details, including the various macro preprocessors, syntax quirks, the sheer amount of configurability PL/I offers, and the challenges these features bring along. Finally, we present a live demo of the new PL/I VS Code extension, where we will explore the features mentioned above.

The emerging creative capabilities of LLM-based agentic AI introduce new challenges for systems engineering, particularly in digital hardware design. In agentic design flows, the quality of the resulting hardware depends critically on the model's ability to interpret design intent and to generate robust, semantically meaningful verification testbenches.

This work identifies the “Verilog paradox”: within the implement–verify–fix loop, the RTL (Register Transfer Level) produced by an agent is often semantically weak, a consequence of Verilog's limited expressive power as a hardware description language.

We show that digital design quality can be significantly improved by introducing strong typing of wires, enriching the semantic structure available to the LLM during both generation and verification. We demonstrate this approach through an industry-level processor implementation, illustrating how stronger semantics enable more reliable agentic design loops and higher-quality hardware artifacts.

Typhoon Modeling Language (TML) is a novel language for description of dynamic systems. It is used inside Typhoon HIL Control Center as the language for description of signal processing (SP) components. The type system of TML is based on tensor structures, with support for arbitrary dimensionality and nesting of tensors. TML enables writing generic numerical algorithms by enabling unified usage of scalar and tensor values inside expressions and with generalized support for broadcasting of nested tensor values.

TML uses an effect system for analyzing which side-effects are allowed in different simulation step points (such as reading or writing states and terminals), and implements additional domain-specific combinatorial correctness analyses using special guard blocks (such as usage of optionally present terminals). For additional type flexibility, TML implements an AST-level macro system with additional robust correctness analysis. TML supports detailed error reporting with domain-based hints.

The presentation will be accompanied by a demo in which the main concepts of graphical model creation inside Typhoon HIL Control Center will be presented, with the accent being on creating a generic user-defined numerical component (TML function) to showcase core language concepts. Model simulation will be run and signal values will be analyzed, with special attention paid to using components with different combinations of input types.

What does it take to build an extensible low-code platform, and can the same platform be used to build new languages? This talk explores both questions through BESSER, an open-source low-code platform, moving from its internal design decisions to its use as a language workbench.

We first look at language engineering in BESSER and the main design decisions behind the platform and how these decisions were shaped by the goal to have a platform that could be easily extended: why Python was chosen, why a UML-based core was adopted, and the design and implementation of the online graphical editor (editor.besser-pearl.org). We also present how agentic AI is integrated into BESSER to support modeling and code generation.

We then turn to language engineering with BESSER, showing how the same platform can serve as a language workbench for building new languages. By combining abstract syntax, Python-based executable behavior, and graphical concrete syntax, BESSER can generate complete web-based language environments, enabling, for example, the rapid development of proof-of-concept digital twins. Both phases are followed by a live demonstration.

Code: github.com/BESSER-PEARL/BESSER

The Agile Law Execution Factory (ALEF) is an MDSE solution that is developed and used at the Dutch Tax Administration to make law and legislation executable by computers. In previous editions of this congress, we presented ideas and concepts that we use in ALEF.

Now is the time to bring ALEF to the next level, allowing other governmental agencies and other organizations to use it. We worked hard to open source ALEF during the last few years. From a developer perspective this is a small step, but for the Dutch Tax Administration this is a giant leap. Besides that, the LangDev community has asked many times to share the code so that parts of ALEF, like the linguistics framework and the translator framework, can be (re)used.

In this presentation we want to share how we are scaling up the use of model driven development at the Dutch government, where you can find the concepts we presented during previous editions and how you might be able to help.

Code: github.com/belastingdienst/ALEF

Have you ever tried asking a coding agent to implement a new feature in your MPS project, only to have it run in circles for half an hour and make no progress? An MCP server helps, but how do you set up everything so that an agent can do its work in a separate worktree in the background?

What if there was a simple way to have an agent (or several) work on your MPS project in parallel with you or other agents without stepping on each other's toes? In this talk we demonstrate mops, a command-line (CLI) tool for MPS, and show how its architecture gives it capabilities beyond what most MCP servers can provide.

You will learn:

• Why you want a CLI rather than an MCP server for MPS
• How mops helps coding agents work with MPS projects
• How to use mops to run several agents on your codebase in parallel

Sergej has been working with JetBrains MPS since 2015, specializing in the infrastructure of MPS projects. Over the years he has helped customers across a range of industries, including automotive, medical, and tax/payroll, with MPS performance, architecture, and migrations. He writes about MPS at specificlanguages.com and holds regular free office hours for MPS developers at every level, from students to professionals.

AI coding agents like Claude have become highly productive tools for working with textual codebases. Language workbenches such as JetBrains MPS store models as structured ASTs rather than plain text, so agents need a dedicated interface to work with them. For MPS, several such bridges already exist: direct manipulation of the underlying XML, MCP servers such as JetBrains' MPS-MCP and itemis' Portalon, and CLI tools. Experience shows that the design of this interface largely determines how effective an agent can be.

This talk is an experience report from developing Portalon, an MCP server that gives AI agents structured access to the live model inside MPS. We optimise the interaction between agent and workbench continuously, using representative use cases as benchmarks and measuring wall-clock time, token consumption and model correctness. The talk covers the three interaction metaphors we offer at the MCP interface; which of them works best depends on the agent's task.

A live demo shows the current state, with an AI agent navigating, analysing and editing real MPS models. Most of these lessons are not specific to MPS and apply to agent support for language workbenches and DSL tools in general.

Every DSL needs a corpus of valid example programs whether it is for testing, fuzzing the language implementation and runtime, documentation, or evaluating an LLM's grasp of the language. Writing them by hand is tedious; generating them with an LLM yields plausible-looking code that silently violates the grammar, the type checker, or the structural shape. Lanzer closes that gap: it is a semiformal DSL that consists of campaigns, a small declarative spec that pairs an informal description (“sort an array of integers”) with formal constraints over the target AST (“require two function declarations; forbid eval; a main that calls a helper”).

Lanzer dispatches the campaign to any ACP-compatible coding agent (Claude Code, Codex, Gemini CLI), then validates the result two ways: the host language's own validator confirms the program is well-formed, and Lanzer checks every requirement against the parsed AST, retrying until the sample properly satisfies the spec. Langium's AST reflection lets Lanzer derive selectors, reachability checks, and requirement validation from any grammar, so onboarding a new language needs almost no configuration and no changes to the language itself.

The talk includes a live demo of Lanzer generating constrained, type-correct programs for a statically-typed variant of Lox.

GPLs benefit from a self-reinforcing cycle: abundant training data fuels capable AI autocompletion, lowering adoption barriers and expanding codebases. Recent literature finds that 12 languages command nearly three-quarters of training tokens, leaving over 70% of languages virtually invisible to AI. DSLs sit trapped in this long tail of data scarcity, leaving off-the-shelf LLM completion unreliable or absent. Yet DSLs persist where domain expressiveness, reduced cognitive load, and accessibility to non-experts matter; at XLINQ, they are the foundation of the tooling stack.

We present an autocompletion service for an XLINQ proprietary DSL that teaches the model the language at inference time. Existing DSL artifacts (e.g., templates, documentation) provide structured, high-signal context for robust AI-based autocompletion tooling. Grammar structure drives completion routing, reducing the noise by constraining the model's attention to what is relevant. A two-phase design separates DSL priming from per-request specifics, keeping latency competitive despite the depth of context injected.

An evaluation framework — anchored in ground-truth comparisons and an LLM judge calibrated with human assessment — serves a dual role: quality gate and data factory. Verified completions accumulate as a natural by-product, seeding a corpus that opens a realistic path toward fine-tuning a model as the language and dataset mature.

Demo: live showcase of the autocompletion service completing across DSL sections and boundary conditions, with a walkthrough of the two-phase generation process and the evaluation pipeline that guided development.

Last year, Meinte has been working on MyFPL: My (own) functional programming language. It's the more finished follow-up project of GenFPL. One of its aims is to experiment with a couple of features that make MyFPL different from most existing FPLs, such as: homoiconic reduction with unknowns (sometimes AKA “partial evaluation”), function parameters that are identity-rather-than-position-based (leading to “super-Schönfinkelization”), and decision tables.

In this talk, Meinte explains his goals for MyFPL, its architecture and projectional approach, its features and characteristics, and its implementation — which relies on LionWeb, of course. Much of the explanation is done as a live demo.

He also showcases MetaRel: a documentational DSL developed to describe meta-relations between artifacts in a modeling context. Its raison d'être is the observation that one artifact might have several meta-relations with other artifacts at the same time, and that parts within an artifact might have meta-relations of varying kinds. In particular, the notion of “meta-level” can be made more precise using MetaRel.

Risk and probabilities are notoriously difficult for humans to grasp intuitively. We believe that visual Domain-Specific Languages (DSLs) provide a solid foundation for describing these complex phenomena. By enabling direct manipulation, visual DSLs allow users to intuitively explore and simulate “what-if” scenarios as conditions change, mapping out complex trees of possibilities.

Using Daga, a library for visual modeling, we have implemented a series of modeling scenarios targeting Binomial and Bayes families of probabilistic problems. This approach allows domain experts to specify and analyze problems across diverse fields, including aerospace failure analysis, asymmetric risk, insurance modeling, and incident tracking. In this talk, we demonstrate our proof-of-concept implementations, discuss the underlying language architecture, and share insights on building visual languages for probabilistic reasoning.

Metadev is applying LLMs and MCP to enhance modeling tools in commercial products. This talk covers and explains different approaches taken to enhance the modeling capabilities in different domains like class UML modeling, BPMN2 models, docker-compose container models and SysML2: incorporating AI assistants, adding direct voice support and testing different approaches to make models understandable by LLMs, so as to be able to produce valid models with as few corrections as possible. Different tests have been made with commercial LLMs to benchmark their capabilities in terms of cost, latency, recall and precision.

The combination of AI with generative capabilities is a great addition to translate user's desires into models. However, using brute-force LLMs to generate code for big domains is not effective in terms of time, costs (tokens), replicability and hallucinations when compared with traditional MDE approaches. Therefore, we have been exploring an effective mixed approach where gen-AI is useful close to the user, to automate and simplify repetitive tasks, while at the same time avoiding AI on the translation stages to enforce traceability and warranty consistency on generated artifacts.

In a sense, MDSE turns ordinary users into software developers. Inevitably, as the adoption of an MDSE solution grows, it encounters many of the same challenges as traditional software development, such as organizing a code base into multiple modules, some of which are more general in nature. Since our users are non-technical, conventional software engineering solutions cannot be applied directly.

This presentation demonstrates a solution that enables non-technical end users to reuse their MPS projects without requiring them to specify build details. The solution extends the MPS build language with declarative constructs for specifying dependencies and the artifacts that are required or produced. By making a few assumptions — for example, that each repository contains a single project — it becomes possible to generate build scripts for end-user specifications, including dependencies on specifications located in other projects, without requiring users to provide technical implementation details. The source code will be made available before the start of the conference.

Demo outline “project dependencies for end user”:

• MPS project A using a sample language
• MPS project B extending project A (with references to concepts in project A)
• IDE action to make A available in MPS when only B is opened
• Continuous Integration for B (and A)

Nelumbo was introduced at LangDev 2025: Nelumbo lets you define your declarative language syntax and semantics and immediately edit, parse, test, and execute your language in any IDE and browser.

The roots of Nelumbo lie in the desire to have the best tool for language development, built upon decades of love and hate experiences with DSL tools like EMF, MPS and many others. Nelumbo is developed with integrability in mind: think of agentic AI, IDEs, databases, the web, etc.

Wim will demo Nelumbo's newest features and give the audience a hands-on experience with Nelumbo's http server and browser-based editor. Nelumbo is open source and developed by a team of 4 developers and is well documented.

Code: github.com/ModelingValueGroup/nelumbo

Implementing interpreters for programming languages and DSLs often requires balancing simplicity, extensibility, and support for advanced execution techniques such as symbolic execution. However, extending an existing concrete interpreter with symbolic execution capabilities often requires substantial re-engineering, leading to duplicated implementations and increased maintenance effort.

This talk presents an approach to writing interpreters that seamlessly become symbolic interpreters by using continuation-passing style (CPS) as the underlying computation mechanism. The approach is implemented as a lightweight internal DSL that tries to hide the complexity of CPS, enabling language semantics to be expressed in a modular and reusable way while abstracting over the execution details.

We introduce this simple DSL, explain how continuations simplify the implementation of interpreters and enable symbolic execution without rewriting the interpreter, and discuss the main implementation ideas behind the library. We also demonstrate the approach on a small language, showing how the same interpreter definition supports both concrete and symbolic execution, and share our experience using the framework.

We are waiting for somebody to start a discussion about the position of model driven software engineering. In previous editions of LangDev a lot of great stuff has been shown; at the same time the question arises: are we on the right track, or are we stuck?

What about new technology that is available now — are we still relevant? And if so, how can we scale up so that more engineers start doing this? To realise the promises of MDSE, shouldn't we focus more on (deeper) formalizing new domains and collaboration with domain experts rather than ‘yet another language workbench’? Diversify the applications of modelled domains and the kind of generated artifacts? To which extent does our tooling support us in these endeavours?

In what way might integration of language workbenches in AI tooling help us? Will it enable domain experts to participate in the formalisation process? Or even more fundamental, do our users still need formalised models now they are able to instruct computers directly using natural language? And if so, why exactly, and how can we convince our users? We can't answer this alone; we need you to actively participate, open-minded and critical. See this as a big panel discussion.

Defining a metamodel is a sequence of abstraction decisions: which concepts exist, how they are classified and related, and which invariants hold. Making those decisions is how a modeler understands a domain; a modeler who does not follow them does not understand it. A large language model can return a valid, plausible metamodel in a single shot: the artifact appears, but the decisions that would have produced it do not. The metamodel can be correct while the modeler never formed the conceptualization behind it. We call this gap domain knowledge debt: unlike technical debt, it is a property of the modeler, not the artifact, invisible at delivery and paid later, when the metamodel must be extended or transferred.

The trouble is not the LLM but that it acts as an oracle, making the abstraction decisions in the modeler's place. Our thesis: the LLM should be a tool, not an oracle, an instrument the modeler wields to reach each decision rather than an authority that supplies it. We make this concrete as a Socratic, five-phase construction that elicits each abstraction decision, shown in Jjodel, a reflective metamodeling platform, on a library domain where one word hides two concepts.

Demo: a short live walkthrough in Jjodel, building the library metamodel through the five Socratic phases (concept identification; classification; relations and multiplicity; constraints; refinement), with the speaker posing the questions that elicit each abstraction decision rather than an LLM supplying the answer.

At Xlinq, entire business applications — data models, processes, queries, and permissions — are specified through a family of purpose-built DSLs and generated into running systems backed by a database. Once such a system is live, every DSL program change becomes a production concern: how do you move a running application and its database from one version to the next while minimizing disruption and manual work?

We present the changeability mechanism we use to evolve generated applications. A single declarative configuration artifact captures the delta between two DSL program versions. Our toolchain diffs the previous and current DSL programs (via tags or branches) to automatically detect a wide range of structural and behavioral changes to the data model, translating them into safe, batched, lock-aware database migrations, alongside detecting new or modified queries. Many changes are handled fully automatically; for the rest, engineers author minimal manual pre/post migration and rollback steps, executed in a well-defined order alongside system-level migrations.

This talk is a real-world experience report on evolving language-driven systems safely in production, cutting across abstract/concrete syntax, semantics, and transformations. We'll walk through a real version-to-version migration end to end, including a live walkthrough of authoring a spec change, generating the migration config, and applying it to a running instance.

TRUMPF builds lasers for cutting and welding, used in various industries. Programming these lasers comprises diverse activities across a range of domains. Over time, TRUMPF developed several editors for these activities — as TRUMPF nowadays provides not only devices, but integrated solutions. Due to the different focus areas, these editors use different representations of the underlying program, which complicates data exchange and close cooperation.

As a solution, we developed a DSL capable of representing relevant aspects of a program in a unified language. We used MPS for prototyping, C# for backend development, and TypeScript for frontend implementation. LionWeb ties all technologies together.

This talk presents TRUMPF's challenges, the advantages and issues with DSL-based development, and how LionWeb underpins the solution. We present the language development process, and how LionWeb ideas helped in a real-world project: unified M2/M1 representation, generators and tools for C# and TypeScript, the bulk and delta protocol, language evolution, and derived models.

After talks at previous LangDev installations explained the idea, the bulk, and delta protocols, we focus on realized and potential use cases of LionWeb — next to a status update.

Status update. LionWeb release 2026.1 contains the finalized delta protocol. We've also improved the implementations in host languages like C#, Java, Python, and TypeScript, and implemented the delta protocol in LionWeb Server.

Real projects. Federico/Strumenta uses LionWeb to store ASTs during legacy modernization, handling up to 67 million nodes. At TRUMPF, LionWeb ties prototyping in MPS, backends in C# and WebAssembly, and browser-based UI and web workers together.

Potential use cases. The LionWeb delta protocol supports live editing, and can provide a common, shared state over several parties, either in point-to-point or hub-and-spoke topology. We spell out how a hypothetical LionWeb-based language workbench would look like. LionWeb carries “integration” in its name for a reason: dedicated support for model- and text-based systems, strong object identity, language evolution, and different views (aka “derived models”) make a great integration platform.

At Xlinq we have an ecosystem of DSLs, each of them taking care of one of the aspects of the business domain. One of these DSLs, Octo, is responsible for the orchestration of business processes, by referencing business entities, invoking routines defined in the other DSLs, and managing input/output through files of various formats. A DSL that is still missing in this ecosystem, though, is a DSL for functional testing of such business processes.

In this talk we present how we solve the lack of the functional testing DSL by bootstrapping Octo. To test a business process, we create a business process that invokes it, provides test input data, and checks the resulting output or persisted data. The testing outcomes are stored as business entities, and file input/output allows for generating testing reports.

This approach doesn't come without a need to solve certain challenges. For example, we need to solve the technical challenge of organizing dependencies between a project-under-test and the test project, so that all the infrastructure of the project-under-test runs properly. And from the practical point of view, we need to provide clear test templates and define a methodology for the business engineers who have to write tests for their business processes.

Demo: we demonstrate how the Xlinq portal, generated from the DSL models, works for a functional testing project (test cases as business processes + test results as business entities).

Language workbenches like Langium enable DSLs with editor support for domain experts. They parse text into ASTs, which are transformed into other data structures or stored in databases. Programmatically creating or updating existing ASTs, e.g. for complex refactorings, requires transforming ASTs back to text, which is not yet supported by Langium. Therefore, generic serialization facilities for Langium DSLs are under development and presented in this talk.

In contrast to hand-written serializers for specific DSLs, which are time-consuming and error-prone, the generic serializer for Langium is designed to serialize most parts of Langium grammars out-of-the-box with reasonable performance and customization possibilities for specific DSLs.

This talk motivates use cases for serializing ASTs back to text, explains challenges during serialization, and shows the architecture of the Langium serializer. The live demo applies the generic serializer to a concrete DSL, including customization possibilities. The DSL community is invited to review the current state of the generic Langium serializer and to discuss its future improvements.

StruktJS is a fast, experimental projectional language workbench currently in the prototyping phase, built to be easy to pick up for users and language designers. Programs live as clean, human-readable text/code — lightweight, efficient for tools and LLMs, and effortlessly editable and diffable in any editor. StruktJS is built on Eclipse Theia and standard web technologies, running in the browser and optionally as a desktop app. It supports features such as projectional editing, typechecking, code generation, live collaboration, internationalization, and a few existing VS Code extensions.

The talk isn't only about the tool — it's about how it came to exist. StruktJS was built through months of back-and-forth with an AI coding agent, from architecture down to the smallest test. It will be shared honestly what worked, what did not, and what that means for building language tools going forward.

Demo outline:

• Open an example two ways: plain text in a normal editor, and the projectional editor in StruktJS — to show the same file is both
• Structural editing basics: side-transformations, code completion, live checker/type-system feedback
• Switch to the desktop (Electron) build of the same IDE
• Let the AI agent implement a small program and run it
• Live session: two peers, live shared editing of the same AST, presence cursors + host handoff

This is a report on the usage of LionWeb in a real-world legacy code migration project: the awesome, the bad, and the ugly. How do you modernize a 2-million-line legacy codebase while it's still evolving? We engineered a transpiler which analyzes IBM EGL code, compiles a migration plan, and outputs Java + Spring Boot + SQL/JDBC code (batch programs and SOAP web services).

The migration plan takes dependencies into account, dividing the work into steps of increasing code complexity, such that each step is only dependent on the preceding ones: migration can then proceed incrementally as the transpiler is being written, with new language constructs added when needed, not earlier.

That's part of a broader strategy to maintain a lean, iterative approach where code is regenerated as often as possible, to test new features and verify bug fixes, and to adapt to new versions of the source codebase. With efficiency in mind, we adopted a pipeline approach where steps exchange LionWeb models, using the model repository APIs as well as custom-built snapshots and caches, on top of Strumenta's Starlasu AST Transformers.