Initial draft of the type system API

[msujew]

For anyone who wants to see how this API is supposed to look like. I will accept feedback on the API direction and then start implementing the library.

[trusktr]

Can we see the proposal of what is being implemented somewhere? Or is it all in code only so far?

[msujew]

@trusktr I've created an internal document that shows potential usage of this API before I started working on this. Note that the API has changed a bit while developing this PR, but the main ideas are still there.

```ts // A typed function that initializes a whole generic type system // Every type has a `literal` that can be seen as its "source" // We clarify that each literal is of type `AstNode` const typeSystem = createTypeSystem(); // primitives const stringType = typeSystem.primitive('string'); const numberType = typeSystem.primitive('number'); // Create an `any` type and set is as the top type of the type system const anyType = typeSystem.primitive('any').top(); // operators const plus = typeSystem.operator('+'); // the 'operate' function returns a `Disposable` // In case we allow user-contributed operator overloads, these need to be deleted at some point plus.operate({ operands: stringType, result: stringType }); plus.operate({ operands: [stringType, numberType], order: 'flexible' // 'strict' would mean that number + string would not be valid here result: stringType }); // plus.operate({ operands: [stringType, anyType], result: stringType, priority: -1 }); // classes, structs, interfaces // These structures are classified as "categories" const classType = typeSystem.category('class'); const interfaceType = typeSystem.category('interface'); const structType = typeSystem.category('struct'); classType.assignable(classType, (from, to) => { // This is likely the default implementation for any complex type structure // This will likely be exposed as `defaultNamedAssignability` if (from.literal === to.literal) { return true; } if (from.super.some(e => typeSystem.isAssignable(e, to)) { return true; } return false; }); classType.assignable(interfaceType, defaultNamedAssignability); structType.assignable(structType, defaultNamedAssignability); structType.assignable(interfaceType, defaultNamedAssignability); interfaceType.assignable(interfaceType, defaultNamedAssignability); // In addition, the library also exports a `defaultStructuralAssignability` function // This allows for example for a fully structural type system (such as TypeScript) or a partially structural type system // Such a type system can for example use named assignability for classes, while using structural assignability for interfaces // These types can then be specialized to create their class/struct/interface instances const classInstance = classType.get(classLiteral); // `classInstance` is an disposable instance of the type system. // It features the same API and can be used to implement more complex type behavior // This is an example of a user defined implicit casting function // Like most things, it returns a disposable classInstance.assignable((from, to) => { return typeSystem.isAssignable(implicitCastingType, to); }); // Example of a user defined explicit casting function classInstance.castable((from, to) => { return typeSystem.isAssignable(explicitCastingLiteral, to); }); // Complex type instances can also be generic // We first have to define the type parameters const genericSimpleType = typeSystem.typeParameter({ name: 'T'; }); const genericConstraintType = typeSystem.typeParameter({ name: 'T2', // A constraint if effectively just a function with (Type) => boolean // The type system object provides a few default constraints (such as `extends`) contraints: [ typeSystem.extends(someClassLiteral) ] }); const genericInstance = classType.get({ literal: classLiteral parameters: [genericSimpleType, genericConstraintType] }); // The generic types can be accessed using the `genericInstance` const typeParameters = genericInstance.typeParameters // A generic class can be specialized with type instances const genericInstanceWithArguments = genericInstance.typeArguments([ T1Instance, T2Instance }); // Language validators need to assert that T2Instance fits the constraints typeSystem.assertConstraints(typeParameters[1], T2Instance); // All types can have members // push also returns a disposable // This allows to declare partial classes or extension functions/properties // And also remove them on an update of their declaring document/class classInstance.members.push(...members); // Delegate types const delegateInstance = typeSystem.delegate({ // names are usually optional throughout the whole type system // The type system needs to support inline types name: '...', literal: delegateLiteral, parameters: [], returnType: ..., generics: [] }); // Union types const unionInstance = typeSystem.union({ literal: unionLiteral, generics: [ /** can also support generics */ ] }); ```

[JohannesMeierSE]

Here are my general thoughts about this API proposal:

• I am thinking of splitting the "type graph" (as mentioned by Ben above) and functionalities working on the type information. Maybe, we could apply the "service-oriented" design of Langium here as well. That would ease to exchange, configure and replace implementations depending on customer needs.
• Additionally, we could separate higher-level features (e.g. isAssignable) and lower-level algorithms (e.g. getCommonSuperType) for better reuse and customization.
• I propose to integrate at least one simple application example for the API as early as possible and directly into the source code, e.g. the pasted code snippet or another simple application.

Some more things we probably need:

• functions to produce nice error messages
• a nice API for ..., depending on the customer's DSL:
  • mapping terms/expressions with types
  • relating types to each other, e.g. sub/super types