Make it easier to switch between curried and multi-argument function calls in the IR #60
Replies: 2 comments
-
There's other value nodes besides |
Beta Was this translation helpful? Give feedback.
-
This didn't come up as an issue with the existing tooling we have in Elm because we were able to move the translation to a common function and use it across the codebase: So a different way to look at the problem is from the perspective of sharing this functionality. To share this functionality we have 2 options:
The latter is usually not feasible but luckily the Morphir IR was built for this exact purpose. This means that if we model the transformation using the Morphir IR we can share it across languages. Wait, we already did that since the logic above is in Elm! So the conclusion is that we can have this functionality available in any of our backends without too much effort which means that anyone using the Morphir IR through generated APIs in our supported languages (Scala, TypeScript) will have access to the uncurry logic. |
Beta Was this translation helpful? Give feedback.
-
The Morphir IR currently encodes all function invocations with an
Apply
node that has a single argument. Multi-argument function calls are encoded using currying. Here's the definition in the IR:This is a very elegant and scalable approach which makes certain tasks like type inference and evaluation cleaner but it also adds complexity to backends that translate to languages with no direct support for currying because they all need to translate the nested
Apply
nodes into a single multi-argument call.We should find a way to avoid duplicating the conversion between curried and multi-argument function calls across various backends.
Beta Was this translation helpful? Give feedback.
All reactions