Applikative Transformatorklassen

Question

Wo sind die Applicative Transformatorklassen? Ich wollte Transformator Klassen für die applicative transformer stack in a previous answer verwenden, aber sie scheinen nicht zu existieren.

Das transformers Paket und viele andere sind voll von Transformatoren, die Applicative Struktur erhalten, auch wenn die zugrunde liegende Struktur kein Monad ist.

Ein kurzer Blick auf transformers hat Applicative Instanzen für die meisten Transformatoren.

Applicative f => Applicative (Backwards f) 
Applicative f => Applicative (Lift f) 
Applicative (ContT r m) 
Applicative m => Applicative (IdentityT m) 
Applicative m => Applicative (ReaderT r m) 
(Monoid w, Applicative m) => Applicative (WriterT w m) 
(Applicative f, Applicative g) => Applicative (Compose f g) 
(Applicative f, Applicative g) => Applicative (Product f g) 

Nur Transformatoren für Zustand und Wechsel (ExceptT und MaybeT) erfordern einen darunter liegenden monadisch für die Applicative Instanz.

(Functor m, Monad m) => Applicative (ExceptT e m) 
(Functor m, Monad m) => Applicative (MaybeT m) 
(Monoid w, Functor m, Monad m) => Applicative (RWST r w s m) 
(Functor m, Monad m) => Applicative (StateT s m) 

Es gibt eine Klasse für Monad Transformatoren. Ich kann sehen, wie etwas diese Monad Constraint erfordern könnte, da es anderswo nicht eingeführt werden kann.

class MonadTrans t where 
    lift :: (Monad m) => m a -> t m a 

Wo ist die Klasse für Applicative Transformatoren?

class ApTrans t where 
    liftAp :: (Applicative f) => f a -> t f a 

Oder einfach nur alte Transformatoren (obwohl ich mir keine Gesetze dafür vorstellen kann)?

class Trans t where 
    liftAny :: f a -> t f a 

Aufgrund des Unterschied nur in polymorphen Zwängen hat dieser typeclasses ein seltsames Varianz Muster. Abgesehen von ihren Gesetzen, die unvorhergesehene Einschränkungen berücksichtigen müssen, sollte alles, was eine Instanz von Trans ist, automatisch eine Instanz von ApTrans und MonadTrans sein, und alles, was eine Instanz von ApTrans ist, sollte automatisch eine Instanz von MonadTrans sein.

Wenn wir weiter zur mtl-Bibliothek gehen, sind die Klassen dort inkompatibel mit einem Applicative Transformatorstapel. Alle mir bekannten mtl-Klassen haben eine Monad Einschränkung. Zum Beispiel ist hier MonadReader

class Monad m => MonadReader r m | m -> r where 
    -- | Retrieves the monad environment. 
    ask :: m r 
    ask = reader id 

    -- | Executes a computation in a modified environment. 
    local :: (r -> r) --^The function to modify the environment. 
      -> m a  --^@Reader@ to run in the modified environment. 
      -> m a 

    -- | Retrieves a function of the current environment. 
    reader :: (r -> a) --^The selector function to apply to the environment. 
      -> m a 
    reader f = do 
     r <- ask 
     return (f r) 

Was ist der Zweck der Monad Einschränkung ist? Es macht MonadReader und die MonadReader Instanzen für viele der oben genannten Transformatoren inkompatibel mit Applicative Transformator-Stacks.

Ich würde naiv so etwas wie

class Reader r m | m -> r where 
    ask :: m r 
    local :: (r -> r) -> m a -> m a 

oder sogar Split local in eine eigene Klasse schreiben.

class Reader r m | m -> r where 
    ask :: m r 

class (Reader r m) => Local r m | m -> r where 
    local :: (r -> r) -> m a -> m a 

local könnte sehr schwierig sein, ohne Monad Instanz zu verwenden.Eine weitere nützliche Schnittstelle ohne die Monad Einschränkung würde irgendwo so etwas wie

class (Reader r m) => Local r m | m -> r where 
    local :: m (r -> r) -> m a -> m a 

Gibt es vorhandene Transformator Klassen, die die Monad Einschränkung nicht haben, oder gibt es einen tatsächlichen Bedarf für einen weiteren Transformator Klassenbibliothek?

Answer 1

