Loment
EN

Roadmap

What comes next

The versions the project is aiming at, from 0.1.5 onward, and what each of them is for. This is a plan — the shape of the work the project has set itself, not a schedule.

No dates, and nothing here is downloadable. Every line below is a direction the project has chosen; none of them is a commitment to a time, and none of them is a feature you can use today. What you can install is the latest release, and what it contains is on the release history.

The nearest milestone: 0.1.5 Alpha 1

The next thing on the list is not a feature. Its goal is stated as zero silence: every claim the language makes gets either a verdict or a test that could prove it wrong — nothing is described without something that could falsify the description.

The input is a survey of what other languages do well — taken from C, Rust, Java and Python — and the target is that every line of it ends up decided. There are three allowed verdicts: copy the mechanism; copy the intent but not the form; or refuse it outright, and say which conflict it hit and which side was chosen. Three phrases are treated as failure states: "undecided", "to be discussed", and "depending on circumstances" — a line that ends in one of those has not been decided, it has been deferred, and the rule is that deferring counts as failing.

Some of those claims cannot coexist, and the useful part of the exercise is being forced to say which one is being given up, and why. Three of the conflicts are worth naming, because they are the ones this language actually sits on:

How thick is the abstract machine

C is thin enough to allow undefined behaviour, and that thinness is what buys its speed and portability — the language assumes nothing. Rust is thick enough to decide borrowing at compile time, and that thickness is what buys its proofs — the language assumes a great deal. They cannot both be maximised.

Where the intelligence lives

Java puts it in the runtime, and buys peak throughput and simpler operations with it. Loment's reason for existing is a program with no runtime and predictable behaviour. Putting the collector into the core is giving up the thing this language is for — which is why reclamation is a tiered choice rather than a policy.

When a name is resolved

Python resolves at run time: no ceremony, and you write quickly. Java resolves at compile time: reliable tooling and refactoring. The same import cannot both be checked at compile time and not be.

None of those three is resolved by finding a clever middle. Each is resolved by choosing a side and writing down what the other side cost.

What comes after

0.1.5 — reclamation becomes something you can rely on

The reclamation ladder is what 0.1.5 is for: the point at which it stops being a design and becomes a property a program can count on. Most of the ladder is already built — all four rungs have implementations and criteria, the adaptive collector and the generational half have both landed, and the language's two implementations agree on them byte for byte. What 0.1.5 adds is the part that is not a feature: settling it, and being able to say what it does and does not guarantee. The ladder itself is described on its own page, which keeps its own status line.

0.1.5.x — the runtime is finished

The runtime setting already exists, with a default, and it is enforced rather than advisory: asking for the reclamation tier that needs a collector while declaring there is no runtime is a compile error, because the two contradict each other by definition. What the runtime holds today is exactly the part that tier needs. This line adds the rest of it.

0.1.6 — the interpreter arrives in the package

A second way to run a program, at the bottom rung of its ladder. The rungs are already built — T0 through T3 live in the repository, each with a criterion — but none of that is in a distribution yet, and choose vm still changes nothing about what the compiler emits. 0.1.6 closes that gap: the interpreter ships, and that page keeps its own status line.

0.1.7 — the object system is filled out

Today the language has structs, enums whose variants carry a single payload, traits dispatched statically, and generics resolved at compile time. This line fills in what is missing rather than adding something nobody asked for.

0.1.8 — the memory management system is filled out

Which rests on the tiers and the ladder above: reclamation becomes a system rather than a set of mechanisms.

Past 0.1.8 the heads are still in planning, and this page will not invent them. One thing outside this list has been announced separately: the package manager's own next version, which is announced on its own repository.

How you can tell whether any of this happened

A roadmap is only worth reading if there is a way to check it later, so the honest thing is to say where the checking happens. The project does not keep its plans in a public issue tracker. It records them as numbered design documents in the repository, and those documents are written in Chinese — which is worth knowing before you go looking, because the roadmap is not where you would expect it to be.

Each version's arrival is then a matter of record rather than of announcement: the release history says what shipped and when, and each of the pages below carries its own status line rather than describing itself as finished.

Release history What has actually shipped, from the first version to the one being built now. Roadmap on the wiki The same plan in more detail, kept beside the rest of the language. docs/ The numbered design records, where each of these lines is argued rather than summarised. In Chinese. Back to the front page What Loment is, and the two kinds of program it builds.