Summary
Top-level constant definitions of type Type cannot currently be used as type annotations in other definitions' signatures. In elaborate_sig (pass 1 of elaboration), each definition's signature is checked with an empty globals table, so references to previously-defined constants fail with "unbound variable".
For example, this should work but currently fails:
def my_int: Type = u32;
def id(x: my_int) -> my_int = { x }; -- ERROR: unbound variable `my_int`
Constant bodies already work — my_int can be referenced inside function bodies (elaborated in pass 2 with the full globals table). The limitation is specifically in type annotations within signatures (pass 1).
Desired behaviour
A top-level constant of type Type (or VmType) defined before another definition should be usable as a type annotation in that definition's signature, in any position where a type is expected. Definitions should not be required to appear in a particular order — forward references in signatures should also be supported.
Implementation
A constraint-solving approach with metavariables is likely the right fit: introduce a metavariable for each definition's type during an initial pass, then solve constraints as definitions are elaborated, supporting forward and mutual references naturally. Cycle detection (for value-level recursion) will be needed.
Current workaround
Inline the type directly (u32) instead of referring to a named constant.
Summary
Top-level constant definitions of type
Typecannot currently be used as type annotations in other definitions' signatures. Inelaborate_sig(pass 1 of elaboration), each definition's signature is checked with an empty globals table, so references to previously-defined constants fail with "unbound variable".For example, this should work but currently fails:
Constant bodies already work —
my_intcan be referenced inside function bodies (elaborated in pass 2 with the full globals table). The limitation is specifically in type annotations within signatures (pass 1).Desired behaviour
A top-level constant of type
Type(orVmType) defined before another definition should be usable as a type annotation in that definition's signature, in any position where a type is expected. Definitions should not be required to appear in a particular order — forward references in signatures should also be supported.Implementation
A constraint-solving approach with metavariables is likely the right fit: introduce a metavariable for each definition's type during an initial pass, then solve constraints as definitions are elaborated, supporting forward and mutual references naturally. Cycle detection (for value-level recursion) will be needed.
Current workaround
Inline the type directly (
u32) instead of referring to a named constant.