Opened 3 years ago
Last modified 3 months ago
#9123 new bug
Need for higher kinded roles
Reported by: | simonpj | Owned by: | goldfire |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Compiler (Type checker) | Version: | 7.8.2 |
Keywords: | Roles, QuantifiedContexts | Cc: | ecrockett0@…, ekmett@…, dima@…, douglas.mcclean@…, sweirich@…, RyanGlScott |
Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
Type of failure: | None/Unknown | Test Case: | |
Blocked By: | Blocking: | ||
Related Tickets: | Differential Rev(s): | ||
Wiki Page: |
Description (last modified by )
This thread on ghc-devs identifies a real shortcoming of the new roles system. Here's a compact example, from the thread
class C m where ret :: a -> m a bind :: m a -> (a -> m b) -> m b join :: m (m a) -> m a newtype T m a = MkT (m a) deriving( C )
The deriving(C)
is accepted without join
in the class, but rejected when join
is added.
T9123.hs:10:37: Could not coerce from `m (m a)' to `m (T m a)' because `m (m a)' and `m (T m a)' are different types. arising from the coercion of the method `join' from type `forall a. m (m a) -> m a' to type `forall a. T m (T m a) -> T m a'
Note that the AMP proposal adds join
to class Monad
!
In one way it is rightly rejected: it really would be unsound to derive an instance for C (T K)
where K
's argument had nominal (but not representational) role. But we have no way to limit the type constructors at which T
can be used.
This deficiency is noted in the Safe Coercions paper, but this seems to be the first occasion on which it has bitten us badly.
Edward made a suggestion on the thread.
Change History (40)
comment:1 Changed 3 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 3 years ago by
comment:3 Changed 3 years ago by
I'm in support, generally, of Edward's suggestion on that thread. His idea does not go "all the way", in that there are some ideas we might want to express but cannot, as Edward points out. But, if the current roles story works for 95% of cases (where the join
problem is an important member of the 5%), the current story + Edward's suggestion would probably cover 99.5%. And, the beauty of Edward's idea is that it is requires no change to Core and can mostly be implemented in user-land. GHC should support with magically-generated instances (like we already do for Coercible
) and will need to incorporate these ideas into the Coercible
solver, but these are relatively minor changes.
Suppose that the class involved is named Representational
, as Edward suggests. (I actually am against that name, because it makes the wrong thing sound representational. But, let's leave bikeshedding over names until later.) Should we make Representational
a superclass of Functor
? It "makes sense" that every Functor
should treat its argument representationally. And, doing so would make GND work trivially with the new Monad
. And, doing so would make Traversable
GND'able (it currently is not). But, of course, it would mean that users may want to write Functor
instances that are not representational and now cannot. (For example, this one.)
If we decide not to make Representational
a (transitive) superclass of Monad
, then Monad
with join
would only be GND'able if the GND instance has a Representational
constraint in its context. This context could probably be inferred. But, any user writing a standalone GND for Monad
(not an uncommon occurrence, I imagine) would have to be aware of this issue.
These issues aren't meant to be "push-back" -- just some ramifications we should consider as we move forward.
It is interesting to note that, had we gone with the POPL'11 implementation of roles, which included support for "higher-kinded" roles, we would be even more stuck here. That implementation tied a role in with a type's kind, which means that we would be forced to make every Monad
representational in order to get GND to work with join
. With the current plan, we have this free design choice. The current roles story may be somewhat less powerful than roles in POPL'11, but they are surely more flexible.
comment:4 Changed 3 years ago by
Description: | modified (diff) |
---|
comment:5 Changed 3 years ago by
Let's articulate Edward's proposal explicitly, so we all know what we are talking about. Here is one possible version, expressed in the language of the Safe Coercions paper. Yell if I get this wrong.
- We add the following decomposition rule to the solution rules for
Coercible
:instance (Repesentational f, Coercible a b) => Coercible (f a) (f b)
Edward actually suggested something more likeinstance (Representational f, Coercible f g, Coercible a b) => Coercible (f a) (g b)
but I dislike the assymetry inf
,g
, and I think this weaker thing will do.
- The
Representational
class would have built-in solution rules (asCoercible
does), all of the form:instance Representational (T a b c)
whenever the next argument ofT
is representational.
I am hazy about
- Whether it should be possible to have user-written instances for
Representational
- How
Representational
is defined. It could beclass Representational f where rep :: Coercion a b -> Coercion (f a) (f b)
orclass Representational f where rep :: Coercible a b => Coercion (f a) (f b)
or (ifRepresentational
is built in)class Representational f where rep :: Coercible a b => Coercible (f a) (f b)
The latter is easiest for the type checker.
I see no need to make Representational
a superclass of Functor
. Rather, GND on
data T m a = MkT (m a) deriving( Monad )
would yield an instance
instance (Representational m, Monad m) => Monad (T m) where ...
which is absolutely fine. No need for every monad to be representational.
Simon
comment:6 Changed 3 years ago by
I agree with everything Simon said.
About hand-written instances of Representational
: We need some facility for this. For example, take ReaderT
:
newtype ReaderT r m a = ReaderT (r -> m a)
ReaderT
gets roles R, R, N. But, this instance is sensible:
instance Representational m => Representational (ReaderT r m)
I suppose it wouldn't be beyond possibility to beef up the role inference algorithm to spit out such Representational
instances. Or, we could require that users request such instances (with a standalone deriving
perhaps) but fill in the details automatically.
If we do allow users to write their own instances, we seem to lose the guarantee that coerce
is free at runtime, no?
comment:7 Changed 3 years ago by
While we're thinking about this, is it at all worthwhile to have a Phantom
class analogous to Representational
? My first thought is "no, not until someone shouts."
comment:8 Changed 3 years ago by
If we do allow users to write their own instances, we seem to lose the guarantee that coerce is free at runtime, no?
Did anyone say guarantee? It’s a promise, not more :-)
What I’m saying: By passing around boxed Coercible
witnesses (e.g. in the Coercion
data type) you can probably create quite complex terms that the compiler will not be able to simplify completely. Then coerce
still incurs the cost of evaluating that box. So I would not worry that a ill-meaning user can make coerce
expensive by writing strange Representational
instances, as long as he can write good instances where there are good instances.
comment:9 Changed 3 years ago by
Cc: | ekmett@… added |
---|
Adding Edward in cc. How bad would it be to leave join
out of Monad
, for now at any rate, so that we can get AMP implemented?
comment:10 Changed 3 years ago by
Just wrote up this wiki page describing the design and laying out some challenges. The page includes a pie-in-the-sky idea for a new design for roles that might fix this problem, at the cost of quite a bit more complexity.
comment:11 Changed 3 years ago by
Richard,
The asymmetry is annoying but without it you cannot write the lifting for Representational (StateT s m)
.
I started without it for the same reason you dislike it and added it only when forced.
Simon,
As for dropping join for now I'd be sad to see it lost, but if we at least commit to seeking a solution to this problem, I'd be personally okay with sacrificing it for now.
comment:12 Changed 3 years ago by
Edward, can you elaborate the "without it you cannot write.." issue, perhaps on the wiki page, so we have it recorded properly?
In the short term (i.e. before we converge on a better design for roles) I think we have these alternatives:
- Defer AMP altogether (very undesirable)
- Remove
join
fromMonad
in the AMP story (better) - Adopt full AMP (
join
and all), but accept that GNDderiving( Monad )
won't work for some monad transformers; you have to write it by hand.
I am agnostic. It's a library issue. Edward, which would you like?
Simon
comment:13 Changed 3 years ago by
newtype StateT s m a = StateT { runStateT :: s -> m (a, s) }
This means that when you go to describe the instance for Representational (StateT s m)
it needs to convert s -> m (a, s)
into s -> m (b, s)
given a coercion between a and b.
But that means we're coercing (,) a
into (,) b
-- let's call those f and g respectively -- and we're expanding that with the coercion from s into s which is trivial.
If we can't lift (Representable f, Coercion f g, Coercion a b)
into Coercion (f a) (g b)
but can only go (Representable f, Coercion a b) => Coercion (f a) (f b)
then we get stuck, as we only have (Representable ((,) a), Coercion ((,) a) (,) b, Coercion s s)
!
For state you could actually get by with a _different_ weaker rule added to the one Richard offered:
ext :: forall (f :: x -> y) (g :: x -> y) (a :: x). Coercion f g -> Coercion (f a) (g a)
which I fake with unsafeCoerce
right now in
https://github.com/ekmett/roles/blob/master/src/Data/Roles.hs
But that isn't enough to handle lifting a coercion where what 'a' occurs on both sides of the nested, which is what you get for free monads, cofree comonads, etc.
The simplest case that fails is probably:
newtype Pair a = Pair (a, a)
comment:14 Changed 3 years ago by
Let's remove join
from Monad
for now, and see if we can't resolve this issue before we're forced to release.
That lets GND work for Monad
, which I agree is critical; it is a very common idiom to hide transformers
monads inside a newtype wrapper and derive Monad
and the related mtl instances and I'd hate to lose that.
comment:15 Changed 3 years ago by
The question, as I see it, is this:
If we know (Rep m, Coercible a b)
can we derive Coercible (s -> m (a, s)) (s -> m (b, s))
? We assume that the only way we can use Rep
is in the following rule: (Rep m, Coercible x y)
implies Coercible (m x) (m y)
. Call that rule (*).
Yes:
- Decompose the
(->)
to get that we need to showCoercible (m (a, s)) (m (b, s))
.
- Use (*) to get that we need to show
Coercible (a, s) (b, s)
.
- By the roles of
(,)
, this reduces toCoercible a b
.
- We are done by assumption.
What have I missed? Where did the asymmetry come into play? I'm not saying that the current solver does this, but it seems possible. You may also want to see the original post in #9117 which may be of interest. (Much of the ensuing commentary is not as relevant.)
comment:16 Changed 3 years ago by
True, if you keep the existing role rules that works for the concrete choice of (,) and State works.
Consider a parameterized version where we fuse the two parameters into arguments of the same type argument, but don't make it concrete.
e.g.
newtype Foo s p a = Foo (s -> p a s)
and there you get stuck on GND for a
whether or not you keep the existing role-based machinery for lifting coercions.
comment:17 Changed 3 years ago by
Now, the question is whether we can derive Coercible (s -> p a s) (s -> p b s)
from (Rep p, Coercible a b)
, right? Once again, we assume that the only way we can use Rep
is the rule (*) in comment:15.
- Decompose
(->)
to get that we need to showCoercible (p a s) (p b s)
.
- Use the eta rule requested at the top of #9117 to reduce the goal to
Coercible (p a) (p b)
.
- Use rule (*) to reduce the goal to
(Rep p, Coercible a b)
.
- We are done by assumption.
This was indeed somewhat harder than the derivation in comment:15 in that it requires the constraint solver to do something it currently cannot (the eta reduction in #9117), but it still doesn't require an asymmetrical rule for Rep
. Note that the eta rule is easily expressible in Core -- it's just that the constraint solver doesn't know to use it.
Does this address your concern, Edward?
comment:18 Changed 3 years ago by
Hrmm, when we have something like
newtype F p f a = F { runF :: p a (f (F p f a)) }
do we get stuck again because of the fact that p has two args and the coercion of a has to be used on both sides of it?
Free = F (,) Cofree = F Either
comment:19 Changed 3 years ago by
Here, we need more assumptions. We have to assume an instance Rep p
and an instance Rep (p a)
. (We need it only for the a
in question, though there would almost certainly be an axiom asserting forall a. Rep (p a)
.)
So, we assume (Rep p, Rep (p a), Rep f, Coercible a b)
and wish to prove Coercible (p a (f (F p f a))) (p b (f (F p f b)))
. We would be doing this in the context of an instance declaration for Rep (F p f)
, so we can assume that, too.
- Use transitivity to break our goal down to two sub-goals:
Coercible (p a (f (F p f a))) (p a (f (F p f b)))
andCoercible (p a (f (F p f b))) (p b (f (F p f b)))
.
- First sub-goal
Coercible (p a (f (F p f a))) (p a (f (F p f b)))
:- Use rule (*) to break the goal down to
Rep (p a)
andCoercible (f (F p f a)) (f (F p f b))
. The first of these is solved by assumption. - Use rule (*) to get
Rep f
andCoercible (F p f a) (F p f b)
. The first of these is solved by assumption. - Use rule (*) to get
Rep (F p f)
andCoercible a b
. Both are solved by assumption.
- Use rule (*) to break the goal down to
- Second sub-goal
Coercible (p a (f (F p f b))) (p b (f (F p f b)))
:- Use the #9117 eta rule to reduce the goal to
Coercible (p a) (p b)
. - Use rule (*) to reduce the goal to
(Rep p, Coercible a b)
. - Done by assumption.
- Use the #9117 eta rule to reduce the goal to
I'm not necessarily saying that the constraint solver is up to this task without help (that is, user annotations or other assistance), but Rep
with rule (*) seems to be able to support the derivation once found.
comment:20 Changed 3 years ago by
Good trick w/ transitivity!
You've won me over on the simpler rule. =)
That leaves these:
instance Representational f => Representational (Compose f) instance Representational p => Representational (WrappedArrow p) instance Representational (p a) => Representational (WrappedArrow p a)
...and if I understand correctly, the form we're talking about also gets stuck whenever an earlier argument occurs 'under' a later argument, e.g. the s
when we try to define instance Representational StateT
occurs under the m
but everything else should work.
comment:21 Changed 3 years ago by
instance Rep m => Rep (Compose m)
where newtype Compose m f a = Compose (m (f a))
:
We wish to show forall a. Coercible (m (f a)) (m (g a))
from Rep m
and Coercible f g
. Fix a
.
- Use rule (*) to get
Coercible (f a) (g a)
. - Use #9117's eta to get
Coercible f g
. We're done.
instance Rep p => Rep (WrappedArrow p)
where newtype WrappedArrow a b c = WrappedArrow (a b c)
:
We wish to show forall a. Coercible (p x a) (p y a)
from Rep p
and Coercible x y
. Fix a
.
- Use #9117's eta to get
Coercible (p x) (p y)
. - Use rule (*), and we're done.
instance Rep (p a) => Rep (WrappedArrow p a)
:
We wish to show Coercible (p a x) (p a y)
from Rep (p a)
and Coercible x y
.
- Use rule (*), and we're done.
Unfortunately, I can't counter the point about StateT
-- we still can't express that s
should be representational if m
's argument is. But, what about this:
newtype Flip0 f a b = Flip0 (f b a) -- not used; just to better understand Flip1 newtype Flip1 f a b c = Flip1 (f b a c) instance Rep m => Rep (Flip1 StateT m)
Would that work for you?
comment:22 Changed 3 years ago by
Just added a new section to the wiki page about difficulty of integrating into the solver. Despite my success yesterday at defeating all of Edward's challenges, it seems his rule will lead to a better implementation.
comment:23 follow-up: 26 Changed 3 years ago by
Owner: | set to goldfire |
---|
Our current solution seems workable, albeit not terribly principled. Cost is low, but benefits seem tangible.
Richard (who owns this ticket anyway) is willing to implement this before 7.10. Thanks.
Simon
comment:24 Changed 3 years ago by
Cc: | dima@… added |
---|
comment:25 Changed 3 years ago by
Cc: | douglas.mcclean@… added |
---|
comment:26 Changed 3 years ago by
Milestone: | → 7.10.1 |
---|
Replying to simonpj:
Richard (who owns this ticket anyway) is willing to implement this before 7.10. Thanks.
(milestone set according to this hint)
comment:27 Changed 3 years ago by
Cc: | sweirich@… added |
---|---|
difficulty: | Unknown → Project (more than a week) |
Milestone: | 7.10.1 → 7.12.1 |
I hate to disappoint, but my thesis advisor, cc'd, has forbidden me from taking this on in the near future.
To be fair, I didn't push back too strongly, because this is a non-trivial change:
- It requires a new theory for Core to be worked out (and, ideally, proved type-safe). We need to update Core because rule (*) from comment:15 has to be baked in.
- It requires a way to infer
Rep
instances. Are these created on-the-fly likeCoercible
ones? Are they generated automatically, but not on-the fly? Do they require the user to request them?
- It requires a new solver for
Coercible
instances, preferably with some suggestion of completeness.
Though I'm not convinced the community would want yet another paper on roles, fixing the deficiencies of the previous paper, I actually think that there's enough to be worked out here that such a paper would be possible to write.
And, I'm a little bothered that, even after all of this work, we would still not have a comprehensive solution. I would expect that within the next few years, someone (quite possibly named Edward Kmett) would find a very-legitimate use case that this solution would not address. And then the whole rigamarole would have to be repeated.
The real answer, I think, is role polymorphism, which would have the expressiveness of the POPL'11 paper but the flexibility of the current system. This would mean decorating each kind-level arrow with a role and allowing abstraction over those roles. But, these annotations could be drawn from an ordinary promoted datatype! Thus, we would have something like (->) :: Role -> * -> * -> *
. (There is some similarity between this idea and NoSubKinds.) Inferring these annotations might be problematic, though.
It is tantalizing to note that roles are somehow dual to injectivity. That is, if F
's argument has a representational role, then x ≈ y
implies F x ≈ F y
(writing ≈
for `Coercible`
). Rather similarly, if F
is injective, then F x ~ F y
implies x ~ y
. We might even want to abstract over injectivity, noting that map f
is injective precisely when f
is injective. Injectivity abstraction is certainly far off (we don't yet have a useful map
in types!), but my intuition is that the right solution to the problems described here would also allow injectivity abstraction... and that if it doesn't we might not have the right solution here.
Getting much more concrete, I think a better way forward in the short term is to allow something like deriving {-# UNSAFE #-} instance Monad m => Monad (N m)
, allowing GND to use unsafeCoerce
instead of coerce
. This could, instead, be done using Template Haskell without too much bother. We could even go ahead and add join
to Monad
. Most GNDs with the enhanced Monad
would still work, and if they don't, we can make sure that the error message gives useful advice.
comment:28 Changed 3 years ago by
Cc: | ecrockett0@… added |
---|
comment:29 Changed 3 years ago by
I've recently realized that an alternate, much more tantalizing fix to this problem is to allow quantifying over implication constraints (#2256).
To be concrete, consider
class Monad m where join :: m (m a) -> m a data StateT s m a = StateT (s -> m (a, s)) -- could be a newtype, but that -- doesn't change my argument type role StateT nominal representational nominal -- as inferred instance Monad m => Monad (StateT s m) where ... newtype IntStateT m a = IntStateT (StateT Int m a) deriving Monad
This induces the following instance:
instance (...) => Monad (IntStateT m) where join = coerce (join :: StateT Int m (StateT Int m a) -> StateT Int m a) :: forall a. IntStateT m (IntStateT m a) -> IntStateT m a
GHC needs to infer the (...)
. It starts with Monad m
along with
Coercible (StateT Int m (StateT Int m a) -> StateT Int m a) (IntStateT m (IntStateT m a) -> IntStateT m a)
This gets reduced to
Coercible (StateT Int m (StateT Int m a)) (StateT Int m (IntStateT m a))
and is then stuck, unable to unwrap the newtype in a nominal context. The problem, at this point is that a
is out of scope in the instance context (...)
, and so GHC gives up. If we had implication constraints, we could just quantify! The instance context would be complex, but everything would work out in practice.
As a separate case, imagine I had declared StateT
as a newtype (so that we can look through to its definition) and we wanted to prove, say, Coercible (StateT Int) (StateT Age)
. Right now, we're stuck, but, I conjecture that the following would work:
data Coercion a b where Coercion :: Coercible a b => Coercion a b pf :: forall m c. (forall a b. Coercible a b => Coercible (m a) (m b)) => Coercion (StateT Int m c) (StateT Age m c) pf = Coercion
(The c
parameter is necessary to allow GHC to unwrap the newtype, as it won't unwrap a partially-applied newtype.)
To prove, GHC unwraps the newtypes to get
[W] Coercible (Int -> m (c, Int)) (Age -> m (c, Age))
and then
[W] Coercible (m (c, Int)) (m (c, Age))
GHC will then look for an appropriate instance, finding
[G] forall a b. Coercible a b => Coercible (m a) (m b)
which matches nicely. (This last step is beyond the current algorithm for the treatment of givens, but it's exactly what the instance-lookup algorithm does! So we just adapt that to a new scenario.) Thus, we now have
[W] Coercible (c, Int) (c, Age)
which is solved handily.
More comments on the solving algorithm on #2256, shortly.
I think this solution, of using implication constraints, is much better than the ad-hoc idea in Roles2. It's more powerful, simpler to explain, simpler to implement, and it goes "all the way".
comment:30 follow-up: 31 Changed 3 years ago by
At the nub of this is the following observation. If a function has type
forall m. (forall a b. Coercible a b => Coercible (m a) (m b)) => ...blah...
then that, in effect, restricts m
to type constructors whose first argument has nominal role -- exactly the problem posed in the Description of this ticket.
Very good observation.
But the inferred context for deriving
clauses is deliberately restricted. If you say
newtype T m a = MkT (m a) deriving( C )
(again from the Description) GHC will insist on a simple context, i.e. a class applied to type variables. You want to infer a rather complicated context. I don't know how to do that.
You could perhaps declare it like this, using "standalone deriving"
deriving instance (C m, forall a. Coercible a b => Coercible (m a) (m b)) => C (T m)
but GHC users might not be so happy with that whenever they say deriving( Monad )
.
Or perhaps
type RepArg1 m = forall a b. (Coercible a b => Coercible (m a) (m b)) deriving instance (C m, RepArg1 m) => C (T m)
And now we are close to Roles2. (But we still don't have deriving( Monad )
unannotated.
Simon
comment:31 follow-up: 32 Changed 3 years ago by
Replying to simonpj:
You want to infer a rather complicated context. I don't know how to do that.
Sure you do!
Currently, the code in TcDeriv instructs the solver to try to reduce certain constraints. This reduction results in an unsolved implication constraint -- exactly the one we need to quantify over. The TcDeriv code, at this point, extracts out the flat (er... now called simple) constraints, checks to see if they're exotic, and then reports an error if there are any exotic simple constraints or if there are any leftover implication constraints. Currently, there's a leftover implication, and so we report an error.
If, instead, we quantified over the leftover implication, we'd be done, with an inferred implication constraint.
A separate question is whether or not this is desirable from a user's standpoint. deriving
quite rightly restricts what it will quantify over. And implication constraints seem quite exotic. We could, though, say that implication constraints aren't exotic. Or, we could bake in the particular implication constraint (forall a b. Coercible a b => Coercible (m a) (m b))
, recognize that, rewrite it to use Simon's type synonym RepArg1 m
, and then it doesn't seem so exotic after all. That's terribly hacky, but it just might be useful enough to do. Or, we could punt and require users to write the constraint when they want it -- the error message will give them guidance. I don't have a strong opinion in any direction here.
It is worth noting that, if join :: m (m a) -> m a
is in Monad
, most GNDs of Monad
would work today. The ones that trip up are when the newtype wraps a monad transformer. That's a common-enough case that we don't want to make it impossible, but a rare enough case that I'm OK with making it annoying, if we can't do better.
comment:32 follow-up: 33 Changed 3 years ago by
Replying to goldfire:
If, instead, we quantified over the leftover implication, we'd be done, with an inferred implication constraint.
Not a good plan. I'm sure you can't be saying
- Reject a constraint
C a Int
as "exotic" - Accept a constraint
forall a. C a Int
as fine
When would an implication be "exotic"?
I think it'd be much better to ask the user to use standalone deriving and write the constraint; but that's going to be jolly scary for users who just want deriving( Monad )
. Your point that it only affects monad transformers is a good one though.
comment:33 Changed 3 years ago by
Replying to simonpj:
I'm sure you can't be saying
- Reject a constraint
C a Int
as "exotic"- Accept a constraint
forall a. C a Int
as fine
Indeed, I was suggesting that implication constraints could be considered not exotic. Perhaps it would make the most sense to simply recur in the implication case, ruling out the example above, but accepting (forall a b. Coercible a b => Coercible (m a) (m b))
(although I seem to recall that anything with a repeated variable is considered exotic).
In any case, I have very little intuition as to how to set the exotic-checker and could be convinced to do just about anything.
Here's a fresh approach to the problem: Don't rule out exotic contexts at all (subject to having the right language extensions on, as with all inferred types). Instead, issue a warning (on by default) when the context is exotic. The warning would exhort programmers to use standalone-deriving to suppress it. (Or, of course, there would be -fno-warn-exotic-inferred-contexts
.) This should allow strictly more programs to type-check than today, so it's not a regression. And, as I understand it, the Haskell Report doesn't specify this end of the language, so we wouldn't be going against spec.
With such a warning mechanism in place, I would favor a more stringent exotic-checker.
With this warning behavior, deriving (Monad)
would work (with -XImplicationContexts
) and just issue a warning. (Without -XImplicationContexts
, it would advise turning on -XImplicationContexts
, of course!)
comment:34 Changed 3 years ago by
I think it'd be better to consider any non-type-variable context as exotic, and reject it. You can always use standalone deriving.
The trouble is that it's very easy to get contexts like (C T)
, which perhaps might be satisfiable at the call site, but not at the deriving
site, but that is unusual, and the programmer ought to be calling it out explicitly.
GHC originally accepted more exotic deriving
contexts, and moved step by step to the current fairly conservative position.
Simon
comment:36 Changed 21 months ago by
Component: | Compiler → Compiler (Type checker) |
---|
comment:37 Changed 21 months ago by
Milestone: | 8.0.1 |
---|
comment:38 Changed 16 months ago by
Cc: | RyanGlScott added |
---|
comment:39 Changed 8 months ago by
Keywords: | Roles added |
---|
comment:40 Changed 3 months ago by
Keywords: | QuantifiedContexts added |
---|
See #9112 (comment 3) for another example.