Quel est le type de classe équivalente à ce qui suit le dictionnaire existentiellement quantifié, inspiré par le type Pipe
:classe de type existentiellement quantifié
{-# LANGUAGE ExistentialQuantification, PolymorphicComponents #-}
data PipeD p = forall cat . PipeD {
isoI :: forall a b m r . Iso (->) (p a b m r) (cat m r a b),
categoryI :: forall m r . (Monad m) => CategoryI (cat m r) ,
monadI :: forall a b m . (Monad m) => MonadI (p a b m) ,
monadTransI :: forall a b . MonadTransI (p a b) }
L'idée approximative Je vais pour essaie de dire que compte tenu de la (PipeLike p)
contrainte, nous pouvons alors déduire (MonadTrans (p a b), Monad (p a b m)
et (en utilisant le pseudo-code) (Category "\a b -> p a b m r")
.
Le CategoryI
et MonadI
ne sont que les équivalents de ces dictionnaires de type classes que j'utilise pour exprimer l'idée que Category
, Monad
et MonadTrans
sont (un peu) super-classes de ce type PipeLike
.
Le type Iso
est juste le dictionnaire suivant le stockage d'un isomorphisme:
data Iso (~>) a b = Iso {
fw :: a ~> b ,
bw :: b ~> a }
Je pense que les types de données associés sont probablement la bonne direction, même si je ne voulais pas du tout de dictionnaires. J'espérais quelque chose comme: 'classe (Monad (p a b m), MonadTrans (p a b), Catégorie (Cat p)) => PipeLike p {- classe vide -}'. Le truc d'isomorphisme était simplement lié au type quantifié existentiellement, ce qui n'est pas nécessaire si j'utilise le type de données associé. –
Vous ne pouvez pas créer de superclasses 'Monad' et' MonadTrans', car étant donné 'p', il n'y a aucun moyen de choisir' a', 'b' et' m'. Vous pouvez, cependant, faire des instances comme je l'ai montré. Ils fonctionneront comme les interfaces originales. – Heatsink
Cela a du sens. Merci d'avoir éclairci mes pensées à ce sujet. Je vais accepter ça. –