spec: Introduce array expressions

[RobinJadoul]

Closes #135

To be merged after #271

[greptile-apps]

Greptile Overview

Greptile Summary

• Adds a new expression form for arrays (["arr", ...]) and renders it in both code and math formatters.
• Updates chip tooling parser/typechecker to recognize array expressions and updates some TOML specs to use array padding values.
• Adjusts chip.typ preprocessed-variable detection to avoid treating unknown types as preprocessed.
• Main issue: the new math formatter for arrays likely emits nested $...$ math blocks, which will break Typst compilation where expr_to_math is embedded in other math expressions.

Confidence Score: 3/5

• This PR is close to mergeable but likely breaks Typst compilation due to the new array math formatter emitting nested math delimiters.
• Core changes are small and scoped, but the expr_to_math implementation for arrays appears inconsistent with the existing formatter contract (math fragments), which is a concrete compile-time issue for the spec docs. Python tooling changes look structurally fine but weren’t executable in this environment.
• spec/expr.typ (array math formatting); secondarily spec/tooling/chip.py for type semantics consistency

Important Files Changed

Filename	Overview
spec/chip.typ	Fixes preprocessed-variable detection to avoid .all() on empty type lookup; otherwise unchanged.
spec/expr.typ	Adds array expression syntax and formatting in code/math renderers; introduces a likely formatting bug in expr_to_math for arrays due to nested math mode delimiters.
spec/src/branch.toml	Updates padding for next_pc_high from scalar 0 to an explicit array expression ["arr", 0,0,0] matching type length.
spec/src/shift.toml	Replaces scalar pad placeholders with explicit array padding expressions for X, Y, limb_shift to match their array types.
spec/tooling/chip.py	Introduces ArrExpr and parsing for ["arr", ...] plus minor formatting; ArrExpr.typecheck returns a Python list but Type alias expects list[Type]

Sequence Diagram

sequenceDiagram
  participant TOML as spec/src/*.toml
  participant ChipPy as spec/tooling/chip.py
  participant ExprTyp as spec/expr.typ
  participant ChipTyp as spec/chip.typ

  TOML->>ChipPy: build_expr(["arr", ...]) from pad/defs
  ChipPy->>ChipPy: ArrExpr.typecheck(env)
  ChipPy-->>ChipTyp: Typed columns/padding used in tables

  TOML->>ExprTyp: expr_to_code/expr_to_math(pad expr)
  ExprTyp-->>ChipTyp: Render padding/defs in spec tables
  ChipTyp-->>ChipTyp: is_preprocessed(var) checks type metadata

Loading

[greptile-apps]

_{5 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

spec/expr.typ
Array math formatter breaks

expr_to_math's new array case wraps the whole result in $...$ even though this formatter already returns math fragments. This will end up nesting math mode delimiters inside an existing math context (e.g. expr_to_math is used inside other $...$ expressions in spec/chip.typ), which causes Typst parse errors.

    "arr": (pp, rec, e) => $[#e.slice(1).map(rec.with(PREC.MAX)).join($, $)]$,

Consider returning a fragment without $...$, e.g. $[#... ] (or build the bracketed list via mwrap(...)), consistent with other cases like "+" and "*".

[RobinJadoul]

Everything compiles fine in typst, and mwrap isn't needed since arrays come with their own non-paren delimiters.
@greptileai

[greptile-apps]

Greptile Overview

Greptile Summary

This PR introduces array expression support to the specification system, allowing array-typed variables to have proper array padding values instead of using scalar fallbacks. The changes add a new ArrExpr type to the Python type checker (spec/tooling/chip.py), update the Typst grammar and formatters (spec/expr.typ), and convert padding values in branch.toml and shift.toml from scalar 0 to proper array expressions like ["arr", 0, 0, 0].

Key changes:

• Added ArrExpr dataclass with typechecking that returns a list of element types
• Implemented array expression parsing in build_expr() matching ["arr", *elems]
• Added formatters for array expressions in both code ([e1, e2, e3]) and math notation
• Fixed bug in spec/chip.typ where .all() was called on potentially empty filtered arrays
• Updated padding values for array-typed variables (next_pc_high, X, Y, limb_shift) to use array expressions

The implementation follows existing patterns in the codebase, properly integrates with the type system, and resolves TODO comments about array handling.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The implementation is clean, well-structured, and follows existing patterns throughout the codebase. The array expression feature adds proper type support for array padding values, replacing placeholder scalar values. The bug fix in spec/chip.typ prevents potential runtime errors from calling .all() on empty arrays. All changes are self-contained, the new ArrExpr class integrates seamlessly with the existing type system, and the TOML updates properly leverage the new functionality.
• No files require special attention

Important Files Changed

Filename	Overview
spec/tooling/chip.py	Added ArrExpr dataclass and array expression parsing support - clean implementation following existing patterns
spec/expr.typ	Added array expression syntax to grammar and formatters for both code and math rendering
spec/chip.typ	Fixed bug where .all() was called on potentially empty array by checking length first
spec/src/branch.toml	Updated next_pc_high padding from scalar 0 to array expression ["arr", 0, 0, 0]
spec/src/shift.toml	Updated padding for X, Y, and limb_shift arrays from scalar 0 to proper array expressions

Sequence Diagram

sequenceDiagram
    participant TOML as TOML Files (branch.toml, shift.toml)
    participant Parser as build_expr()
    participant ArrExpr as ArrExpr Class
    participant Typecheck as typecheck()
    participant Formatter as Formatters (expr_to_code, expr_to_math)
    participant Renderer as Typst Renderer
    
    Note over TOML: pad = ["arr", 0, 0, 0]
    
    TOML->>Parser: Parse padding expression
    Parser->>Parser: Match ["arr", *elems]
    Parser->>ArrExpr: Create ArrExpr(elems)
    
    Note over ArrExpr: Stores list of child expressions
    
    ArrExpr->>Typecheck: typecheck(env)
    loop For each element
        Typecheck->>Typecheck: e.typecheck(env)
    end
    Typecheck-->>ArrExpr: Return list[Type]
    
    ArrExpr->>Formatter: Format for display
    alt Code Format
        Formatter->>Formatter: expr_to_code()
        Note over Formatter: [e1, e2, e3]
    else Math Format
        Formatter->>Formatter: expr_to_math()
        Note over Formatter: [e₁, e₂, e₃]
    end
    
    Formatter->>Renderer: Render in document
    Note over Renderer: Display padding values in tables

Loading

[erik-3milabs]

I would move some of the code (e.g. 7ef1970) to PR271, that is all about type checking, to keep this PR clean & focused on just arrays.
Aside from that, LGTM

[erik-3milabs]

do we not wish to enforce that len(elems) > 0? (though perhaps already on __init__)

[erik-3milabs]

suddenly, this code was moved to #271?

[RobinJadoul]

I must have messed up with the update-refs, because that was absolutely meant to move onto the typechecking only

[RobinJadoul]

Hmm, but 7ef1970 definitely appears as commit on typecheck, so I can only guess it's a problem in github's UI