Dlaczego istnieją typy WrappedMonad i WrappedArrow? Czy to dlatego, że Monad s nie były Applicative? Biorąc pod uwagę, że WrappedArrow istnieje, powinien instancjaDlaczego owiniętyMonad i owinięty?
Arrow a => Applicative (Arrow a b)
prostu być wbudowana w sam Haskell w ten sam sposób, że Applicative jest teraz nadklasą Monad?
Niemal tak za WrappedMonad. Myślę, że staje się (i być może już) w gruncie rzeczy przestarzałe. Ale WrappedArrow jest trudniejsze, ponieważ typy Arrow i Applicative mają różne rodzaje, * -> * -> * vs. * -> *. I ze względu na sposób rozdzielczość instancja GHC pracuje, dodając wystąpienie (zakładam dodatkowy Arrow była literówka)
instance Arrow a => Applicative (a b)
oznaczałoby, że żaden konstruktor typ z dwoma lub więcej argumentów może następnie otrzymując Applicative bez jednoczesnego dając Arrow - wydaje się to dość drastyczne.
Opcja odwrotna polegająca na dodaniu superklasy Applicative (a b) => do Arrow a wydaje się bardziej smaczna - z wyjątkiem tego, że nie można mieć nadklas z typem forall, takim jak b. Takie superklasy byłyby użyteczne również w innych sprawach i zostały zasugerowane wiele razy, więc zakładam, że trudno jest je dobrze wdrożyć.
Jest również tak, że większość ludzi uważa, że klasa "Arrow" jest źle zaprojektowana, więc sprawienie, by była superklasą niezwykle ważnej klasy "Applicative" prawdopodobnie nie przejdzie tak dobrze. – dfeuer
Podklasa @dfeuer, nie nadklasy. Nie miałoby to bezpośredniego wpływu na 'Applicative'. Wciąż nie jest to możliwe w obecnym systemie klasy. –
Ah, brakuje mi twojego punktu, tak myślę. – dfeuer