Meeting minutes M3 design 2022-10-07

[enikao]

M3 (Meta-meta-model) design

Present: @ftomassetti @markusvoelter @slisson @dslmeinte @enikao

Assumptions

• We support several target languages (Java, TypeScript)
• No experiments - do the same thing as EMF, MPS

Separate Concept and ConceptInterface?

Pro:

• More explicit
• Avoid diamond inheritance problem
• Close to most programming languages

Con:

• Less M3 elements
• Diamond inheritance problem not really solved in MPS

Aspects:

• Could work if ConceptInterface can only contain DerivedFeatures
• Are methods part of M3? => No

Alternative: Only have Concept, allow multiple inheritance from Concept iff at most one of the supertypes has concrete features.

=> Decision: Keep ConceptInterface, can only have DerivedFeatures.
Rationale: Being more explicit simplifies understanding, implementation, and usage.

Derived Features (aka Calculated Features)

To be added to M3

• Part of structure (vs. "behavior")
• Name as identity
• Can be contained in both Concept and ConceptInterface
• Calculated
• Implemented in host language (i.e. there's no way to define Derive Feature semantics in LionWebCore)
• If derived feature with same signature is inherited from several interfaces, need to override it explicitly.

Concept

• flag abstract: alternative name instantiable?

=> Decision: Keep name abstract:
Rationale: Closer to most programming languages

How to resolve references?

We need a way to resolve references we don't know the target of yet.
Examples: Parsed, but not yet linked AST; Targeted part of the model not yet loaded; Dead reference

Assumption: This will not need fundamental M3 changes, but rather adjustments.
Assumption: Will also cover the case of parsed, but not yet linked parse trees.

PrimitiveType and subtypes

=> Decision: Will swap names of Datatype and PrimitiveType
Rationale: Every programming language knows PrimitiveTypes, even though they differ in what they consider primitive (e.g. String in Java vs. JavaScript).
Datatype can be other things than primitive (e.g. records, value types, etc.)

Introduce ValueType?

Pro:

• Different semantics than Concept (identity, atomic etc.)

Con:

• Similar to Concept (want to have features etc.)
  -> Could be special flag "IHaveNoIdentity" on Concept
• Complicates property editors

Aspects:

• Which use cases do they cover?

=> Decision: Don't include for now.
Rationale: No strong reasons to include, can be added later.

Have Enum on M3 at all?

Use cases:

• structured named constants
• named boolean

Pro:

• Nice support in host languages, e.g. switch completeness check
• Present in most M3s

Con:

• Cannot hold additional features
• Bad experience when using them in MPS

Aspects:

• Can be replaced by one specific Concept for Enum, instances for literals in a library
  MPS Example: Concept Visibility, language library contains instances public and private of concept Visibility.
• Can be replaced by AbstractConcept for Enum, Subconcepts for literals
  MPS Example: Concept AbstractVisibility, subconcepts PublicVisibility extends AbstractVisibility and PrivateVisibility extends AbstractVisibility.
• Could be flag sealed on Concept

=> Decision: Remove Enum from M3 for now.
Rationale: Can be represented otherwise; most host languages provide similar support for sealed types as they do for enums.

Ordered vs. unordered Features

Aspects:

• When creating domain models, it's mostly convenient to have ordered features.
• For automatic merging / diffing, explicitly knowing the order doesn't matter is very useful
• Collaborative modeling / distributed data structures can handle unordered collections a lot easier.

Decision: Not explicitly taken => TODO

Multi-valued Reference / Property?

Pro:

• Annoying to add "helper crap" (Smart References, containers for multi-value properties)
• Symmetry to Containment

Con:

• Hard to implement (needs magic node lists etc.)
• We need "helper crap" anyways
• We need multi-valued Containment in any case
• More complicated editors for multi-valued Property

=> Decision: Don't support multi-valued Reference / Property.
Rationale: Good workarounds available, implementation tricky.

Open topics to be discussed on M3

• "Main feature" (as in Intentional Workbench)
• Annotations
• Is M3 a node<>?
• Decide on ordered vs. unordered Features