Opened 8 months ago

Last modified 8 months ago

#16173 new feature request

Move `Data.Profunctor` from `profunctors` package to `base`

Reported by: chshersh Owned by:
Priority: normal Milestone:
Component: Core Libraries Version: 8.6.3
Keywords: base, profunctor, QuantifiedConstraints Cc: ekmett, andrewthad, Artyom.Kazak, glaebhoerl
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #14767 Differential Rev(s):
Wiki Page:

Description

Contravariant was added in GHC 8.6.

Profunctor also looks like fundamental abstraction to be worth considering adding to base.

Having both Profunctor and Choice typeclasses in the base library will also allow to write microprism package similar to microlens. Prisms often turns to be very useful since they allow to work nicely with sum types.

type Prism s t a b = forall p f. (Choice p, Applicative f) => p a (f b) -> p s (f t)

Additional context for this ticket from Reddit:

It was proposed on Reddit to use QuantifiedConstraints for Profunctor. I'm not quite fluent with QuantifiedConstraints, but I think this may looks like this (mostly copy-pasting code from profunctors package):

{-# LANGUAGE QuantifiedConstraints #-}

class (forall a . Functor (p a)) => Profunctor p where
  {-# MINIMAL dimap | (lmap, rmap) #-}

  dimap :: (a -> b) -> (c -> d) -> p b c -> p a d
  dimap f g = lmap f . rmap g

  lmap :: (a -> b) -> p b c -> p a c
  lmap f = dimap f id

  rmap :: (b -> c) -> p a b -> p a c
  rmap = dimap id

instance Profunctor (->) where
  dimap ab cd bc = cd . bc . ab
  lmap = flip (.)
  rmap = (.)

Change History (4)

comment:1 Changed 8 months ago by Artyom.Kazak

Cc: Artyom.Kazak added

comment:2 Changed 8 months ago by ulysses4ever

This is something likely to be brought up in the library mailing list simultaneously.

comment:3 Changed 8 months ago by glaebhoerl

Cc: glaebhoerl added

comment:4 Changed 8 months ago by andrewthad

If is it decided that Profunctor should use QuantifiedConstraints to get its Functor superclass, that would need to happen in library-space, not as it's moving into base. Aside from that, I don't feel particularly strongly about the superclass one way or the other.

Note: See TracTickets for help on using tickets.