Expose a stage-1 .eph -> .wasm CLI subcommand

v1.0.0 ships:

Stage 1 — Idris2 .eph parser, callable from the Idris2 build but not from ephapax-cli.
Stage 2 — ephapax-cli compile-sexpr consumes .sexpr IR.

Missing: a single subcommand on ephapax-cli (or a just recipe) that chains parser -> IR -> wasm so downstream projects can run ephapax-cli compile-eph foo.eph -o foo.wasm in one shot.

Concrete downstream. hyperpolymath/hypatia's build-gossamer-gui workflow currently builds the toolchain successfully (pinned to c14c3e92, cached per-SHA) then skips compilation with a ::warning:: because no chained subcommand exists. The workflow already probes for just compile-affine, ephapax-cli compile-eph, and ephapax-cli compile-affine; whichever name lands first will be picked up automatically.

Suggested shape: ephapax-cli compile-eph <input.eph> -o <output.wasm> (matches existing compile-sexpr naming). Implementation can be a thin shell over the Idris2 parser + the existing compile-sexpr step.

docs(ui): refresh bridge.eph header and rewrite Gossamer lifecycle ar…

ci(gossamer): discover Ephapax CLI binary tolerantly

feat(gossamer): prep for end-to-end .eph→.wasm compile (#196)

ci(gossamer): discover Ephapax CLI binary tolerantly

ci(gossamer): probe `ephapax compile`; name the real upstream gate

feat(gossamer): close remaining #218 items (DataView cache, ipc_recv …

test(gossamer): automate GUI wasm browser smoke (closes #216)

refactor(gossamer): tighten loader + multi-channel IPC + smoke harness (

test(gossamer): automate GUI wasm browser smoke (closes #216) (#220)

Status / scope update (2026-05-13):

After tracing through both parsers against hyperpolymath/hypatia's bridge.eph (the named downstream), the real gate behind this issue is not CLI-subcommand naming — it's the v2 grammar that bridge.eph (and the broader AffineScript→.eph migration) requires. Both parsers currently reject module, import, extern, data, match, and let!:

Rust (src/ephapax-lexer, src/ephapax-parser): grammar accepts only top-level fn and type. Adding a compile-eph clap alias on the existing Compile subcommand would make things worse — it'd short-circuit the hypatia workflow's compile branch (which currently emits a structured ::warning:: about v2 grammar) and replace it with a silent parser error.
Idris2 (idris2/src/Ephapax/Parse/Lexer.idr lines 204-218): keyword list is let, let!, fn, if, then, else, in, region, drop, copy, inl, inr, case, of, type. Same gap.

The parser work is now tracked separately in #43 ("Implement v2 grammar in Rust + Idris2 parsers"), with the concrete production list, AST nodes, typechecker hooks, IR-emit notes, and test corpus laid out. This issue (#36) reverts to tracking only the trivial CLI-subcommand aliases (compile-eph, compile-affine) that should land after #43 — at that point they're a 3-line clap change.

The hypatia workflow's existing probe order (just compile-affine → ephapax compile-eph → ephapax compile-affine → ephapax compile) is already correct: it picks up whichever name materialises first, including the v1.0.0 compile subcommand the moment its parser learns v2.

Recommend: keep #36 open as a stub for the CLI-naming work post-#43, OR close #36 with the new naming work folded into #43's "definition of done". Author's call.

Disposition (2026-05-14)

Closing as folded into #43.

The 2026-05-13 comment on this issue gave two options ("keep #36 open as a stub" vs "close with naming work folded into #43"); having now re-read the codebase end-to-end, the second option is the right one. Reasons:

The CLI-alias work is genuinely a 3-line clap change — there is no separate tracking value in a stub ticket; it will land naturally as part of the v2-grammar PR that makes it useful.
Carrying Expose a stage-1 .eph -> .wasm CLI subcommand #36 open with "blocked by Implement v2 grammar (module/import/extern/data/match/let!) in Rust + Idris2 parsers #43" creates ambiguity ("is this the CLI-naming part of v2? or something extra?") that a single ticket avoids.
Implement v2 grammar (module/import/extern/data/match/let!) in Rust + Idris2 parsers #43 has been re-scoped today to reflect the actual code state (see the new comment there). Its "Suggested ordering" is the canonical roadmap; the trailing CLI-alias step lives at the bottom of that list.

The hypatia probe order in build-gossamer-gui.yml already names compile-eph and compile-affine ahead of plain compile; the moment ephapax-cli grows those aliases (after the v2-grammar work in #43), the workflow picks them up without any change on hypatia's side.

Status update (2026-05-14): Phase A of the blocking #43 landed in #45 — slash module paths + extern "abi" { ... } blocks parse end-to-end at the surface-AST layer. The trivial compile-eph / compile-affine clap aliases still wait for Phase B (typecheck) + Phase C (codegen) — see the phase table on #43 for the sequencing. Once Phase C lands, this issue collapses to a 3-line clap change as the 2026-05-13 comment described.

feat(cli): Phase D — compile-eph / compile-affine aliases (closes #36)

Resolved by #45 — clap aliases for compile-eph and compile-affine land alongside Phases A → C of #43, so the aliases route to working end-to-end compilation (parse → desugar → typecheck → valid wasm) for extern "abi" { ... } blocks specifically. Hypatia's build-gossamer-gui probe order picks them up with no further changes there.

Closing on merge.

feat(cli): Phase D — compile-eph / compile-affine aliases (closes #36) (

Navigation Menu

Repository navigation

Expose a stage-1 .eph -> .wasm CLI subcommand #36

Disposition (2026-05-14)

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Expose a stage-1 .eph -> .wasm CLI subcommand #36

Description

Activity

hyperpolymath commented on May 13, 2026

hyperpolymath commented on May 14, 2026

Disposition (2026-05-14)

hyperpolymath commented on May 14, 2026

hyperpolymath commented on May 14, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions