Mps Language Modularity

MPS Language Modularity & Composition

Loading companion skills

Companion names in this skill are lazy dependencies: load only those relevant to the current task. If this skill came from an MCP server, use the host's skill loader to resolve the companion's unique discovered entry URI on the same host-assigned originating server. If the host has no server-backed skill loader, stop and report that limitation; do not silently fall back to a filesystem copy. If this skill came from a filesystem catalog, load the named sibling from that same catalog at <skills-root>/<skill-name>/SKILL.md, even if remote skill loaders are also available. Do not invent a tool name or server endpoint.

The design tier for multi-language MPS work: before authoring aspects, decide how the languages relate. This skill turns a 2×2 taxonomy into a decision procedure and routes each choice into the aspect skills that implement it.

The MPS-specific lesson: syntax composition is the easy part. MPS is projectional — no parser, no grammar to become ambiguous — so combining notations needs far less work than in parser-based tools (only alias clashes and completion UX still need a glance). The real difficulty is semantic: scopes, type systems, generator contracts, and migration. Choosing a modularity kind is mostly choosing where the dependency lives and how generated code interacts.

Critical directives

• Spend effort on semantics, not syntax. Scopes, type bridges, generator contracts, and migration are where modular languages break.
• Two questions decide the kind (below). Answer them before touching any aspect.
• MPS "extends" ≠ the design category. At the module level MPS calls almost any inter-language use "extension"; that tool-level dependency is independent of whether your design is referencing/extension/reuse/embedding. See references/design-principles.md.
• References vs. containment is the structural fork. Model a foreign element as a reference → referencing. Contain a foreign concept as a child → inline composition (extension vs embedding). Hard to reverse — pick deliberately.
• Reuse must be designed in. Abstract hooks, behavior contracts, and generator placeholders must exist before you need them; after-the-fact reuse (especially interwoven generation) is severely limited.
• The exported surface is an API. Behavior-method names, interface concepts, placeholder IDs, mapping labels, and generated abstract signatures are cross-language contracts — stabilize, version, and test them.

The two questions (the 2×2)

The four-kind taxonomy (referencing / extension / reuse / embedding) was introduced by Markus Voelter in his work on language composition (DSL Engineering). This skill adapts it to MPS practice.

"Inline / same fragment" means the concrete syntax the user writes — not where generated code ends up. Whether generated code is physically inlined is a separate axis (separated-vs-interwoven within Reuse), orthogonal to the kind.

Decision procedure

1. Must the new constructs be written inline, among the host's nodes in the same fragment/root?
   • No → step 2. Yes → step 3.
2. (separate fragments) May the new language know the other directly?
   • Yes → Referencing — cross-language references + search scopes.
   • No → Reuse — keep the core independent; build a separate adapter language that depends on both.
3. (inline syntax) Are the new constructs built specifically for this host, or do they come from a language that must stay independent (a reusable guest)?
   • Built for the host, may depend on it → Extension — subconcept the host's concepts; integrate type rules and generators additively.
   • Must stay independent → Embedding — add a third composition language depending on both host and guest, so neither needs to know the other.

If the goal is only to attach metadata to existing nodes (traceability, variability) rather than compose semantics, none of the four applies — see the annotations escape hatch in references/design-principles.md.