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 the language standards we also want to publish and document stable API interactions.