Documentation

Network2Go.Definition

Compiling TLA⁺ operator and function definitions into Go top-level declarations.

Four forms, and which one a declaration takes is read off its type, not its syntax:

Type variables reach only the parametric-operator form. A rigid type variable compiles to a Go type parameter, and each one carries a dictionary parameter beside it, since a polymorphic definition is called at many types and its ordering therefore cannot be a closed expression. Go has no generic package-level var, so the other three forms — all of which are vars — must reject one. That is a restriction of Go's, not a choice: there is nowhere to bind the parameter.

CONSTANT/VARIABLE declarations and ASSUME produce nothing. A CONSTANT is supplied by whoever wires the generated code into a runnable system, under the capitalized name every reference to it compiles to — the same boundary the absence of an emitted main sits on. An ASSUME is a proof obligation about a specification, with no computational content to emit.

Does name occur in e as a reference to the enclosing function definition being checked?

A function definition's body sees its own name in scope, resolved through Ξ like any module-level name (.module); a bare occurrence of name inside name's own body is therefore a self-reference. The caller has already ruled out a parameter of the same name, so the check is exact and no binder-respecting scope walk is needed.

Compiles one top-level declaration, or nothing for the ones with no computational content.

Equations
Instances For

    A whole declaration list, keeping only what compiles to something. Order is preserved: Go resolves package-level declarations independently of the order they are written in, so this matters for readability rather than for correctness.

    Equations
    Instances For