5.0 Semantics

The role of semantics is to encode the meaning of the language into a set of deterministic rules and specified sequences of operations.

There are two types of abstract semantics explicitly defined in RDCore.SDK:

The environment host may provide additional semantics through external providers (extensions); static semantics are effective in design-time and fully available to the semantic analysis layer.

Runtime semantics are partially available to the semantic analysis layer (for simulated execution pipelines), but generally unavailable in a static context.

5.0.1 Static Semantics

The role of static semantics is to determine a declared type for a given bound expression, given the determined static declared type of its inputs.

Static semantics always yield a StaticSemanticsEvaluationResult that represents either:

👉 In most error cases, the compile-time error metadata returned is for a TypeMismatch error.

5.0.2 Runtime Semantics

The role of runtime semantics depends on the type of node being evaluated:

  • Directives and literal or constant expressions evaluate to their static / compile-time value;
  • Operators evaluate a VBTypedValue from their operands;
  • Statements induce side-effects to program, global, or host environment state.

5.0.2.1 Operator Evaluation

Note

This section describes the implementation of MS-VBAL §5.6.9.2 Simple Data Operators.

The evaluation pipeline of all operators follows a clear sequence:

  1. The effective type of the operation is determined, based on the declared type of its operands;
  2. Validation: all non-null operands are let-coerced to the determined effective type of the operation;
  3. Evaluation: a templated method evaluates a result, having the execution context and the validated operands to work with.

The sequence may be aborted at any point to return an error result that encapsulates VBRuntimeErrorInfo error metadata.

5.0.2.2 Statement Evaluation

Note

The specification of this section is currently a work in progress.

5.0.3 Semantic Analysis

The analysis pipeline of all operators follows a clear sequence:

  1. The effective type of the operation is determined, based on the declared type of its operands and invoking the same methods as runtime semantics;
  2. Validation: all non-null operands are let-coerced to the determined effective type of the operation, using the same runtime semantics let-coercion provider as the evaluation pipeline;
  3. Semantic evaluation: a templated method evaluates a semantic result, having the execution context and the validated operands to work with but without inducing any side-effects.

The Analyze method then yields a builder that builds a semantic context for this specific expression node that includes the results of each evaluation step:

👉 The role of the Analyze method at this level is simply to report the semantic facts of an operation, that usually cannot be inferred from the operands or effective type alone. These flags are pure facts, not opinions.

🧩 The role of analyzers in extensions like RDCore.Diagnostics is to inspect the flags and errors in these _semantic contexts, and issue diagnostics. While error diagnostics are reserved for coded syntax/compilation and runtime/application errors, a hint or suggestion diagnostic can be as opiniated as needed.

Note

Warning diagnostics should be used carefully, for flagging potential bugs or logical errors causing unexpected or unintended behavior, or perhaps severe performance issues. Always consider the possibility of there being a treat warnings as errors host environment configuration setting: if a diagnostic is not worth breaking a build over, then it's not a warning.

RDCore implements the MS-VBAL type coercion rules verbatim through pattern-matching against its type system.

⏮️ RD-VBAL §4.0 Program Structure | ⏭️ RD-VBAL §6.0 Standard Library

Edit this page