Başvuranlar beste yapar, monadlar yapmaz

Başvuranlar beste yapar, monadlar yapmaz.

Yukarıdaki ifade ne anlama geliyor? Ve ne zaman biri diğerine tercih edilir?

Türleri karşılaştırırsak

(<*>) :: Applicative a => a (s -> t) -> a s -> a t
(>>=) :: Monad m =>       m s -> (s -> m t) -> m t

iki kavramı ayıran şeyin ne olduğuna dair bir ipucu elde ederiz. Bu (s -> m t)tipinde (>>=)bir değer gösterdiği sbir hesaplama davranışını belirler m t. Monadlar, değer ve hesaplama katmanları arasında girişime izin verir. (<*>)Operatör böyle müdahaleyi sağlar: fonksiyonu ve argüman hesaplamaları değerlere bağlı olmayan. Bu gerçekten ısırıyor. Karşılaştırmak

miffy :: Monad m => m Bool -> m x -> m x -> m x
miffy mb mt mf = do
  b <- mb
  if b then mt else mf

iki hesaplama arasında karar vermek için bazı etkilerin sonucunu kullanır (örneğin füzeleri fırlatmak ve bir ateşkes imzalamak), oysa

iffy :: Applicative a => a Bool -> a x -> a x -> a x
iffy ab at af = pure cond <*> ab <*> at <*> af where
  cond b t f = if b then t else f

ki değerini kullanır abarasında seçim yapmak için değerleri iki hesaplamalar atve afbelki de trajik etkisine, hem de elde edildiğini.

Monadik versiyon, esasen (>>=)bir değerden bir hesaplama seçmenin ekstra gücüne dayanır ve bu önemli olabilir. Bununla birlikte, bu gücü desteklemek, monadların bestelenmesini zorlaştırır. 'Double-bind' oluşturmaya çalışırsak

(>>>>==) :: (Monad m, Monad n) => m (n s) -> (s -> m (n t)) -> m (n t)
mns >>>>== f = mns >>-{-m-} \ ns -> let nmnt = ns >>= (return . f) in ???

bu kadar uzağa gidiyoruz, ama şimdi katmanlarımız karmakarışık. Elimizde bir tane var n (m (n t)), bu yüzden dışardan kurtulmamız gerekiyor n. Alexandre C'nin dediği gibi, uygun bir

swap :: n (m t) -> m (n t)

sırasını değiştirmek amacıyla niçeriye ve joindiğer bunu n.

Daha zayıf 'çift uygulama' tanımlaması çok daha kolaydır

(<<**>>) :: (Applicative a, Applicative b) => a (b (s -> t)) -> a (b s) -> a (b t)
abf <<**>> abs = pure (<*>) <*> abf <*> abs

çünkü katmanlar arasında hiçbir girişim yoktur.

Buna karşılık, Monads'nin ekstra gücüne gerçekten ne zaman ihtiyacınız olduğunu ve Applicativedestekleyen katı hesaplama yapısından ne zaman kurtulabileceğinizi anlamak iyidir .

Bu arada, monadları oluşturmak zor olsa da, ihtiyacınız olandan daha fazlası olabileceğini unutmayın. Türü m (n v)ile işlem gösterir mdaha sonra işlem, -Etkileri na -Etkileri v-değeri, mdaha önce -Etkileri bitiş n-Etkileri (dolayısıyla gerek başlangıç swap). m-Efektleri -etkileri ile birleştirmek istiyorsanız n, o zaman kompozisyon sorulamayacak kadar fazla olabilir!

Başvuranlar beste yapar, monadlar yapmaz.

Monads yapmak oluşturma, ancak sonuç bir monad olmayabilir. Aksine, iki başvurunun bileşimi zorunlu olarak bir başvurudur. Orijinal açıklamanın amacının "Uygulanabilirlik oluşturur, monadlık oluşturmaz" olduğundan şüpheleniyorum. Yeniden ifade edildi, " Applicativekompozisyon altında kapalı ve kapalı Monaddeğil."

Başvuru sahipleriniz varsa A1ve A2tür data A3 a = A3 (A1 (A2 a))de geçerlidir (böyle bir örneği genel bir şekilde yazabilirsiniz).

Öte yandan, eğer monadlarınız varsa M1ve M2o zaman tipin data M3 a = M3 (M1 (M2 a))mutlaka bir monad olması gerekmez ( kompozisyon için >>=veya joinkompozisyon için mantıklı genel bir uygulama yoktur ).

Bir örnek türü olabilir [Int -> a](burada bir tür yapıcı oluşturmak []ile (->) Intmonads her ikisi de). Kolayca yazabilirsin

app :: [Int -> (a -> b)] -> [Int -> a] -> [Int -> b]
app f x = (<*>) <$> f <*> x

Ve bu, herhangi bir uygulamaya genelleşir:

app :: (Applicative f, Applicative f1) => f (f1 (a -> b)) -> f (f1 a) -> f (f1 b)

Ama mantıklı bir tanımı yok

join :: [Int -> [Int -> a]] -> [Int -> a]

Buna ikna olmadıysanız, şu ifadeyi düşünün:

join [\x -> replicate x (const ())]

Döndürülen listenin uzunluğu, bir tam sayı sağlanmadan önce sabit olarak ayarlanmalıdır, ancak doğru uzunluğu sağlanan tam sayıya bağlıdır. Bu nedenle, joinbu tür için doğru bir işlev olamaz.

Maalesef, asıl amacımız olan monadların bileşimi oldukça zor. Aslında, belli bir anlamda, sadece iki monadın işlemlerini kullanarak yukarıdaki tipte bir birleştirme işlevi oluşturmanın bir yolu olmadığını gerçekten kanıtlayabiliriz (ispatın ana hatları için eke bakın). Bir kompozisyon oluşturmayı ummamızın tek yolu, iki bileşeni birbirine bağlayan bazı ek yapılar olmasıdır.

Monadları oluşturma, http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf

Dağılım yasası çözümü l: MN -> NM yeterlidir

NM'nin monadisitesini garanti etmek için. Bunu görmek için bir birime ve bir multiye ihtiyacınız var. çokluya odaklanacağım (birim birim_ birimdir)

NMNM - l -> NNMM - mult_N mult_M -> NM

Bu mu değil MN bir monad olduğunu garanti.

Ancak önemli gözlem, dağıtım hukuku çözümlerine sahip olduğunuzda devreye girer.

l1 : ML -> LM
l2 : NL -> LN
l3 : NM -> MN

bu nedenle LM, LN ve MN monadlardır. Soru, LMN'nin bir monad olup olmadığı (ya da

(MN) L -> L (MN) veya N (LM) -> (LM) N ile

Bu haritaları yapmak için yeterli yapıya sahibiz. Bununla birlikte, Eugenia Cheng'in gözlemlediği gibi , her iki yapının monadisitesini garanti etmek için altıgen bir koşula (Yang-Baxter denkleminin bir sunumuna karşılık gelen) ihtiyacımız var. Aslında, altıgen koşulda, iki farklı monad çakışır.