Skip to Content
i documentation
Contributing

Contributing

Find the sources, checks, and principles for changing i.

These pages are for programmers changing the compiler, the standard library, or the documentation. They explain where to work, how a program reaches the host, and how to check a change against the language definition.

The project aims to be a complete standalone language with a useful standard library. It keeps the language small: there are no keywords, every value and binding is immutable, and no library is special to the compiler. Concurrency is structured: a task belongs to a scope and cannot outlive it. Services and tests use general language features. Simplicity matters; the philosophy of the project comes first, optimisation second.

The goal is that a program never passes the checker and then traps at run time because the checker accepted an invalid program. This is not yet true: the known gaps record a checked program that traps as well as other differences from the standard. A specified stop is a separate outcome defined by the language.

The standard is the definition. It says that a compiler or program that does not keep to it is wrong, and that the present compiler does not yet implement everything in it. Read the relevant section before changing behavior.

Where help is wanted

The known-gap register gives concrete conformance tasks. Start by reading the cited spec paragraph and writing a regression case:

AreaRecorded work
Tasks and continuationsC03: remove a captured scope from the caller’s chain correctly; C04: retain only the environment needed by a captured computation.
PatternsP13: implement data-rest patterns and their unique-known-shape check; P15: report never-used branches in the recorded coverage cases.
Services and resourcesEF10: implement the specified row projection; EF11: implement the specified resource scope lifecycle and API. These are gaps, not available APIs.
TypesT12: normalize unequal invariant intersections to Never; T13: recognize impossible data consistently; T14: reject non-hole arguments on the right of a written difference; T15: retain invariance for unused labelled-type parameters; T16: check well-formed type applications; T23: check written polymorphic function types inside data.
Text and macrosSX16: make negative Float inspection produce the specified spelling; MP08: charge macro work and frames according to source-level rules.
SoundnessT8/F2: prevent a relaxed written type parameter from giving an invalid known result type to callers. Whether written parameters should instead be rigid remains open.

The register names external review probes, not fixture paths in this repository. It says each probe should become a regression case when its gap is implemented. Do not assume there is already a case to update.

Documentation has a concrete starting point too: the site landing page still contains placeholder introductory copy. The library-page generator also has fallbacks for missing source documentation. Improve the source documentation rather than editing generated pages.

See also