| ... | ... | @@ -185,7 +185,23 @@ topdecl -> default tycls type_1 type_2 ... type_n |
|
|
|
That is, there is a single unique relation between types that can be chosen if *all* of its variables are otherwise unconstrained.
|
|
|
|
|
|
|
|
|
|
|
|
Open questions: if some of the variables are already resolved to actual types, is it OK to default the remaining variables? Assuming the resolved types are in the default relation anyway? What if the already-resolved types are not in the default relation? Would anyone ever want to use defaulting to choose different types depending on what other types have already beeen resolved?
|
|
|
|
Open questions: if some of the variables are already resolved to actual types, is it OK to default the remaining variables? Assuming the resolved types are in the default relation anyway? What if the already-resolved types are not in the default relation? Would anyone ever want to use defaulting to choose different types depending on what other types have already been resolved?
|
|
|
|
|
|
|
|
|
|
|
|
What happens if the choice of default types is not confluent? For example:
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
instance Foo Float Integer
|
|
|
|
instance Foo Double Int
|
|
|
|
default Fractional Double
|
|
|
|
default Num Integer
|
|
|
|
(Fractional a, Foo a b, Num b) => e
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Here, if you choose 'a' first, using the default Fractional Double, then because you have an instance of Foo Double Int, then 'b' must be Int. But if you choose 'b' first, using the default Num Integer, then because you have an instance Foo Float Integer, then 'a' must be Float. One suggestion might be that defaulting will only occur if the results are confluent, i.e. the compiler should try all possible orderings in
|
|
|
|
which to default variables, and if they do not come up with the same
|
|
|
|
answer, then reject the program.
|
|
|
|
|
|
|
|
### Pros
|
|
|
|
|
| ... | ... | @@ -196,7 +212,8 @@ Open questions: if some of the variables are already resolved to actual types, i |
|
|
|
|
|
|
|
### Cons
|
|
|
|
|
|
|
|
- not sure if this exactly captures the existing Haskell'98 module (but because defaults are currently limited to Prelude classes, it probably does).
|
|
|
|
- not sure if this exactly captures the existing Haskell'98 module (but because defaults are currently limited to Prelude classes, it probably does)
|
|
|
|
- the story for MPTC is not altogether clear yet
|
|
|
|
|
|
|
|
## Proposal 3 - global scope
|
|
|
|
|
| ... | ... | |