MonadPlus और Monoid विभिन्न उद्देश्यों को पूरा करता है।
ए Monoid एक प्रकार के * पर पैरामीटरकृत है।
class Monoid m where
mempty :: m
mappend :: m -> m -> m
और इसलिए इसे लगभग किसी भी प्रकार के लिए तत्काल किया जा सकता है जिसके लिए एक स्पष्ट ऑपरेटर है जो सहयोगी है और जिसमें एक इकाई है।
हालांकि, MonadPlus न केवल निर्दिष्ट करता है कि आप एक monoidal संरचना है, लेकिन यह भी है कि उस संरचना कैसे Monad काम करता है, और कि कि संरचना इकाई में निहित मूल्य के बारे में परवाह नहीं है से संबंधित है, यह है कि (भाग में) इस तथ्य से संकेत मिलता है कि MonadPlus दयालु * -> * का तर्क लेता है।
class Monad m => MonadPlus m where
mzero :: m a
mplus :: m a -> m a -> m a
monoid कानूनों के अलावा, हम कानूनों के दो संभावित सेट हम MonadPlus लिए आवेदन कर सकते है। अफसोस की बात है कि समुदाय इस बात से असहमत है कि उन्हें क्या होना चाहिए।
कम से कम हम
mzero >>= k = mzero
जानते हैं, लेकिन वहाँ दो अन्य प्रतिस्पर्धी एक्सटेंशन, बाएं (sic) वितरण कानून
mplus a b >>= k = mplus (a >>= k) (b >>= k)
और छोड़ दिया पकड़ कानून हैं
mplus (return a) b = return a
तो MonadPlus के किसी भी उदाहरण को इन अतिरिक्त कानूनों में से एक या दोनों को संतुष्ट करना चाहिए।
तो Alternative के बारे में क्या?
ApplicativeMonad के बाद परिभाषित किया गया था, और तार्किक Monad की एक सुपर क्लास के रूप में है, लेकिन मोटे तौर पर डिजाइनरों हास्केल 98 में पीठ पर विभिन्न दबावों के कारण, यहां तक कि Functor नहीं Monad 2015 तक की एक सुपर क्लास अब हम अंत में था Applicative
प्रभावी ढंग से, AlternativeApplicative क्या MonadPlusMonad है करने के लिए है (एक भाषा मानक में अभी तक नहीं तो।) GHC में Monad की एक सुपर क्लास के रूप में की है।
इन के लिए हम क्या हम MonadPlus साथ संबंध के लिए
empty <*> m = empty
तुलनात्मक रूप से प्राप्त होता है और इसी तरह के वितरण और पकड़ गुण हैं, जिनमें से कम से कम एक आप को पूरा करना चाहिए वहाँ मौजूद हैं।
दुर्भाग्यवश, यहां तक कि empty <*> m = empty कानून भी एक दावा है। उदाहरण के लिए, यह Backwards के लिए नहीं है!
जब हम मोनाडप्लस को देखते हैं, तो खाली >> = f = खाली कानून लगभग हमारे लिए मजबूर होता है। रिक्त निर्माण में किसी भी तरह से 'f फ़ंक्शन को कॉल करने के लिए कोई भी नहीं है।
हालांकि, Applicative के बाद से नहीं है Monad और Alternative की एक सुपर क्लास MonadPlus की एक सुपर क्लास, हम अलग से दोनों मामलों को परिभाषित हवा नहीं है।
इसके अलावा, भले ApplicativeMonad की एक सुपर क्लास था, तो आप वैसे भी MonadPlus वर्ग की आवश्यकता होगी, हवा चाहते हैं, क्योंकि भले ही हम का पालन करना था
empty <*> m = empty
कि सख्ती कि
साबित करने के लिए पर्याप्त नहीं है
empty >>= f = empty
तो दावा करते हुए कि MonadPlus कुछ दावा है कि यह Alternative है।
अब, प्रथा के अनुसार, MonadPlus और Alternative एक दिया प्रकार के लिए सहमत होना चाहिए, लेकिन Monoidपूरी तरह से अलग हो सकता है।
उदाहरण के लिए MonadPlus और AlternativeMaybe के लिए स्पष्ट काम करते हैं:
instance MonadPlus Maybe where
mzero = Nothing
mplus (Just a) _ = Just a
mplus _ mb = mb
लेकिन Monoid उदाहरण एक Monoid में एक semigroup लिफ्टों। अफसोस की बात है क्योंकि हास्केल 98 में उस समय Semigroup वर्ग मौजूद नहीं था, यह Monoid को पुनः प्राप्त करके ऐसा करता है, लेकिन इसकी इकाई का उपयोग नहीं करता है।ಠ_ಠ
instance Monoid a => Monoid (Maybe a) where
mempty = Nothing
mappend (Just a) (Just b) = Just (mappend a b)
mappend Nothing x = x
mappend x Nothing = x
mappend Nothing Nothing = Nothing
टी एल; डॉMonadPlusAlternative तुलना में मजबूत दावा, जो बारी में Monoid तुलना में मजबूत दावा है, और जब एक प्रकार के लिए MonadPlus और Alternative उदाहरणों से संबंधित होना चाहिए, Monoid हो सकता है (और कभी-कभी) कुछ पूरी तरह से अलग है।
यह एक अच्छा सवाल है। विशेष रूप से, 'आवेदक' और 'मोनाडप्लस' बिल्कुल * वही * (मॉड्यूल सुपरक्लस बाधाएं) प्रतीत होता है। – Peter
तीरों के लिए 'एरोझेरो' और 'एरोप्लस' भी है। मेरी शर्त: प्रकार हस्ताक्षर क्लीनर बनाने के लिए (जो अलग सुपरक्लास बाधाओं * वास्तविक अंतर बनाता है)। –
@ कैटप्लसप्लस: ठीक है, 'एरोझेरो' और 'एरोप्लस' में दयालु '* -> * -> *' है, जिसका अर्थ है कि आप उन्हें एक फ़ंक्शन के लिए तीर प्रकार के लिए पास कर सकते हैं जिसे उन्हें कई प्रकार के लिए उपयोग करने की आवश्यकता होती है , 'मोनॉयड' का उपयोग करने के लिए आपको प्रत्येक विशेष तत्कालता के लिए 'मोनॉयड' के उदाहरण की आवश्यकता होगी, और आपको कोई गारंटी नहीं होगी कि उन्हें उसी तरह से संभाला गया था, उदाहरण असंबंधित हो सकते हैं! –