Split inference rules #5
Conversation
| @@ -34,27 +34,33 @@ export function createTypir(domainNodeEntry: AstNode): Typir { | |||
| } | |||
| } | |||
|
|
|||
| // extract inference rules, which is possible here thanks to the unified structure of the Langium grammar (but this is not possible in general!) | |||
| const binaryInferenceRule: InferOperatorWithMultipleOperands<BinaryExpression> = { | |||
| filter: isBinaryExpression, | |||
There was a problem hiding this comment.
AS already discussed, this is very Langium-specific. Having one filter function could be enough. You could create a isNumericOperator for +,-,* and /. Maybe even bind this to the name first.
const isNumericOperator = operator.createBinaryOperator(['+', '-', '*', '/'], (node, name) => isBinaryExpression(node) && node.op == name));
//returns also "node is BinaryExpression"
const inferenceRule = operators.createExpandRule(isNumericOperator, node => [node.left, node.right]);But I also see that you cannot reuse it like you did... it is weird somehow to uncouple from the operator name.
I think we need to be careful what mix with what. It is confusing to see the inference rule in you example being used for <, and for +. What is an "inference rule"? Does it make sense to call it like this here? For me this feels confusing, because you say you infer something to grasp a type information, but on the other side you are splitting a node into child nodes...
There was a problem hiding this comment.
Well, the operands are required for inference, since in case of overloaded operators/functions, the types of the operands need to be checked.
On the other hand, filter, match and operands are used for validations as well, since the assigned values to these operands need to respect the declared types of the operands.
I totally agree, the names and the design of the "inference rules" is still unclear!
Contributes a refactoring for inference rules of operators and functions: