Two roles, one practical test
CoreLang is the principal worked example through which the developing DomainLang method will first be tested. Building it will expose weak questions, missing assets and unclear terms in the method.
CoreLang is also intended to become a common base for suitable business-related domain languages. Instead of starting every language with a new parser, editor connection and runtime, a team could reuse the CoreLang structure and tools, then add the words and checks required by its domain.
What reuse should mean
A rebooking language might add concepts such as appointment, cancellation, offer and working day. The common base should provide consistent ways to structure statements, identify errors, connect to an editor and exchange the checked result with other tools.
This is a design target, not current behaviour. The first example must define which parts are genuinely common and show that a domain extension remains clear to its intended authors.
What remains owned by each language
Each language owns the meaning of its domain words and rules. Reuse must not silently turn a service policy into a programming-language concept or expose CREXX assembly instructions (RXAS) in business source. A visual, descriptive or highly specialised language may be better served by another notation and toolchain.
If a CoreLang-based language needs to run, it can use the proposed RXAS path. That choice reuses CREXX infrastructure; it does not make CoreLang or the domain language a REXX dialect—a language variant that follows REXX syntax and behaviour.
How the accelerator will be judged
The first comparison should record how much language-specific work was still required: vocabulary, meaning, validation, parser changes, editor support, tests and execution code. CoreLang earns its common-base role only if reuse reduces that work without making the resulting language harder for domain specialists to understand.