Nice!
That's kind of what I was going for with Carter earlier in the day, thanks Matthew.
That's kind of what I was going for with Carter earlier in the day, thanks Matthew.
I think a diagonalization function and functor are both very sensible additions to `bifunctors` and `Data.Bifunctor`. The theory behind this is sound: The diagonalization functor Δ: Hask → Hask^Hask, forms the center of the adjoint triple `colim -| Δ -| lim : Hask → Hask^Hask`.
Certainly the function `diag :: a → (a,a)` is something I've seen written in several libraries, and should be included in `Data.Tuple` as a `base` function. The clear generalization of this function is `diag :: Biapplicative f ⇒ a → f a a`. I'm in favor of both existing in their separate capacities.
Certainly the function `diag :: a → (a,a)` is something I've seen written in several libraries, and should be included in `Data.Tuple` as a `base` function. The clear generalization of this function is `diag :: Biapplicative f ⇒ a → f a a`. I'm in favor of both existing in their separate capacities.
Thoughts?
Emily
On Wed, Sep 16, 2020 at 3:49 PM, Carter Schonwald <carter.schonwald@gmail.com> wrote:
Is the join bipure definition taking advantage of the (a->) monad instance? Slick!On Wed, Sep 16, 2020 at 3:39 PM Matthew Farkas-Dyck <strake888@gmail. com> wrote: We also have
diag = join bipure
and (in pseudo-Haskell)
diag = unJoin . pure
where
newtype Join f a = Join { unJoin :: f a a } deriving (Functor)
deriving instance Biapplicative f => Applicative (Join f)
The latter seems on its face potentially related to the instance for
lists of fixed length, but i am not sure how deep the connection may
be._______________________________________________
Libraries mailing list
Libraries@haskell. org
http:// mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries