Programs like
```
after : ({} -> a), ({} -> b) -> ({} -> b)
fx = after (\{} -> {}) \{} -> if Bool.true then fx {} else {}
```
are legal because they always decay to functions, even if they may not
look like functions syntactically. Rather than using a syntactic check
to check for illegally-recursive functions, we should only perform such
checks after we know the types of values.
Closes#4291
Every type can have `Eq.isEq` derived for it, as long as
- it does not transitively contain a function
- it does not transitively contain a floating point value
- it does not transitively contain an opaque type that does not support
`Eq`
Prior to this commit, if you had a module structure like
```
| - A.roc
| - Dep
| - B.roc
```
where `B.roc` was defined as
```
interface B exposes [] imports []
```
and `A.roc` was defined as
```
interface A exposes [] imports [Dep.B]
```
The compiler would hang on you. The reason is that even though we expect
`B` to be named `Dep.B` relative to `A`, that would not be enforced.
With this patch, we now enforce such naming schemes - a module must have
the namespaced name it is referenced by. Currently, we determine the
expected namespaced name by looking at how transitive dependencies of the
root module reference the module. In the future, once we have a package
ecosystem and a solid idea of "package roots", we can use the "package
root" to determine how a module should be named.
Closes#4094
Previously we would construct the shapes of unions used in the pattern
tree for exhaustiveness checking using the type of the branch patterns,
rather than the type of the condition variable. Clearly we want to
always use the condition variable, otherwise some branches will be
seen as exhaustive, when they are not!
To do this, we now index into the condition variable while refying the
patterns to build the tree for exhaustiveness checking.
Closes#4068
