Syntax and Names

This page describes the layout of .proc files and how the names written in them resolve: roles, components, instances, measures, inputs and answers. The statements themselves are in the Statement Reference, the expressions in Expressions, Types and Units.

Files#

• Steps and procedures live in .proc files of a library package, next to its package.yaml (see Libraries and Validation). A library may have any number of files; names are shared by all of them, so a step defined in one file is called from another.
• A file contains top-level step and procedure blocks, in any order: calls resolve whatever the order of the definitions.
• Anything else at the top level is an error (procedure::unexpected-line).

Lines and blocks#

• One statement per line. A statement never spans several lines.
• Blocks by indentation. The lines of a block are indented under the line that opens it, all by the same amount. Only step, procedure and if failed open a block.
• Spaces only. A tab in the indentation is an error (procedure::indentation, "tab in indentation").
• A line indented deeper than its block, or an indented block under a line that opens none, is an error (procedure::indentation).
• Comments start with # and run to the end of the line, outside strings. Blank lines and comments are ignored.

# Operations on a TCU outside the procedures of the specification.

procedure "Standby TCU"
  uses sat: platform-v3
  input tcu: tcu_id

  step "Command standby"          # an inline step, inside the procedure
    send standby to sat.tcu[tcu]
    expect sat.tcu[tcu].mode is STANDBY within 10 s

Strings#

Step names, procedure names, questions of ask, texts of log and descriptions are strings in double quotes: "TCU answers". A string cannot contain a double quote and does not span lines; an unterminated string is reported (procedure::syntax). Strings are never values in expressions (expr::string-value). Only the text of a log holds expressions, between braces ("TCU1 at {sat.tcu[TCU1].anode_voltage}", see log).

Descriptions#

A description "…" line in the header of a step (inline steps included) or of a procedure describes it for operators. The hover of the editor and the launch form of the web console show it.

procedure "Hot standby test"
  description "Powers the platform from the bench supply, then brings a TCU to hot standby."
  uses sat: platform-v3

• At most one per step or procedure (procedure::duplicate-description).
• It is not part of the compiled procedure: writing or rewording a description changes neither the hash of the procedure nor its validation in stellar.lock.

Keywords and reserved words#

Every line starts with a keyword:

An unknown keyword is reported with the closest one (procedure::unknown-keyword); a keyword in the wrong place too (procedure::misplaced), for instance a send directly in a procedure or a do in a step.

Inside a line, to, with, via, within, retry, every, for, as and into split the line into clauses, outside strings and brackets. They cannot be used as names on the lines that accept them. A clause keyword written twice on one line is an error. In a type, of follows file_id (file_id of lttm).

In expressions, and, or, not, is, true and false are keywords, and param followed by a path reads a parameter, with in <mode> after the path for a given mode.

Names#

• Roles, inputs, typed answers, argument names and environments are identifiers: ASCII letters, digits and _, starting with a letter (procedure::invalid-name otherwise).
• Platforms in uses are catalogue package names, such as platform-v3 or lab-psu.
• Step and procedure names are free strings. Step names are unique in a library, and so are procedure names (procedure::duplicate-step, procedure::duplicate-procedure); a step and a procedure may share a name, since do calls steps and run calls procedures.
• A library step must have a name (procedure::anonymous-step); anonymous steps exist only inline in a procedure.
• Roles, inputs and the answers of ask … into share one namespace per step or procedure (procedure::duplicate-name). An answer is visible in the statements that follow its ask.

Addressing#

A path names what a statement reads or commands. It starts with a role; each segment may be indexed with […].

Rules:

• Instances. A multi-instance component is always indexed, by a value of its instance enum (TCU2) or by an input of that enum type (tcu); a single-instance one never is (procedure::missing-instance, procedure::unexpected-instance, procedure::unknown-instance). Measures and roles are never indexed.
• Single component. For a platform with one component, the component is omitted: send output_on to psu, check psu.voltage > 27 V. On a platform with several components, a component must be named (procedure::several-components).
• files. The on-board directory is indexed by an input declared file_id of <file type>, resolved at run time; a literal identifier is refused. Its telecommands receive their file_id argument from the instance: do not write it in with (procedure::file-id-argument). See Files and Streams.
• link. The standard link component exists for every target, one instance per link. sat.link[nominal] is accepted by the compiler whatever the link: link names belong to the target, not to the platform, and are checked when the run request is resolved (run::unknown-link). See COP-1 and the Link Component.

Roles and inputs#

uses <role>: <platform>
input <name>: <type>

• uses sat: platform-v3 declares a role typed by a platform. The platform must be a catalogue the library depends on (procedure::unknown-platform); its version is fixed by the library, see Libraries and Validation.
• input declares a typed input; see Input types.
• An inline step declares neither (procedure::inline-declaration): it uses those of its procedure.

Name resolution in expressions#

In a condition, an argument value or a call argument, a name resolves in this order:

1. a path starting with a role: a measure (sat.tcu[tcu].mode, psu.voltage);
2. an input or a typed answer of the step or procedure (bus_voltage, measured);
3. on one side of is, or as the value of an enum argument, a value of the enum on the other side (STANDBY, SAFE_MODE).

An unknown name is reported with the closest known one (expr::unknown-name, expr::unknown-enum-value).