Language design

This page states the design the language follows. What the compiler accepts today is in the Guide and the Reference; where they differ from this page, they describe the current compiler.

A RobotDSL program combines four descriptions into one checked model.

Domain	Describes
CoreDSL	Components, internal joints, attachment frames, and physical/data interfaces
WorldDSL	Scene entities, placement, support surfaces, and task locations
TaskDSL	Actions, control flow, inputs, results, and resource use
EvaluateDSL	Optional assertions and the observations needed to judge them

Names and values

Declarations have explicit names. Imports select declarations from the libraries supplied to the compiler. Missing or ambiguous references are errors; instance names do not imply placement or behavior.

Physical quantities carry units, and spatial values identify their frames. Static transforms resolve at compile time; dynamic transforms need a runtime provider. An omitted optional argument may use a defined default. An invalid explicit value cannot silently become that default. Missing physical values remain unknown.

Robot and world

A component can be one rigid body or an articulated subassembly. Instantiation preserves its internal joints and exposes its declared interfaces. Mechanical attachment, power, command, and sensor connections are separate operations. Composition checks their compatibility and the resulting assembly's constraints.

World entities carry explicit poses, scale, and static or dynamic behavior. Visual geometry, collision geometry, and navigation maps have separate meanings. A rendered mesh does not establish physical properties or traversability. Named locations and regions provide references for tasks and assertions.

Tasks

Actions declare typed inputs/results, required capabilities, resources, and completion/cancellation behavior. Each action instance has its own arguments.

Control	Meaning
Sequence	Run children in order, continuing after success
Fallback	Try alternatives after failure, stopping at success
Retry	Reattempt a failed body within a bound
Repeat	Execute a body for a declared number of iterations
Timeout	Request cancellation when a deadline expires
Parallel	Run children under explicit completion, cancellation, and resource rules

Pseudocode illustrating branch-specific goals and results:

sequence:
    navigate robot to station_a
    image := fallback:
        capture camera
        sequence:
            navigate robot to station_b
            capture camera
    inspect image

Both destinations and both branches are checked before execution. Visiting station_b is required only when that branch executes. Every successful path produces the image consumed by inspect.

A value must be available on every path reaching its use. Failed or cancelled attempts provide no result unless the action declares partial results. Retries have distinct execution identities and cannot reuse stale results accidentally. They do not undo physical effects. Cancellation is a request whose completion must be observed; exclusive resources remain owned until released.

Requirements and evaluation

Provider choices are explicit. Actuation, odometry, state estimation, localization, mapping, planning, and control are separate requirements. Navigation does not universally require lidar or SLAM; the selected provider determines its inputs. Maps, calibration, and pretrained policies are explicit resources. Compilation checks their interfaces and does not perform calibration or training.

EvaluateDSL checks declare their observations, scope, and timing. Unsupported requested enforcement is an error. Analysis-only requests are identified as such. Missing evidence is not a pass, and user assertions cannot weaken independent benchmark criteria. Physical outcome, execution conformance, and runtime health remain separate results.

Target-specific restrictions are checked during binding. A target rejects behavior it cannot preserve rather than silently changing the task. See Architecture for the compiler boundaries.