Community Guidelines

The LM community aims to be inclusive, but not smothering or over-bearing. When you are ready to interact with the larger community, here are some guidelines to set you up for success.

Respect Each Other And Each Others Time

LM is a loosely knit community. In such a diverse community it is important to set expectations to prevent us from wasting each others time. The most important resource in the LM community is the community members. Please try to be respectful of others and expect others to be respectful of you.

Fair Interactions

LM Core aims to create an environment where all stakeholders can build and thrive.

LM aims to provide a compiler backend that addresses the NxM problem of language frontends vs language backends. The LM project is written in LSTS, but we try to avoid favoritism towards that language. Similarly the LM project currently depends on an ANSI C backend and Posix APIs, but we try to limit the effect of those dependencies. LM aims to be nothing more than a fast well-typed macro assembler built on top of the logic of System F<: with Specialization.

When proposing to add support for a new frontend or a new backend, please consider:

• who is going to write the new plugin?
• who is going to maintain the new plugin?
• does the plugin even need to be hosted inside the LM Core project? (can it live in an independent project?)
• does the plugin require a code-commitment as to how things are structured inside LM Core?
• what LM features does the plugin depend on?
• what LM libraries does the plugin depend on?

When moving forward with a new plugin:

• make sure that there are regression tests that cover the feature and library dependencies

Unlike [Net]Script

JavaScript was the first programming language to become widely adopted on internet browsers. While JS was being developed there was a corporate arms-race to add features but also to break the competitors interpreter. This mine-laying and sabotage created the often unfortunate feature set that we now call ECMAScript.

If LM contributors were transported back to that time, we may not be sure what to do differently. However, we are here now, and on friendly terms; so let's build something nice together.

What history has taught us moving forward is that corporations like to deliberately break stuff that may be of use to their competitors. Herein lies one of the fundamental technical contributions of LM, which is an ability to "mine sweep" effectively. Diverse tools and architectures create arbitrary hurdles to software development. LM provides the ability to declare architecture-specific concerns without burdening other programmers with more tedium or pain.

Code > Commentary

In order to encourage a developer mindset, sometimes collaborators may be asked to provide a working example of a proposed feature or change. These "development" branches may potentially fail or be rejected during further discussion; that is OK.

For example, an early development change considered using only SmartStrings inside the compiler instead of CStrings. This had an unexpectedly severe negative performance impact, so the changes were abandoned. This outcome was not foreseeable until the code was already written.

The "Code > Commentary" principle is intended to prevent language designers from becoming detached from reality, which can easily happen if we are not careful.

"Personal Canon" Standardization

Instead of deferring to one specific source of authority to determine what is or is not standards compliant, LM encourages a "personal canon" approach. When considering whether something is standard, ask yourself whether it should be, and then go with that determination. The community "standard" exists explicitly to support the widest variety of personal canons.

No Fiefdoms

Once an organization starts to grow past a certain modest size, it is natural for hierarchies to start to form. Some take this opportunity to create an elevated position for themselves with "serfs" below them to do the actual work. LM attempts to reject these power structures, and will give equal authority to all contributors. That said, this is a chaotic project, and equal authority might not amount to much.

In practice what this means is that "upstream" or "downstream" is not explicitly set by the community. You are currently reading from "andrew-johnson-4/lambda-mountain" because this is my personal branch. I don't claim any right over other forks beyond simple attribution and non-liability from the MIT License. Everyone is welcome and encouraged to fork, rewrite, or obliterate anything here and turn it into a very different project. When these changes are shared, I might like some of the new abstractions, and proceed to adopt those back into this codebase.

When streams or rivers "fork" it is also common for them to merge again downstream.