| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Both #9692 and #14179 were caused by GHC being careless
about using eta-reduced data family instance axioms. Each of those
tickets were fixed by manually whipping up some code to eta-expand
the axioms. The same sort of issue has now caused #15845, so I
figured it was high time to factor out the code that each of these
fixes have in common.
This patch introduces the `etaExpandFamInstLHS` function, which takes
a family instance's type variables, LHS types, and RHS type, and
returns type variables and LHS types that have been eta-expanded if
necessary, in the case of a data family instance. (If it's a type
family instance, `etaExpandFamInstLHS` just returns the supplied type
variables and LHS types unchanged).
Along the way, I noticed that many references to
`Note [Eta reduction for data families]` (in `FamInstEnv`) had
slightly bitrotted (they either referred to a somewhat different
name, or claimed that the Note lived in a different module), so
I took the liberty of cleaning those up.
Test Plan: make test TEST="T9692 T15845"
Reviewers: goldfire, bgamari
Reviewed By: goldfire
Subscribers: rwbarton, carter
GHC Trac Issues: #15845
Differential Revision: https://phabricator.haskell.org/D5294
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After 8136a5cbfcd24647f897a2fae9fcbda0b1624035 (#11450), if you have
a class with an associated type:
```
class C a where
type T a b
```
And you try to create an instance of `C` like this:
```
instance C Int where
type T Int Char = Bool
```
Then it is rejected, since you're trying to instantiate the variable ``b`` with
something other than a type variable. But this restriction proves quite
onerous in practice, as it prevents you from doing things like this:
```
class C a where
type T a (b :: Identity c) :: c
instance C Int where
type T Int ('Identity x) = x
```
You have to resort to an auxiliary type family in order to define this now,
which becomes extremely tiring. This lifts this restriction and fixes #13398,
in which it was discovered that adding this restriction broke code in the wild.
Test Plan: ./validate
Reviewers: simonpj, bgamari, austin
Reviewed By: simonpj
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3302
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch finishes off Trac #11450. Following debate on that ticket,
the patch tightens up the rules for what the instances of an
associated type can look like. Now they must match the instance
header exactly. Eg
class C a b where
type T a x b
With this class decl, if we have an instance decl
instance C ty1 ty2 where ...
then the type instance must look like
type T ty1 v ty2 = ...
with exactly
- 'ty1' for 'a'
- 'ty2' for 'b', and
- a variable for 'x'
For example:
instance C [p] Int
type T [p] y Int = (p,y,y)
Previously we allowed multiple instance equations and now, in effect,
we don't since they would all overlap. If you want multiple cases,
use an auxiliary type family.
This is consistent with the treatment of generic-default instances,
and the user manual always said "WARNING: this facility (multiple
instance equations may be withdrawn in the future".
I also improved error messages, and did other minor refactoring.
|
| | |
|
| |
|
