Morphir elm compiler allows type definitions with type parameters that exist only on RHS, allowing runtime type errors #1147
Description
Describe the bug
In Elm, if you have a type definition - alias or otherwise - any type parameters that appear on the RHS must appear on the LHS. This is not enforced in Morphir, allowing runtime type errors.
To Reproduce
The following code compiles with morphir-elm
:
type Any = Any a
polymorphicList : Int -> String -> List Any
polymorphicList i s = [Any i, Any s]
runtimePolymorphism : a -> b -> String
runtimePolymorphism a b =
let Any x = Any a in
let Any y = Any b in
String.concat[x, y]
rutimeTypeError: Int -> String
runtimeTypeError i =
let Any x = Any i in
let Any y = Any 6 in
String.concat[x, y]
type alias AnyAlias = a
aliasedRuntimePolymorphism : AnyAlias -> AnyAlias -> List AnyAlias
aliasedRuntimePolymorphism x y = [x, y]
aliasedRuntimeTypeError : Int -> String -> List AnyAlias
aliasedRuntimeTypeError i s = aliasedRuntimePolymorphism i s
mixedNumbers : Int -> List AnyAlias
mixedNumbers i = aliasedRuntimePolymorphism i 4.5
The fact that this compiles demonstrates the lack of time safety exposed by allowing type parameters on RHS only. In polyMorphicList
(which can be run in the morphir elm interpreter), List Any
can contain Any String
as well as Any Int
. Furthermore, when extracting from an Any, the type inference treats the value as a free type variable, allowing it to effectively be cast to anything.
This can be seen in runtimePolymorphism
, which will work if you enter two strings (quotes required), but be "Unable to Compute" otherwise.
The same behaviors can be seen with type aliases, showing similar behavior.
Also, while it is not possible to actually create a list of mixed Ints and Strings (a runtime type error results), it does seem to be possible to make a mixed list of ints and floats.
Expected behavior
These type definitions should be rejected by the compiler, as happens in native elm.
Desktop (please complete the following information):
- OS: OSX
- Version: 2.89.0
Additional Context
While this has similar consequencs to #1146 , I believe it is a separate underlying issue.