Generics

[JohannesMeierSE]

• builtin generics
• DSL-specific generics

[JohannesMeierSE]

A sketch done by Mark: https://github.com/TypeFox/typir/pull/1/files#diff-0bd0f4528db84b6cc53a84483d04aa264704111d46b4bc3c4e574ac72641a3e2R1

[aabounegm]

Is there a way to implement type inference for the ternary operator (cond ? expr1 : expr2) without support for generic types in Typir? I cannot find any reference about inferring the type of an expression based on the type of a subexpression in the examples or documentation.

[JohannesMeierSE]

Is there a way to implement type inference for the ternary operator (cond ? expr1 : expr2) without support for generic types in Typir?

Yes, there is a work-around, but it requires to create an operator signature for each argument type to support:

typir.factory.Operators.createTernary({ name: 'ternaryIf', signatures: [
    { first: typeBool, second: typeNumber, third: typeNumber, return: typeNumber },
    { first: typeBool, second: typeString, third: typeString, return: typeString },
    // ...
] }).finish();

You could simplify this with a for loop for all relevant primitive types, but this approach is ugly for e.g. class types.

I cannot find any reference about inferring the type of an expression based on the type of a subexpression in the examples or documentation.

Yes, you are right, the documentation does not describe this yet.
It is possible, since typir.Inference.addInferenceRule(...) supports as argument also the TypeInferenceRuleWithInferringChildren: The main idea is, that 1st inferTypeWithoutChildren returns the AST nodes whose types should be inferred by Typir beforehand. These types are given as arguments to inferTypeWithChildrensTypes as 2nd step, which finally returns the type to infer.
There is an internal application example for function calls in packages/typir/src/kinds/function/function-inference-call.ts.
(Note that this API might be reworked in upcoming versions).

To calculate the return type (#34) might be another idea for ternary operators in general, but this approach is not sufficient for the ternary if here.

[JohannesMeierSE]

A completely different approach is to allow any type in the signature and to add a validation to restrict the supported types, something like this:

const typeAny = typir.factory.Top.create({}).finish();

typir.factory.Operators
    .createTernary({ name: 'ternaryIf', signatures: [{ first: typeBool, second: typeAny, third: typeAny, return: typeAny }]})
    .inferenceRule({
        // ...
        validation: (call, name, operatorType, accept, typir) => {
            typir.validation.Constraints.ensureNodeIsEquals(call.thenExpression, call.elseExpression, accept, (actual, expected) => ({
                message: `The types of the then branch ('${actual.name}') and of the else branch ('${expected.name}') need to be the equal.`,
            }));
        },
    })
    .finish();

Downside for the ternary if is, that the return type is any as well, which makes nesting the ternary if into other expressions difficult.

[aabounegm]

That seems like a valid approach, and perhaps it could satisfy all requirements if the return signature can be a function of the actual inferred parameter types! Though I'm not sure how much of a real use case that has 😄.
Anyway, since I need this for a fun side project (so nothing urgent at all) that will need generics anyway, I guess I will wait for real generics to be implemented

[JohannesMeierSE]

it could satisfy all requirements if the return signature can be a function of the actual inferred parameter types! Though I'm not sure how much of a real use case that has

Yes, that is a real use case and will be supported in the future in #34! Matrix multiplication is another use case, since the return matrix depends on the dimensions of the two input matrices.

Yes, supporting a function for the return type is one idea I have for #34, but it needs to be combined with generics or filters/patterns for the input parameters. Therefore #34 will need some more time to be realized.

I will wait for real generics to be implemented

Same here, the design is under development, but in an early stage ...