Current status — 2026-09-02
ACTIVE fixture maintenance / FUTURE site. The website itself is future work. The current obligation is to keep interesting Idriç examples and compiler-stage receipts executable so a later Try Idriç surface does not inherit stale demonstrations.
Purpose
Eventually build Try Idriç, a small website where someone can edit and run Idriç examples and inspect what the compiler understood and produced.
Do not wait for the website to start collecting examples. Treat the examples as maintained compiler fixtures now: they should live with the language, remain interesting, and be exercised continuously so the future site does not become a gallery of stale snippets.
A base branch named try-idric has been cut from the current Idriç branch as the place to begin this work.
Initial examples
Ordinary programs
Keep several small, recognizable examples that answer “what does normal Idriç look like?” before showing unusual type-system or backend work. Candidates:
- print text and a number
- a small record and field access
- a choice with visible branching
- a bounded loop over an array
- parsing a small piece of text
- a constrained value such as
Port_Number / Destination_Port
- a short program that produces an intentionally useful diagnostic
These should not be toy factorial/Fibonacci examples.
Plurality
Preserve an example where plurality belongs to the type rather than to a form renderer:
- one or more values inhabit a plural type
- empty input does not
- a consumer can inspect one versus many without reimplementing the meaning
- the example is general rather than hard-wired to email addresses, though email addresses can be one concrete presentation
High-dimensional rotation
Keep a high-dimensional rotation example because it can expose both mathematical meaning and compiler output:
- the readable Idriç source
- the checked/typed form
- one-step-at-a-time / lowered compiler forms
- final target assembly
- observable result and runtime
Provide a comparison built from a conventional implementation compiled by a standard GCC toolchain. Use an explicitly documented standard algorithm and equivalent inputs. Show:
- relevant compiler/toolchain versions and flags
- emitted assembly, with a focused window in the UI and the full artifact available
- static instruction count (define exactly what is counted)
- code size
- runtime distribution rather than one unexplained number
- warmup, repetitions, target hardware, and timing method
- enough information to reproduce the comparison
Do not present assembly line count as runtime cost. “Assembly steps” must be separated into static instructions and dynamically executed instructions if the latter can actually be measured.
Compiler interface needed by the site
Add or preserve a compiler command/interface that can emit named stages without scraping debug output. The exact spelling can wait, but the contract should support something like:
edric compile example.idric --emit parsed,checked,anf,target-assembly
Each stage should be a complete compiler artifact. The website may show only a small, readable window by default, with expansion/download for the whole artifact.
The parsed view should show how Idriç parsed the submitted source rather than merely echoing it. Diagnostics must remain normal compiler diagnostics, not website-owned reinterpretations.
Continuous checks
- Every published example compiles on its declared backend or explicitly reports SKIP.
- Expected output is checked.
- Intermediate-stage snapshots are deliberate and reviewable.
- Benchmark receipts record hardware and toolchain identity.
- GCC comparison source and flags are versioned beside the Idriç example.
- No silent fallback to a different backend or algorithm.
- Website presentation remains downstream of compiler-owned semantics.
First deliverable
Before designing the full UI, establish an example manifest and a headless command that produces one bundle per example: source, result, diagnostics, selected compiler stages, target output, and benchmark metadata. The later website can render those bundles without becoming another compiler.
Current status — 2026-09-02
ACTIVE fixture maintenance / FUTURE site. The website itself is future work. The current obligation is to keep interesting Idriç examples and compiler-stage receipts executable so a later Try Idriç surface does not inherit stale demonstrations.
Purpose
Eventually build Try Idriç, a small website where someone can edit and run Idriç examples and inspect what the compiler understood and produced.
Do not wait for the website to start collecting examples. Treat the examples as maintained compiler fixtures now: they should live with the language, remain interesting, and be exercised continuously so the future site does not become a gallery of stale snippets.
A base branch named
try-idrichas been cut from the currentIdriçbranch as the place to begin this work.Initial examples
Ordinary programs
Keep several small, recognizable examples that answer “what does normal Idriç look like?” before showing unusual type-system or backend work. Candidates:
Port_Number/Destination_PortThese should not be toy factorial/Fibonacci examples.
Plurality
Preserve an example where plurality belongs to the type rather than to a form renderer:
High-dimensional rotation
Keep a high-dimensional rotation example because it can expose both mathematical meaning and compiler output:
Provide a comparison built from a conventional implementation compiled by a standard GCC toolchain. Use an explicitly documented standard algorithm and equivalent inputs. Show:
Do not present assembly line count as runtime cost. “Assembly steps” must be separated into static instructions and dynamically executed instructions if the latter can actually be measured.
Compiler interface needed by the site
Add or preserve a compiler command/interface that can emit named stages without scraping debug output. The exact spelling can wait, but the contract should support something like:
Each stage should be a complete compiler artifact. The website may show only a small, readable window by default, with expansion/download for the whole artifact.
The parsed view should show how Idriç parsed the submitted source rather than merely echoing it. Diagnostics must remain normal compiler diagnostics, not website-owned reinterpretations.
Continuous checks
First deliverable
Before designing the full UI, establish an example manifest and a headless command that produces one bundle per example: source, result, diagnostics, selected compiler stages, target output, and benchmark metadata. The later website can render those bundles without becoming another compiler.