CoreLangA business language and common starting point

CoreLang

From source text to editor feedback and execution

CoreLang can reuse working editor and execution components, but the parser and connections that make them a CoreLang toolchain still need to be built.

Content-authored diagram

Reuse execution tools without exposing them in the language

CoreLang would add the parser and translation steps needed to connect business rules to existing CREXX tools.

  1. CoreLang source

    A domain specialist writes a rule using agreed CoreLang terms.

  2. Parser and checks

    New CoreLang tools identify the structure, check the meaning and return useful errors.

  3. Checked meaning

    A small internal record preserves the responsibility, deadline, exception and other agreed meaning.

  4. RXAS emitter

    A new CoreLang component writes readable RXAS for the part that needs to execute.

  5. rxas and rxlink

    Existing CREXX tools optimise, assemble and link the generated program.

  6. RXVM

    The existing CREXX virtual machine runs the linked program and returns its result.

Read the connections
  • CoreLang source → Parser and checks: read and validate.
  • Parser and checks → Checked meaning: record the agreed business meaning.
  • Checked meaning → RXAS emitter: select the executable part.
  • RXAS emitter → rxas and rxlink: provide readable assembly source.
  • rxas and rxlink → RXVM: produce and run a linked program.
The CoreLang source, parser, checks and RXAS emitter are proposed. The rxas assembler, rxlink linker and RXVM already exist in the CREXX project.

Return useful information to the author

A CoreLang parser will read source text and identify its structure. Language checks will then decide whether the rule is complete and meaningful. For example, they should report that a rebooking rule has no responsible team and point to the relevant place in the source.

DSLSH already keeps an editor and parser synchronised. The editor sends document changes; DSLSH updates the parser view and returns highlighting and error information. THE CREXX Edition demonstrates that connection in a working editor. Its browser interface is a working proof of concept, not a production or multi-user web editor.

CoreLang should use these components for its first authoring demonstration while remaining usable through other editors and domain-specific interfaces.

Reuse the CREXX execution path

When an example needs to run, the proposed first path is:

  1. The CoreLang parser identifies the source structure, and CoreLang validation checks it against the agreed business meaning.
  2. A small internal form carries the executable part without exposing machine instructions to the language author.
  3. A CoreLang emitter writes RXAS, the readable assembly language accepted by the CREXX assembler.
  4. The existing rxas tool checks, optimises and assembles that source.
  5. The existing rxlink tool links the required modules and libraries.
  6. RXVM, the CREXX virtual machine, runs the program.

The CREXX repository contains the working assembler, linker, virtual machine, libraries and supporting tools. The CoreLang parser, emitter and connection from source to execution are proposed work. Using this path would not make CoreLang use cREXX syntax.

Keep LLVM as later research

An LLVM backend could later produce native machine code, but it requires stable decisions about values, calls, errors, libraries, debugging and packaging. Those decisions are more complex than the first small example needs.

The shortest useful path is to make one CoreLang example work through RXAS. LLVM experiments can follow when they answer a specific question and can be compared with the working path.

Related work

What the other projects contribute

  • DSLSH and THE supply the preferred first editing path.
  • The CREXX repository is authoritative for RXAS, rxas, rxlink and RXVM behaviour.