-
-
Notifications
You must be signed in to change notification settings - Fork 0
Unopinionated Philosophy
λ☶ is a fragment assembler. As such, you as a user are enabled to generate whatever binary file you want. This tool exists to transform data from the provided input to a desired output. The language exists to enable transformation, not judge implementation.
LM provides high-level abstractions that may be familiar from Functional or OOP programming. However, nothing is provided that can't be removed by the programmer. Abstraction is a burden that always needs to justify its cost.
Some features are considered "untouchable" to never be removed entirely. These features are required by the internal compiler infrastructure and can't really be removed without crippling the tool itself. These features have no runtime cost. They are only exposed at compile time.
The most opinionated that λ☶ will ever be is to decide what libraries to support and encourage. Our process is entirely metrics driven and whenever possible we try to quantify opinions. Patterns of code manipulation are only said to be desirable or undesirable when compared against some metric. If you disagree with any design decision, please try to quantify it. This helps move the discussion forward.
The type system also tries to be unopinionated to a certain extent. The language is strongly rooted in the semantics of System F<: with a small extension to support ad-hoc specialization. However, there are several ways to possibly circumvent the type system.
LM is an assembler, with the programmer defining the instruction set at some level. The rest of the toolchain is then built on-top of these low-level building blocks. This does mean that at some level the compiler needs to trust the programmer. This basis of trust is called the "Principle of Nominal Trust" because certain definitions are believed without further verification. One design goal would be to minimize the surface area of this trust, however it would be impossible to completely remove this boundary.
The compiler should be 100% user defined to the capacity of System F<: with Specialization. There may be some small conveniences added (like hygienic macros), but every transformation should be transparent to the user.
Generated object files are 100% configurable. If you have the libraries available, then you can use whatever platform you want. You could even generate non-traditional objects like ChatGPT prompts or MP3s.
A Standard is a set of semantic tests that can be run with doby validate [folder].
A Standard will simultaneously validate a compiler version and associated platform definitions.
The standard library is validated by the standard/lm/v1.0 language standard.
Language standards should have a major and minor version specified, but no development version (the third number).
LM can be run in --standard [version] mode which requires that all features used must be explicitly defined in the standard.
This is not a 100% guarantee that no platform specific bugs would be present, but it can be a useful lint step in a larger build process.
LM is fundamentally an assembler. We strongly encourage static analysis to make sure that you get what you want from your program. Beyond static analysis, LM aims to provide intuitive abstractions that transparently generate the program code that you are looking for. The LM project itself however will only accept security vulnerabilities when "the generated code is surprising." This could be in the nature of overly complex abstractions, strange interactions, or plain old bugs. We welcome all security related communications publicly or privately at your discretion.
The λ☶ source code and documentation are released under the terms of the attached permissive MIT license. This license is intended only to protect the future development of the project while otherwise allowing people to use the code and IP as they would like. Please, just be nice.