Object‐Oriented Programming

LM may seem at first to be object-oriented to a great extent. This is half intentional and half subtly incorrect. LM has no object model, unless you are referring to categorical objects. LM has no class model, unless you are referring to set-theoretical classes. LM has no inheritance model, unless you make one.

LM is just an assembler with some mathematical abstractions. If an abstraction is not able to model the entirety of its domain, no more no less, then it should be corrected in that.

What does LM natively support?

LM supports discriminated or undiscriminated structs and unions. This may look like an inheritance model at first glance, however it is truly only a data representation. The standard inheritance "Diamond Problem" is a good example that demonstrates the difference.

The Diamond Problem is an inheritance problem where a class becomes the subclass of two conflicting superclasses. This is considered a hard error in many languages.

    A
   / \
  B   C
   \ /
    D

In LM all subtype relations can be expanded into plural type notation.

A
A+B
A+C
A+B+C

In this case all type signatures and representations are unambiguous so there is no error here. Possibly there could be some unresolved ambiguity in method resolution but that is a separate issue.

What does LM support?

Here are some Object-Oriented features that are supported either directly or indirectly.

• Object Subtyping (as long as the memory layout is sound)
• Runtime Types (a runtime Type can be modelled as a Proposition against a static Type)
• Aspect-Oriented Programming (specialization is a natural way of addressing Cross-Cutting Concerns)

What does LM not support?

LM as a holistic project will reject features that do not model the entirety of their domain. LM attempts to provide mathematical abstractions, not opinionated abstraction. If you want opinionated code then build a frontend for it.

Specifically Rejected Features

• This list will be expanded as needed