Prose: render comparison calls infix (incl. float_* mapped to same operators) #26

New Issue

2026-05-21T10:06:51+02:00

Brummel commented

2026-05-21 10:06:51 +02:00

Prose (Form-B) currently renders class-method comparison calls as prefix:
eq(a, b), gt(i, stop). Make them infix for human readability:
a == b, i > stop. Pure syntactic rewrite in the prose printer — no
type information needed.

Mapping (class-method dispatch):

eq → ==, ne → !=
lt → <, le → <=, gt → >, ge → >=

Float (no class instance — see operator-routing-eq-ord milestone):

Prefix float_eq(x, y) in prose is unacceptable for human readability.
Float comparisons must also render infix, mapped to the same
operators as the class-method counterparts:

float_eq → ==, float_ne → !=
float_lt → <, float_le → <=, float_gt → >, float_ge → >=

Open question for the brainstorm — load-bearing for accept/reject:

Does collapsing float_eq(a, b) and eq(a, b) to the same prose
a == b lose information that downstream LLM back-propagation needs?
Prose is lossy-by-design (docs/PROSE_ROUNDTRIP.md) and the roundtrip
is LLM-mediated, but float_eq vs eq carries a real semantic
difference (NaN handling, no class instance, no NoInstance diagnostic).

Empirical test required before shipping: take a prose corpus exercising
both forms, run roundtrip back to Form-A via LLM, measure whether the
LLM picks the correct named function from contextual type info (float
literals, declared parameter types). If the recovery rate is too low,
the prose printer needs a disambiguating cue (e.g. trailing comment,
distinct operator like ==./<., or a typed-context hint).

Form-A is unchanged. Still (app eq a b) / (app float_eq x y),
canonical and hashable. Only the prose projection changes.

Scope:

crates/ailang-prose/ — printer rewrite
docs/PROSE_ROUNDTRIP.md — document the lossy infix mapping +
the float_* collapse decision once the empirical test resolves it
Existing .prose.txt fixtures — regenerate

Prose (Form-B) currently renders class-method comparison calls as prefix: `eq(a, b)`, `gt(i, stop)`. Make them infix for human readability: `a == b`, `i > stop`. Pure syntactic rewrite in the prose printer — no type information needed. **Mapping (class-method dispatch):** - `eq` → `==`, `ne` → `!=` - `lt` → `<`, `le` → `<=`, `gt` → `>`, `ge` → `>=` **Float (no class instance — see operator-routing-eq-ord milestone):** Prefix `float_eq(x, y)` in prose is unacceptable for human readability. Float comparisons must also render infix, mapped to the **same** operators as the class-method counterparts: - `float_eq` → `==`, `float_ne` → `!=` - `float_lt` → `<`, `float_le` → `<=`, `float_gt` → `>`, `float_ge` → `>=` **Open question for the brainstorm — load-bearing for accept/reject:** Does collapsing `float_eq(a, b)` and `eq(a, b)` to the same prose `a == b` lose information that downstream LLM back-propagation needs? Prose is lossy-by-design (`docs/PROSE_ROUNDTRIP.md`) and the roundtrip is LLM-mediated, but `float_eq` vs `eq` carries a real semantic difference (NaN handling, no class instance, no NoInstance diagnostic). Empirical test required before shipping: take a prose corpus exercising both forms, run roundtrip back to Form-A via LLM, measure whether the LLM picks the correct named function from contextual type info (float literals, declared parameter types). If the recovery rate is too low, the prose printer needs a disambiguating cue (e.g. trailing comment, distinct operator like `==.`/`<.`, or a typed-context hint). **Form-A is unchanged.** Still `(app eq a b)` / `(app float_eq x y)`, canonical and hashable. Only the prose projection changes. **Scope:** - `crates/ailang-prose/` — printer rewrite - `docs/PROSE_ROUNDTRIP.md` — document the lossy infix mapping + the float_* collapse decision once the empirical test resolves it - Existing `.prose.txt` fixtures — regenerate

Brummel added the feature label 2026-05-21 10:06:51 +02:00

Brummel referenced this issue

2026-05-21 10:07:21 +02:00

Rename arithmetic operators to named functions (add/sub/mul/div/mod/neg) #27

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/AILang#26