Opened 18 months ago
Last modified 16 months ago
#14943 new bug
Make (=>) polykinded (:: k -> k -> Constraint)
Reported by: | Iceland_jack | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Compiler | Version: | 8.2.2 |
Keywords: | QuantifiedConstraints | Cc: | |
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
Would it be a good idea to treat =>
in -XQuantifiedConstraints
as
type family (=>) :: k -> k -> Constraint where (=>) = Implies0 (=>) = Implies1 (=>) = Implies2 ..
class (a => b) => Implies a b instance (a => b) => Implies a b class (forall x. f x => g x) => Implies1 f g instance (forall x. f x => g x) => Implies1 f g class (forall x y. f x y => g x y) => Implies2 f g instance (forall x y. f x y => g x y) => Implies2 f g ..
or will this get too confusing? This means type signatures like the ones from #14942
oneTwo :: (forall x. semi x => Semigroup x) => Free semi Int nil :: (forall x. mon x => Monoid x) => Free mon Int together :: (forall x. mon x => Monoid x) => [Free mon Int]
could equivalently be written
oneTwo :: (semi => Semigroup) => Free semi Int nil :: (mon => Monoid) => Free mon Int together :: (mon => Monoid) => [Free mon Int]
I'm not sold on this idea myself. It's quite possible this would screw with the parser.
Change History (3)
comment:1 Changed 18 months ago by
comment:2 Changed 18 months ago by
No, I don't see a need for this. You could always define such an infix type family yourself, couldn't you? Then you wouldn't need to mess with built-in syntax.
comment:3 Changed 16 months ago by
Keywords: | wipT2893 removed |
---|
Note: See
TracTickets for help on using
tickets.
Yeah... I'm certainly not convinced this is a good idea. This seems needlessly magical, and moreover, oddly asymmetric with the typing rule for
(->)
.