Wie J. Abrahamson sagte, sind Applicatives unter Produkten und Zusammensetzung geschlossen, so dass keine dedizierten Transformatorversionen benötigt werden. Allerdings gibt es auch keine Notwendigkeit, Ihre eigenen Applicative Produkt/Zusammensetzungstypen zu rollen, weil die Plattform bereits diese hat:

• Data.Functor.Compose
• Data.Functor.Product
• Data.Functor.Constant
• Data.Functor.Identity
• Control.Applicative.Lift

Ich habe festgestellt, dass das einfacher ist Art und Weise zu verwenden, diese mit der GeneralizedNewtypeDeriving Erweiterung, denn dann können Sie nur Typen definieren, wie diese:

newtype MyType m a = MyType (Compose (Const m) (Reader m) a) 
    deriving (Functor, Applicative) 

-- Plus a bunch of utility definitions to hide the use of Compose and generally 
-- keep you sane... 

Ein weiteres anderes nützliches Werkzeug in der Applicative Toolset sind das kostenlose applicative Funktors. Ich benutze normalerweise Edward Kmett's free library's version, aber es ist einfach, eigene zu rollen, wenn Sie weniger Abhängigkeiten wünschen.

können diese Definitionen auch nützlich sein (obwohl ich Vorschläge auf dem Namensschema begrüßen würde, vor allem die "I/O" Bit):

{-# LANGUAGE Rank2Types, TypeOperators #-} 

import Control.Applicative 
import Data.Functor.Compose 

-- | A handy infix type synonym for 'Compose', which allows us to 
-- stack 'Applicative's with less syntactic noise: 
-- 
-- > type CalculationT s p f = Reader (Frame s p) :. Reader (Cell s p) :. f 
-- > type Calculation s p = Calculation s p Identity 
-- 
-- Note that 'Identity' and ':.' form something a type-level monoid 
-- modulo @newtype@ equivalence. The following isomorphisms hold: 
-- 
-- > f :. Identity ~= Identity :. f ~= f 
-- > f :. g :. h ~= (f :. g) :. h 
-- 
type f :. g = Compose f g 
infixr :. 

-- | Lift an action from the outer functor into the composite. 
-- Alternative reading: append an 'Applicative' to the right of @f@. 
liftO :: (Functor f, Applicative g) => f a -> (f :. g) a 
liftO = Compose . fmap pure 

-- | Lift an action from the inner functor into the composite. 
-- Alternative reading: prepend an 'Applicative' to the left of @g@. 
liftI :: Applicative f => g a -> (f :. g) a 
liftI = Compose . pure 

-- | Lift a natural transformation from @g@ to @h@ into a morphism 
-- from @f :. g@ to @h :. g@. 
hoistO :: (forall x. f x -> h x) -> (f :. g) a -> (h :. g) a 
hoistO eta = Compose . eta . getCompose 

-- | Lift a natural transformation from @g@ to @h@ into a morphism 
-- from @f :. g@ to @f :. h@. 
hoistI :: Functor f => (forall x. g x -> h x) -> (f :. g) a -> (f :. h) a 
hoistI eta = Compose . fmap eta . getCompose 

Answer 2

Applicative, im Gegensatz zu Monads, sind unter Produkten und Zusammensetzung geschlossen und benötigen daher keine spezielle Klasse von Dingen wie "Transformatoren". Hier ist eine kleine Bibliothek:

data (*) f g x = P (f x) (g x)  deriving Functor 
data C f g x = C (f (g x))  deriving Functor 

instance (Applicative f, Applicative g) => Applicative (f * g) where 
    pure a = P (pure a) (pure a) 
    P ff gf <*> P fx gx = P (ff <*> fx) (gf <*> gx) 

instance (Applicative f, Applicative g) => Applicative (C f g) where 
    pure = C . pure . pure 
    C fgf <*> C fgx = C (liftA2 (<*>) fgf fgx) 

Darüber hinaus ist alle Monaden sind applicatives so sollten wir in der Lage sein, diesen Code wiederverwenden. Leider zwingt das Fehlen von Subtyping von Applicative-Monad dazu, dass monadischer Code mehr Ausgrenzung erfordert als nötig und damit einen solchen Code verbietet. Es hätte korrigiert werden können, wenn alle diese Bibliotheken nach einer (Applicative m, Monad m) Einschränkung fragen würden, aber das tun sie nicht. Darüber hinaus, wie oft Sie sonst schreiben müssten

(MonadReader m, Monad m) => ... 

die Monad Superklasse Einschränkung ist bequem. Ich bin mir nicht sicher, dass es aber absolut notwendig ist.