Static vs. dynamic linking for Morphir IRs

[AttilaMihaly]

We recently added a feature to Morphir that allows you to have dependencies across different IRs. It's a very minimal solution but it allows you to have references in your Elm code to other Morphir models, specify their IR in your morphir.json and run morphir make which will successfully resolve the references to the external IR. The resulting IR will be incomplete though because it will contain references to those other IRs.

This means that any tool that works with that IR will have issues finding the definition for certain references. So at some point before that we need to:

• Load all the IRs that the current one depends on and their dependencies transitively
• Do tree-shaking to eliminate unused definitions (optional but very beneficial)
• Detect, resolve or report any version conflicts

The question is when do we do each step and to what extent. This problem is similar to static vs. dynamic linking in other languages but since Morphir can be authored and executed in various ways the notion of compile-time vs runtime isn't that well-defined. So let's look at some of the existing tools we have and see which steps they depend on.

Elm Frontend

The Elm Frontend parses the Elm sources, does name resolution and type inference. This means that it needs to:

• Load all the interfaces (type signatures) of all the used types and functions in the current package.
• Detect, resolve or report version conflicts on the interface level (so not considering implementations).
• Not directly related but in order to be able to author the Elm code with the Elm tooling we also need Elm sources for all the dependencies.

Scala Backend

The Scala Backend reads the IR and generates Scala source code from it. By default it only generates Scala files for the definitions within the current package and does not check if the references point to an existing definition or not. This means that the generated code will contain references to the dependencies and the problem of making them available for the Scala compiler is left to the user to solve.

This is not ideal so we have been considering to provide the option to generate all dependencies into the current project directly. If we decide to do that this component will need to:

• Load all the interfaces and implementations of all the used types and functions in the current package.
• Detect, resolve or report version conflicts on the interface level (so not considering implementations).

Morphir Web

Morphir Web which can be accessed by running morphir-elm develop offers a lot of features ranging from insight to testing so it needs full access to everything in the IR and its dependencies. Specifically it needs to:

• Load all the interfaces and implementations of all the used types and functions in the current package.
• Detect, resolve or report version conflicts on the interface level (so not considering implementations).

Problem Statement

Morphir is modular and all these components can be combined in various ways in a particular project. As a result, the exact order in which these components will be invoked in an SDLC process is unknown. At the same time it would be ideal to only apply a particular step only once both for efficiency and consistency.

There are various technical solutions to achieve that so we would like to invite everyone to chime in to figure out the best solution.

[DamianReeves]

I've also been considering linking and how we construct IRs as our use-cases also need to support referencing IR/modules across morphir projects/models.