Define language for Typesystem as derived model

[enikao]

We need to calculate the type of a node in several contexts, including validation (e.g. "do the types of these assigned nodes match?") and scoping (e.g. "which members does the thing on the left side of the dot have?").

[dslmeinte]

I think there's a language hierarchy here. I wrote some things up in the context of computation of constraints: let's see whether we can get through enough of the agenda to also table that?

[joswarmer]

@dslmeinte Please explain, I cannot place language hierarchy in the context of this question.

[dslmeinte]

The general text I wrote is below, but I need to put it in a good spot in the specification repo still, through a PR.

---

A constraint conceptually consist of the following data:

• A concept, i.e. instance of the LionCore Concept.
• A logical condition that evaluates to a Boolean (or Unknown) value. It does so having access to an it which is an instance of the given concept, and possibly additional values such as root, model, etc.
• A template for a message that's produced as an issue.
• (optionally:) A function that returns (a Boolean or Unknown) whether the problem can be fixed automatically, and a method (/function) that does that.

For every node in the model, do the following:

• Filter all constraints whose stated concept matches or is a supertype of the node's actual concept.
• Of those constraints, evaluate the logical condition.
• Whenever a constraint's logical condition evalues to false, produce an issue using the constraint's message template.

Note: constraints that check cardinality defined in the language's M2 are generic, and should not have to be stated explicitly.

In practice, it might be advantageous to allow expand the notion of a constraint as follows:

• Add computation of temporary, computed values, i.e. values necessary for evaluating the constraint that are not reused anywhere else, so shouldn't a computed feature.
• Add possibility of emitting multiple issues per constraint.
• Add constructs specifically for finding duplicate names, and emitting one issue per duplicate (so multiple issues per constraint). This is more efficient than evaluating “from \<node i>, gather all nodes with the same name" for many nodes separately, and can produce more useful issue messages.

A constraint checker is a language service that, given a model and a collection of constraints, executes all constraints on every node in the model, and reports back violations in the form of a derived model consisting of issues.

Typical examples:

• Uniqueness of names within a certain scope.
• Type matching (e.g. assignability).
• Checking that “things match up” on either side of a reference, e.g. checking for a “path expression” such as <entity>.<property> that <property> is indeed a feature of <entity>. (Such things are often done through scoping, but that doesn't necessarily produce very meaningful issue messages.)

A language architecture for constraints could look as follows:

• An expression language(*) for expressions that can access nodes and their details, and navigate over links (containments/children, references) - this is the “large bit”!
• A language(*) to define computed features that augment a language.
• A language(*) to define types and their relations (assignability, etc.).
• A language(*) to define type computation/derivation. (In practice, virtually all type computations can be done directly, without infering anything using solvers or such.)
• A language(*) to express a template for a textual message.
• A language(*) to define constraints.

(*) Either as a full-blown external DSL, or through an existing programming language with suitable support in the form of a library/framework/internal DSL.

This represents the ideal / the royal way / the point on the horizon, but is quite unrealistic to achieve in the short to middle-long run - at least, in the context of being an effort that happens “purely” within the LionWeb group.

In theory, KernelF would be a great fit as an expression language. In practice, its implementation (its type system, specifically) is quite MPS-specific. This would eventually warrant coming up with a “new KernelF” that's defined in a technology-aspecific way - e.g. using LionWeb for the M2s. Implementing an interpreter as a reference would be good enough. Generating code would probably be more performant, although using GraalVM might prove a helpful here as well.

An expression language would encompass a number of separate aspects:

• Primitive values (literals).
• A uniform way of expressing literals, especially array- and object-like literals.
• A uniform way to connect to definitions of structured data, such as a data model, or object types. Essentially, entities and their properties. With that: access to structured data.
• Binary operations: arithmetic, comparison.
• String manipulation - upto, and possibly including, templating.
• Conditionals/branching - if then else, switch/match/when.
• Array/collection-like functions: map, filter, groupBy, etc.
• A way to express unknown values - to be able to do partial evaluation.

[enikao]

I think there are different understandings of this language: This language is used to send calculated types of nodes as derived model over the wire. It is not meant to describe the rules how to calculate a type.

Example: Assume the language discussed here is called LionWeb-typesystem.

We have an original model that contains something like MPS' BaseLanguage. Node with id 123 is of concept MethodDeclaration. If we ask for the derived model of node 123 for LionWeb-typesystem, we might get back a node of concept UserDefinedType with some features like name=List, baseType=->java.util.List, collection=true.

So LionWeb-typesystem only contains concepts to describe UserDefinedType, PrimitiveType, EnumType (or something similar). It does not say anything how a processor would calculate that type based on the MethodDeclaration instance with id 123.