Opened 20 months ago

Last modified 18 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:


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 20 months ago by RyanGlScott

Yeah... I'm certainly not convinced this is a good idea. This seems needlessly magical, and moreover, oddly asymmetric with the typing rule for (->).

comment:2 Changed 20 months ago by goldfire

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 18 months ago by RyanGlScott

Keywords: wipT2893 removed
Note: See TracTickets for help on using tickets.