Describe the bug
The morphir-elm based interpreter frequently fails to work with first class or higher order functions; in particular, it reliably fails whenever a first class function relies on anything from lexical scope.
To Reproduce
The following code works in native elm:
type MyEnum = TwoArg Int Int
unable_to_compute : Int -> MyEnum
unable_to_compute x =
let
inner =
let y = 5 in \z -> TwoArg y z
in
inner x
wrong_result : Int -> MyEnum
wrong_result x =
let
inner = TwoArg 5
in
inner x
In the morphir-elm interpreter, "unable_to_compute", as the name would imply, is unable to be computed. "wrong result" meanwhile ignores its input argument and results in "TwoArg 5".
Expected behavior
I would expect the behavior to match elm, with first-class functions maintaining locally scoped variables.
Desktop (please complete the following information):
Describe the bug The morphir-elm based interpreter frequently fails to work with first class or higher order functions; in particular, it reliably fails whenever a first class function relies on anything from lexical scope.
To Reproduce The following code works in native elm:
In the morphir-elm interpreter, "unable_to_compute", as the name would imply, is unable to be computed. "wrong result" meanwhile ignores its input argument and results in "TwoArg 5".
Expected behavior I would expect the behavior to match elm, with first-class functions maintaining locally scoped variables.
Desktop (please complete the following information):
Additional context This may be relevant to the morphir-scala discussion on RTValue, MDM and IR at https://github.com/finos/morphir-scala/discussions/529