language: add canonical nan literals and f32/f64 NAN constants

[julia-script]

Status after the refactor

PR #125 completed the target-dependent half of the original issue: usize and isize now expose MAX, MIN, and BITS, with 32-bit/64-bit and engine coverage. That work is complete and is no longer part of this issue.

The remaining work is a source spelling for canonical floating-point NaN values and ordinary standard-library NAN constants.

Current limitation

Silk's decimal floating-point literal grammar cannot produce an IEEE NaN bit pattern. The literal-only constant-initializer rule (SEM0086) also correctly rejects computed or call-based workarounds such as 0.0 / 0.0 and f64.fromBits(...) in a constant declaration.

Runtime NaN values are already possible, so this is API and language-spelling work rather than a blocker for floating-point execution.

Decided design

• Add a dedicated, contextually typed floating nan literal.
• The literal defaults to f64 and becomes f32 in an f32 context.
• It denotes the established positive canonical quiet NaN for the selected width.
• Do not add sign or payload syntax.
• Declare pub const NAN: f32 = nan and pub const NAN: f64 = nan in ordinary standard-library source.
• Do not recognize the standard-library declarations by name in the compiler.
• Keep the literal-only constant-initializer rule; do not introduce general constant evaluation.
• Synchronize the authoritative constant specification with the already accepted target-dependent-constant delta while updating it for nan.

Out of scope

• General constant evaluation.
• User-selected NaN signs or payloads.
• Further target-dependent integer-constant work; PR stdlib: add target-dependent usize and isize bounds #125 completed that scope.

Acceptance criteria

• The lexer/parser and semantic model accept a contextually typed nan literal.
• An unconstrained nan defaults to f64; an f32 context produces f32.
• f32.NAN and f64.NAN exist as ordinary standard-library constants.
• Tests show each constant is not equal to itself.
• Tests assert the positive canonical quiet-NaN bit pattern for each width.
• The evaluator, native LLVM backend, and direct Wasm backend agree.
• The OpenSpec/main specification records the literal and synchronizes the target-dependent constant rules.
• SEM0086 continues to reject non-literal constant initializers.

[julia-script]

Decision: two narrow features — and the caveat checked out, so NAN is not blocking

Decided by Julia, 2026-08-13, answering the mechanism question in the body.

Two narrow features, not one general mechanism. Rationale, for the record:

• The two cases are different problems. usize/isize is target selection — the compiler already knows the pointer width, nothing is evaluated, it only picks which literal applies. NAN is spelling — a bit pattern the decimal float grammar cannot reach. Describing both as "constant evaluation" generalizes past what either needs.
• General const-evaluation does not have a natural stopping point. "What may appear in a constant initializer — calls? which calls? loops?" is the question that made constexpr and const fn multi-year features elsewhere. That is a large surface to open in order to name one constant.
• SEM0086's one-literal rule is currently load-bearing. stdlib: Add MAX, MIN, EPSILON, BITS, PI, and INFINITY constants #38 cited it as the reason its workarounds were unavailable, which is a constraint doing its job. Relaxing it is also the irreversible direction: narrow features leave general evaluation available later, but once initializers accept expressions, code depends on that immediately.

The NaN caveat — measured, not assumed

Probed against the built compiler on main at d3491e6. A NaN is obtainable at runtime, two independent ways, with zero diagnostics and no trap:

fn probe(zero: f64) -> i32 {
  let quotient = zero / zero
  if quotient == quotient { return 1 }
  return 42
}
pub fn main() -> i32 { return probe(0.0) }

→ Completed(42) — the value is not equal to itself, so it is a NaN. Float division by zero does not trap.

The same holds for probe(1e999) with big - big (infinity minus infinity) → Completed(42).

Consequence: the SEM0086 one-literal rule bans 0.0 / 0.0 only as a constant initializer. As a runtime expression it is fine. So:

• f64.NAN is ordinary API convenience, not a prerequisite. stdlib: Add sqrt, abs, floor, ceil, round, pow, and log #41's canonical-NaN acceptance criterion can be written today with a runtime NaN, and stdlib: Add sqrt, abs, floor, ceil, round, pow, and log #41 is therefore not blocked by this issue at all — correcting what I recorded on stdlib: Add sqrt, abs, floor, ceil, round, pow, and log #41 earlier.
• Only the usize/isize half is on the critical path, and it is the half self-hosting actually needs.

Revised plan

1. Target-dependent constant declarations — usize/isize MAX/MIN/BITS, value selected per target at specialization. This is the blocking half; it ships first.
2. A NaN spelling — a separate, lower-priority follow-up. NAN should exist as public API (Rust, Zig and C all have it), but nothing waits on it.

The acceptance criteria above should be split along that line when the work is dispatched.

---

Generated by Claude Code

[julia-script]

Triage review — 2026-08-13

Verdict: Correct but needs refinement
Priority: keep existing

The issue is now half implemented. PR #125 merged the target-dependent half: packages/compiler/src/TargetConstant.ts defines the closed pointer-width selectors, packages/compiler/stdlib/silk/usize.silk and isize.silk expose MAX, MIN, and BITS, and packages/compiler/test/TargetDependentConstants.test.ts contains 32-bit/64-bit and engine acceptance coverage.

The NAN half remains real. Neither f32.silk nor f64.silk declares NAN, and packages/compiler/test/NumericConstants.test.ts explicitly records that absence because no decimal literal can produce the required nonzero NaN payload. The existing decision comment already separates target selection from NaN spelling, so keeping both under one unchecked acceptance list would incorrectly ask future work to redo shipped behavior.

This issue remains actionable only for the NaN spelling. Refine or split it so the remaining work charters one narrow, spec-backed NaN representation and tests its non-reflexive behavior and canonical bits; treat the pointer-width criteria as completed by #125. I did not rerun the existing tests.