आगामी .NET 4.0

Question

में IMONAD जैसे कुछ ऐसा क्यों नहीं है ... उन सभी नए (और यदि हम आईन्यूमेरेबल की गणना करते हैं तो इतना नया नहीं है) मोनैड से संबंधित सामान?

interface IMonad<T> 
{ 
SelectMany/Bind(); 
Return/Unit(); 
} 

इससे किसी भी monadic प्रकार पर काम करने वाले कार्यों को लिखने की अनुमति होगी। या यह इतना महत्वपूर्ण नहीं है?

Answer 1

IMonad<T> के तरीकों के लिए हस्ताक्षर क्या होना चाहिए इसके बारे में सोचें। हास्केल में इकाई typeclass परिभाषित किया गया है के रूप में

class Monad m where 
    (>>=) :: m a -> (a -> m b) -> m b 
    return :: a -> m a 

यह इस सीधे एक सी # इंटरफ़ेस करने के लिए अनुवाद करने के लिए मुश्किल है, क्योंकि आप सामान्य की परिभाषा के भीतर संदर्भ के लिए विशिष्ट लागू करने उपप्रकार ("मा" या ISpecificMonad<a>) सक्षम होना चाहिए इमोनैड इंटरफेस। ठीक है, उदाहरण के लिए (उदाहरण के लिए) IEnumerable<T> सीधे IMonad<T> लागू करें, हम इमोनैड कार्यान्वयन को एक अलग ऑब्जेक्ट में फैक्टर करने का प्रयास करेंगे जिसे विशिष्ट मोनैड प्रकार के उदाहरण के साथ पारित किया जा सकता है, जिसे इसे किसी भी तरह से इलाज करने की आवश्यकता है मोनड (यह "शब्दकोश-गुजरने वाली शैली" है)। यह IMonad<TMonad> होगा और टीएमओनाड IEnumerable<T> में टी नहीं होगा, लेकिन IEnumerable<T> स्वयं होगा। लेकिन प्रतीक्षा करें - यह या तो काम नहीं कर सकता है, उदाहरण के लिए Return<T> के हस्ताक्षर हमें सेTMonad<T> पर TMonad<> के लिए प्राप्त करना है। IMonad एक काल्पनिक सी # विशेषता यह है कि हमें प्रकार कंस्ट्रक्टर्स सामान्य प्रकार पैरामीटर के रूप में (TMonad <> की तरह) का उपयोग करने की अनुमति होगी का उपयोग कर की तरह

interface IMonad<TMonad<>> { 

    TMonad<T> Unit<T>(T x); 
    TMonad<U> SelectMany<T, U>(TMonad<T> x, Func<T, TMonad<U>> f); 
} 

कुछ के रूप में परिभाषित करना होगा। लेकिन निश्चित रूप से सी # में यह सुविधा (उच्च-प्रकार का पॉलीमोर्फिज्म) नहीं है। आप रनटाइम पर टाइप कन्स्ट्रक्टर को पुनः सत्यापित कर सकते हैं (typeof(IEnumerable<>)) लेकिन उन्हें पैरामीटर दिए बिना टाइप हस्ताक्षर में संदर्भित नहीं कर सकते हैं। तो -100 अंक की बात के अलावा, इस "ठीक से" को कार्यान्वित करने के लिए केवल एक और सामान्य इंटरफ़ेस परिभाषा जोड़ने की आवश्यकता नहीं होगी, बल्कि टाइप सिस्टम में गहरी वृद्धि होगी।

यही कारण है कि इंटरफ़ेस तंत्र आदि का उपयोग करने के बजाय अपने स्वयं के प्रकारों पर क्वेरी की समझ रखने की क्षमता है (अगर वे सही हस्ताक्षर के साथ सही जादू विधि नाम हैं तो वे "जादुई रूप से काम करते हैं)

Answer 2

मोनाड्स बस .NET प्रोग्रामर के लिए महत्वपूर्ण नहीं हैं। मोनैड को जानने के बिना भी आप LINQ ढांचे का निर्माण कर सकते हैं। सबसे महत्वपूर्ण बात यह है कि यह कोई अलग नहीं दिखता है। इससे कोई फर्क नहीं पड़ता कि आप मोनैड्स (हास्केल), अभिव्यक्ति वृक्ष पुनर्लेखन (लिस्प), सेट-आधारित ऑपरेशंस (एसक्यूएल), या नए प्रकार (रूबी, पायथन) बनाने के लिए मानचित्र/कम करने के संदर्भ में सोचते हैं, अंतिम परिणाम है वही होने जा रहा है।

वास्तव में, मैं कहूंगा कि monads .NET डेवलपर्स के लिए बेकार बेकार हैं। हर बार जब मैं monads के आधार पर .NET के लिए लाइब्रेरी देखता हूं, तो यह हमेशा सी # या वीबी कोड की तुलना में अधिक वर्बोज़ और कम समझदार होता है। कारण सरल है, सी # और वीबी जैसी भाषाएं हास्केल जैसी भाषाओं की तुलना में अधिक शक्तिशाली बिल्डिंग ब्लॉक पर बनाई गई हैं।

विशेष रूप से हास्केल को सब कुछ के लिए monads का उपयोग करने की आवश्यकता है क्योंकि उनके पास सब कुछ है। लिस्पे में मैक्रोज़ या जावास्क्रिप्ट में डायनामिक टाइपिंग के लिए यह वही है। जब आपके पास एक-चाल टट्टू होती है, तो उस चाल को बहुत अच्छा होना चाहिए।

On LINQ, Monads, and the Blindness of Power