Boxed Float (IEEE 754 f64) type

[boldfield]

Summary

• Add Float as a boxed IEEE 754 f64 type following the Int64 boxed-scalar pattern
• Header constant TAG_FLOAT = 0x0B, 21 runtime FFI primitives (arithmetic, comparison, math, conversion)
• Float literal syntax in lexer/parser (3.14, 1e10, 2.5e-3), type system integration, full codegen wiring
• float_to_string always includes .0 for whole numbers (e.g., 4.0 not 4); inf/NaN unchanged
• 10 e2e tests + runtime unit tests covering the full surface
• spec/language.md updated: Float in literal syntax, type table, expression forms, stdlib reference, runtime model; removed from v1 limits

Key design decisions

• ABI: sigil_float_box accepts i64 bit pattern (not f64) to stay in Cranelift's integer register class — codegen uses f64::to_bits() as i64 → iconst(I64) → call
• Division: IEEE 754 semantics (div-by-zero → ±Inf, not abort)
• float_to_string formatting: appends .0 to whole numbers so Float values are always visually distinct from Int

Test plan

• 10 e2e tests: literals, arithmetic, negation, div-by-zero→inf, from_int round-trip, comparisons, floor/ceil, string parse/validate, NaN≠NaN, doc-only import
• Runtime unit tests: boxing, arithmetic, comparison, math, conversion, to_string formatting (3.14, 4.0, inf, NaN)
• Full workspace test suite passes (330/330; 3 pre-existing perf-floor flakes excluded)

Implements plan: 2026-05-05-sigil-float.md

🤖 Generated with Claude Code

[boldfield]

Code Review: Boxed Float Type

Clean implementation that mirrors the established Int64 boxed-scalar pattern. Correctness looks good across all layers. A few issues worth addressing:

Issues

1. Lexer: greedy exponent consumption produces misleading errors

The exponent branch (line ~164 of lexer.rs) unconditionally consumes e/E and an optional sign without verifying that exponent digits follow. Input like 1e or 1e+ gets consumed and then fails with "float literal 1e is out of range" — but it's not out of range, it's malformed.

A simple fix: peek ahead for at least one digit before committing to the exponent parse. Otherwise, leave the e unconsumed and treat the preceding part as an integer literal. This matters because .sigil source with a typo (1e) currently eats characters that belong to the next token and gives a confusing diagnostic.

2. Dead code in codegen: make_float_binop takes unused name parameter

let make_float_binop = |name: &str, sig_holder: &mut Signature| {
    // ...
    let _ = name;
};

The name parameter is immediately discarded. The closure doesn't need it — drop the parameter.

Observations (not blocking)

• float_to_int clamping is redundant with Rust's saturating as semantics (f64 as i64 already returns 0 for NaN, i64::MAX for overflow, i64::MIN for underflow since Rust 1.45). The explicit checks make the contract more visible to readers though, so not wrong — just worth knowing that removing them wouldn't change behavior.

• "Plan D" comments appear throughout the codegen additions. The PR summary and branch name suggest this is a Plan C continuation (Float type for the Sigil language). If "Plan D" is intentional naming, ignore this — just flagging potential naming drift.

Verdict

Solid work. The lexer exponent greediness is the only thing I'd want fixed before merge — it'll bite someone debugging a typo in float-heavy code and getting a confusing diagnostic. The dead parameter is a one-line cleanup.