Language Standards

We are currently working towards a V1.0 LSTS language standard to go along with the V3 compiler makeover.

All relevant approved features are covered by tests in the tests/promises folder.

Exceptions

Error messages are unstable. If something causes an error that is expected, the error-case will be considered stable, however the error message is not stable.

Focus Areas

Well-Defined Memory State

LM-family languages like LSTS are defined by logical operations on memory regions. For this reason the promises are all obsessed with what specific binary values are expected to result from any operation. Implementing this on top of C often means being more precise than C by specifying sizes like int32_t instead of just int. There are also some operations that we truncate to be more reasonable with expectations, such as ~4. One slight exception to this is USize which becomes a U32 or U64 depending on platform configuration.

Well-Defined Program State

One of the high-level goals of LM is to close the gaps where undefined behavior (UB) exists. This turns out to be somewhat difficult to do in general, but we would still like for most common programs to be definable without UB. The UB problem is the schism that separates LM-family languages from ML-family languages, and we are always working to reduce the distance.

Compiler Internals

LM attempts to be a "white-box" project where most internal APIs are made available to anyone. LM is licensed with the permissive MIT license for this reason to allow direct linking or inclusion in other projects. However, this also creates a legacy problem with respect to exposed APIs. With each language standard we also want to publish and document stable API interactions.

Performance

The LM compiler tries to minimize its footprint in memory and cpu usage. This is hard to test, but easy to benchmark, so that is the route that we are taking. These benchmarks are available in tests/benchmarks and include comparisons to other languages such as C, C++, Rust, and ML.

Cleanliness

The LM compiler tries to properly release all intermediate resources after it finishes a task. This is a fairly hard problem, but we are making progress. Some of the promises assert that all resources will be released when disowned.