[arithmetics example] incorrect evaluation when number is used as a function

[sorawee]

Langium version: the one that runs on https://langium.org/showcase/arithmetics/
Package name: the one that runs on https://langium.org/showcase/arithmetics/

Steps To Reproduce

Run the code provided below in https://langium.org/showcase/arithmetics/

Link to code example:

Module basicMath

def sqrt(x):
    x(2);

Sqrt(81);

The current behavior

Passes validation, and evaluates to 81.

The expected behavior

This should really fail validation because the language's grammar doesn't permit higher-order function, so any parameter used at the function position is definitely incorrect. But it doesn't fail the validation. In fact, the grammar explicitly permits it for an unknown reason.

On evaluation, it also simply returns the parameter, discarding 2, which also seems wrong

[montymxb]

Hey @sorawee 👋 , thanks for the catch there! Looks like we're missing that very validation. Would you be interested in adding it in by chance?

[sorawee]

Hi @montymxb !

I'd love to contribute, but I don't know what's the preferred approach. One possibility is to remove AbstractDefinition in the grammar file entirely, and have func link to Definition directly. However, since it seems like AbstractDefinition was intentionally created and I don't understand why, so I don't feel comfortable making changes there.

[montymxb]

Hey again!

There's a couple ways to go about it. One would be to modify the grammar since AbstractDefinition seems to have been added for some reason that never materialized (maybe passing functions was considered at some point 🤔 ).

However, for this one it would be great to have an additional validation that emits an error when the func property of a FunctionCall (which is an AbstractDefinition) isn't actually a function def. In that case evaluation shouldn't proceed as well due to the emitted error diagnostic, fixing both issues.

You can check out the checkMatchingParameters validation inside the arithmetics-validator.ts. Here it would be pretty helpful to add an additional check to ensure that the func property has the correct type. Something like the isDefinition type guard from the generated ast.ts import should do the trick.