🕕 👨🏻‍⚕️ 💂🏼 बिना साधुओं के हास्केल 💆🏽 ☪️ 🎈

कोई भी प्रोग्रामर जो हेकेल का अध्ययन करता है, वह जल्द ही या बाद में एक सन्यासी के रूप में इस तरह की एक अतुलनीय अवधारणा के पार आएगा। कई लोगों के लिए, भाषा का परिचय भिक्षुओं से होता है। कई मोनाड गाइड हैं, और नए लगातार दिखाई दे रहे हैं (1)। जो कुछ लोग भिक्षुओं को समझते हैं, वे ध्यान से अपने ज्ञान को छिपाते हैं, जो अंतोदय और प्राकृतिक परिवर्तनों (2) के संदर्भ में भिक्षुओं को समझाते हैं। कोई भी अनुभवी प्रोग्रामर दुनिया की अपनी स्थापित तस्वीर में भिक्षुओं के लिए जगह नहीं पा सकता है।

नतीजतन, जावा प्रोग्रामर्स केवल हास्केल में चकली करते हैं, अपने मिलियन-लाइन एंटरप्राइज प्रोजेक्ट से नहीं। सी ++ डेवलपर्स अपने सुपर-फास्ट एप्लिकेशन को पैच करते हैं और यहां तक कि अधिक चालाक बिंदुओं के साथ आते हैं। वेब डेवलपर्स सीएसएस, एक्सएमएल और जावास्क्रिप्ट के लिए उदाहरणों और विशाल विनिर्देशों के माध्यम से छोड़ते हैं। और जो लोग अपने खाली समय में हैस्केल का अध्ययन करते हैं, उन्हें एक अजेय बाधा के साथ सामना करना पड़ता है जिसे मोनाड्स कहा जाता है।

इसलिए, हम सीखेंगे कि बिना साधुओं के हास्केल में कैसे कार्यक्रम किया जाए।

ऐसा करने के लिए, हमें थोड़ा खाली समय, एक अच्छी रात की नींद, हमारे पसंदीदा पेय का एक मग और ghc संकलक चाहिए। विंडोज़ और मैकोस में, यह हैसेल प्लेटफॉर्म (3) पैकेज में पाया जा सकता है, लिनक्स उपयोगकर्ता रिपॉजिटरी से ghc इंस्टॉल कर सकते हैं। Prelude> से शुरू होने वाले नमूना कोड को इंटरएक्टिव इंटरप्रेटर ghci में जांचा जा सकता है।

हब (4) पर पहले से ही एक समान लेख था, हालांकि यह इनपुट-आउटपुट के सभी आईएनएस और बहिष्कार की व्याख्या नहीं करता है, लेकिन बस उपयोग के लिए तैयार टेम्पलेट प्रदान करता है।

अगले चरण पर जाएं - ऑपरेटर

चलो शुरू से। हास्केल में सभी गणना "साइड इफेक्ट्स" और "साइड इफेक्ट्स के बिना" में विभाजित थे। पहले में शामिल हैं, उदाहरण के लिए, इनपुट / आउटपुट उपकरणों से लिखना / पढ़ना, बीच में कहीं त्रुटि की संभावना के साथ गणना, आदि। "कोई साइड इफेक्ट" में संख्याओं को जोड़ना, स्ट्रिंग्स को किसी भी गणितीय गणना - किसी भी "शुद्ध" कार्यों जैसे संचालन शामिल हैं।

शुद्ध कार्य उसी तरह से संयोजित होते हैं जैसे अन्य सभी प्रोग्रामिंग भाषाओं में कार्य करते हैं:

Prelude> show (head (show ((1 + 1) -2))) '0'

साइड इफेक्ट्स वाले कार्यक्रम बनाने के लिए, एक विशेष ऑपरेटर बनाया गया था

>>=

चलो इसे "कनेक्ट" कहते हैं (संलग्न। बाइंड)। सभी I / O क्रियाएँ उनसे चिपकी हुई हैं:

 Prelude> getLine >>= putStrLn asdf asdf

यह ऑपरेटर इनपुट के रूप में दुष्प्रभावों के साथ 2 कार्यों को स्वीकार करता है, और बाएं फ़ंक्शन का आउटपुट दाईं ओर इनपुट के रूप में कार्य करता है।

आइए दुभाषिए के कमांड के प्रकारों को देखें: t:

 Prelude> :t getLine getLine :: IO String Prelude> :t putStrLn putStrLn :: String -> IO ()

तो गेटलाइन कुछ भी स्वीकार नहीं करता है, और एक IO स्ट्रिंग प्रकार लौटाता है।

तथ्य यह है कि टाइप नाम में 2 शब्द हैं, यह दर्शाता है कि यह प्रकार संयुक्त है। और जो शब्द पहले आता है, हम टाइप बिल्डर को कॉल करेंगे, और बाकी सब इस बिल्डर के पैरामीटर हैं (मुझे पता है कि क्या असंगत लगता है, लेकिन ऐसा होना चाहिए)।

इस स्थिति में, IO शब्द का अर्थ केवल साइड इफेक्ट है, और इसे ऑपरेटर = द्वारा त्याग दिया जाता है। साइड इफेक्ट्स के अन्य "संकेतकों" के एक उदाहरण के रूप में, हम लोकप्रिय प्रकार के राज्य का हवाला दे सकते हैं, जिसका अर्थ है कि एक फ़ंक्शन में किसी प्रकार का राज्य है।

चलो putStrLn पर चलते हैं। फ़ंक्शन इनपुट के रूप में एक स्ट्रिंग लेता है, और IO () लौटाता है। IO के साथ, सबकुछ स्पष्ट है, एक साइड इफेक्ट, और () सिससल शून्य का एक हास्केल एनालॉग है। यानी फ़ंक्शन इनपुट / आउटपुट के साथ कुछ करता है और एक खाली मान देता है। वैसे, सभी हास्केल कार्यक्रम इस बहुत ही IO () के साथ समाप्त होने चाहिए।

तो, "कनेक्ट" ऑपरेटर अपने परिणाम को पहले तर्क से लेता है, साइड इफेक्ट इंडिकेटर को काटता है और पास होता है जो इसके दूसरे तर्क में हुआ। यह जटिल लगता है, लेकिन हास्केल का आधा हिस्सा इस एकल कथन पर समर्थित है, सभी इनपुट / आउटपुट को इसका उपयोग करके प्रोग्राम किया जाता है। यह इतना महत्वपूर्ण है कि इसे भाषा के लोगो में भी जोड़ा गया था।

क्या होगा अगर चिपके कार्यों के लौटे और स्वीकृत मूल्य मेल नहीं खाते हैं? लाम्बा के कार्य बचाव में आते हैं। उदाहरण के लिए, हम केवल एक पैरामीटर को इनपुट के रूप में स्वीकार करते हैं, लेकिन इसके साथ कुछ भी नहीं करते हैं:

 Prelude> (putStrLn " 1") >>= (\a -> putStrLn " 2") >>= (\b -> putStrLn " 3")  1  2  3

आगे देखते हुए, मैं कहूंगा कि "=" ऑपरेटर की बहुत कम प्राथमिकता है और, यदि वांछित है, तो इस उदाहरण में आप बिना कोष्ठक के कर सकते हैं। इसके अलावा, यदि लैंबडा फ़ंक्शन के अंदर तर्क का उपयोग नहीं किया जाता है, जैसा कि हमारे उदाहरण में, आप इसे _ से बदल सकते हैं।

चलो पहले उदाहरण को पूरी तरह से समकक्ष होने के लिए फिर से लिखते हैं, लेकिन लंबो फ़ंक्शन का उपयोग करते हुए:

 Prelude> getLine >>= \a -> putStrLn a asdf asdf

स्क्रीन पर एक स्ट्रिंग प्रदर्शित करते समय, लंबो फ़ंक्शन का उपयोग करते हुए, हमने अब स्पष्ट रूप से संकेत दिया कि हम एक चर को स्वीकार कर रहे थे और स्पष्ट रूप से लिखा था कि हम इसका उपयोग कैसे करते हैं।

क्या आपने "परिवर्तनशील" कहा था?

जी हां, अब बात करते हैं चरों की। जैसा कि आप जानते हैं, हास्केल में कोई चर नहीं हैं। हालाँकि, यदि आप किसी सूची को देखते हैं, तो आपको कई असाइनमेंट दिखाई देंगे।

ऊपर दिए गए कोड में, ए और बी चर के समान हैं। उन्हें अन्य भाषाओं की तरह भी संदर्भित किया जा सकता है। हालांकि, ये ए और बी अनिवार्य भाषाओं में चर से काफी अलग हैं।

सभी अनिवार्य प्रोग्रामिंग भाषाओं में, एक चर स्मृति का एक नामित क्षेत्र है। हास्केल में, ए और बी जैसी चीजों को अभिव्यक्ति और मूल्यों का नाम दिया गया है।

हम एक उदाहरण देते हैं और इन अंतरों को दिखाते हैं। निम्नलिखित सी कोड पर विचार करें:

 a = 1; a = a + 1; printf("%d",a)

सब कुछ क्रिस्टल स्पष्ट है और परिणाम अनुमानित है।

अब हास्केल पर भी ऐसा ही करें:

 Prelude> let a = 1 Prelude> let a = a + 1 Prelude> print a ^CInterrupted.

कोड निष्पादन कभी समाप्त नहीं होता है। पहली पंक्ति में, हम एक के रूप में परिभाषित करते हैं। दूसरी पंक्ति में, हम एक + 1 के रूप में परिभाषित करते हैं। दूसरी पंक्ति को पढ़ते समय, दुभाषिया एक के पिछले मूल्य को भूल जाता है, और फिर से, इस मामले में, खुद के माध्यम से निर्धारित करता है। खैर, इस पुनरावर्ती परिभाषा की गणना कभी नहीं की जाएगी।

स्मृति के नामित क्षेत्रों के लिए - वे हास्केल में हैं, लेकिन यह एक पूरी तरह से अलग कहानी है।

इस डिज़ाइन का उपयोग करके, आप "कनेक्ट" ऑपरेटर के कई कॉल के माध्यम से पैरामीटर पास कर सकते हैं:

 Prelude> getLine >>= \a -> putStrLn " :" >>= \_ -> putStrLn a asdf  : asdf

असली कोड

अब अपने गुप्त ज्ञान का उपयोग करके हम कुछ वास्तविक लिखेंगे। अर्थात्, एक प्रोग्राम जो उपयोगकर्ता से डेटा प्राप्त करता है, उन पर कुछ कार्य करता है और स्क्रीन पर परिणाम प्रदर्शित करता है। हम प्रोग्राम को लिखेंगे क्योंकि यह एक अलग फाइल में होना चाहिए और इसे मशीन कोड में संकलित करना चाहिए।

फ़ाइल का नाम बताएं।

 main = putStrLn "  :" >>= \_ ->       getLine >>= \a ->       putStrLn "   :" >>= \_ ->       putStrLn (show ((read a)^2))

संकलन:

 ghc --make test.hs

चलाएँ:

 $ ./test   : 12    : 144

पढ़ा गया फ़ंक्शन वांछित प्रकार के मान में स्ट्रिंग को पार्स करने का प्रयास करता है। वह खुद किस प्रकार का अनुमान लगाती है यह एक अलग कहानी है। शो फ़ंक्शन किसी भी प्रकार के मान को स्ट्रिंग में परिवर्तित करता है।

रीड फ़ंक्शन सुरक्षित नहीं है, अगर हम इसे अक्षर देते हैं और इसे एक नंबर पार्स करने के लिए कहते हैं, तो एक त्रुटि होगी। हम इस पर ध्यान नहीं देंगे, मैं केवल यह उल्लेख करूंगा कि इस मामले के लिए एक सुरक्षित मॉड्यूल है।

पवित्रता का प्रवेश

अलग-अलग, सवाल उठता है कि साइड-इफेक्ट कोड से शुद्ध कार्यों को कैसे कॉल किया जाए।

उपरोक्त उदाहरण में, एक शुद्ध फ़ंक्शन को IO फ़ंक्शन के तर्क के रूप में लिखा गया है। अक्सर यह पर्याप्त है, लेकिन हमेशा नहीं।

क्लीन कोड को कॉल करने के अन्य तरीके हैं।

इनमें से पहला साफ कोड के हिंसक रूपांतरण को साइड-इफेक्ट कोड में बदलना है। वास्तव में, शुद्ध कोड को साइड-इफेक्ट का एक विशेष मामला माना जा सकता है, इसलिए यह रूपांतरण किसी भी खतरे को उत्पन्न नहीं करता है। और यह रिटर्न फ़ंक्शन का उपयोग करके कार्यान्वित किया जाता है:

 main = putStrLn "  :" >>= \_ ->       getLine >>= \a ->       putStrLn "   :" >>= \_ ->       return (show ((read a)^2)) >>= \b ->       putStrLn b

हम संकलन, सत्यापन, कार्यक्रम पहले की तरह काम करते हैं।

एक और तरीका यह है कि हम ... Haskel निर्माण का उपयोग करें। कई मैनुअल में, इस पर पर्याप्त ध्यान दिया जाता है, इसलिए हमने इस पर रोक नहीं लगाई है, मैं आपको एक तैयार उदाहरण देता हूं:

 main = putStrLn "  :" >>= \_ ->       getLine >>= \a ->       putStrLn "   :" >>= \_ ->       let b = (show ((read a)^2)) in       putStrLn b

अधिक चीनी की आवश्यकता है

भाषा डेवलपर्स ने देखा है कि निर्माण आम हैं

 >>= \_ ->

इसलिए, उन्हें निरूपित करने के लिए, हमने ऑपरेटर का परिचय दिया

>>

हमारे कोड को फिर से लिखें:

 main = putStrLn "  :" >>       getLine >>= \a ->       putStrLn "   :" >>       let b = (show ((read a)^2)) in       putStrLn b

तो यह थोड़ा और सुंदर हो गया।

लेकिन एक कूलर ट्रिक है - सिंटैक्टिक शुगर "डू" :

 main = do    putStrLn "  :"    a <- getLine    putStrLn "   :"    let b = (show ((read a)^2))    putStrLn b

आपको क्या चाहिए! तो आप पहले से ही रह सकते हैं।

एक ब्लॉक के अंदर, बाएं औचित्य तक सीमित, निम्नलिखित प्रतिस्थापन होते हैं:

 a <- abc   abc >>= \a -> abc   abc >> let a = b   let a = b in do

"डू" अंकन सिंटैक्स को सभी आधुनिक प्रोग्रामिंग भाषाओं के सिंटैक्स के समान बनाता है। फिर भी, हुड के तहत, स्वच्छ और साइड-इफ़ेक्ट कोड को अलग करने के लिए एक सुविचारित तंत्र है।

एक दिलचस्प अंतर रिटर्न स्टेटमेंट का उपयोग है। इसे ब्लॉक के बीच में डाला जा सकता है, और यह फ़ंक्शन के निष्पादन को बाधित नहीं करेगा, जिससे घबराहट हो सकती है। लेकिन वास्तव में, इसका उपयोग अक्सर IO फ़ंक्शन से शुद्ध मान लौटाने के लिए एक ब्लॉक के अंत में किया जाता है:

 get2LinesAndConcat:: IO String get2LinesAndConcat = do    a <- getLine    b <- getLine    return (a + b)

एक निर्वात में क्षेत्र

अब हम एक अलग फ़ंक्शन में अपना साफ कोड निकालते हैं। और एक ही समय में, आखिरकार लापता प्रकार के हस्ताक्षर की व्यवस्था करें।

 main :: IO () main = do    putStrLn "  :"    a <- getLine    putStrLn "   :"    let b = processValue (read a)    putStrLn (show b) processValue :: Integer -> Integer processValue a = a ^ 2

महत्वपूर्ण बिंदु यह है कि साइड-इफेक्ट I / O कोड केवल I / O कोड से चलाया जा सकता है। हालाँकि, क्लीन कोड कहीं से भी चल सकता है।

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

शैलीगत मार्गदर्शिकाओं में, साइड-इफ़ेक्ट कोड के उपयोग को कम करने और शुद्ध कार्यों (5) में अधिकतम कार्यक्षमता लाने की सिफारिश की गई है। हालाँकि, यदि प्रोग्राम I / O करने के लिए डिज़ाइन किया गया है, तो आपको जहाँ भी ज़रूरत हो, इसका उपयोग करने से बचना चाहिए। एक नियम के रूप में, ऐसे मामलों में सहायक कार्यों की आवश्यकता होती है, जो शुद्ध हो सकते हैं। अनुभवी हास्केल प्रोग्रामर अनिवार्य भाषाओं की तुलना में यहां तक कि IO कोड के उत्कृष्ट समर्थन को पहचानते हैं (बयान साइमन पेटन जॉन्स के लिए जिम्मेदार है, लेकिन कोई सीधा लिंक नहीं मिला था)।

शुद्ध कार्यों के प्रदर्शन का एक पहलू है। चलो एक उत्कृष्ट उदाहरण लेते हैं, फ़ंक्शन के लिए कई क्षेत्रों के साथ एक जटिल "कर्मचारी" संरचना पास करते हैं। तो, सी के साथ सादृश्य द्वारा, कोड की दक्षता सूचक द्वारा इस पैरामीटर को पारित करने के लिए तुलनीय होगी, और विश्वसनीयता स्टैक के माध्यम से पैरामीटर को पारित करने के लिए तुलनीय है, क्योंकि सी में केवल स्टैक से गुजरना मूल संरचना की प्रतिरक्षा की गारंटी देता है।

क्या बात कर रहे हो

"यह कोड भयानक है, यह अनुचित रूप से जटिल है, अन्य सभी भाषाओं के गर्म ट्यूब शब्दार्थ के साथ बहुत कम है, c / c ++ / c # / java / python आदि किसी भी उद्देश्य के लिए पर्याप्त है।"

खैर, इसमें कुछ सच्चाई है। यहां आपको यह तय करने की आवश्यकता है कि आपको क्या लगता है भयानक है: स्वच्छ कोड से साइड इफेक्ट्स को अलग करना या इस तंत्र का एक विशिष्ट कार्यान्वयन।

यदि आप जानते हैं कि इस तरह के तंत्र को कैसे सरल और अधिक समझने योग्य है, तो कृपया विश्व समुदाय को इसके बारे में बताएं! हास्केल समुदाय बहुत खुला और मैत्रीपूर्ण है। नए मानक का मसौदा, जो नियमित रूप से अपनाया जाता है, किसी भी प्रस्ताव पर विचार करता है, और यदि वे वास्तव में सार्थक हैं, तो वे निश्चित रूप से स्वीकार किए जाएंगे।

यदि आपको लगता है कि "अजगर में भी सब कुछ अच्छा है, तो आप अपने दुष्प्रभावों से जुड़े हुए हैं!", कोई भी आपको उस टूल का उपयोग करने से परेशान नहीं करता है जो आपको पसंद है। अपने आप से, मैं यह जोड़ सकता हूं कि हास्केल वास्तव में विकास को सरल बनाता है और कोड को अधिक समझ में आता है। इसे या इसके विपरीत सत्यापित करने का एकमात्र तरीका हास्केल में लिखने की कोशिश करना है!

आगे कहाँ जाना है

आगे के अध्ययन के लिए, ~~या इस लेख के बजाय,~~ हम ~~इस लेख~~ की सिफारिश कर सकते हैं "हैस्केल से नरम परिचय" (6), और विशेष रूप से इसका अनुवाद (7)।

इसके अलावा, ज़ाहिर है, कोई अन्य लेख उपयुक्त हैं (8)। बहुत सारे गाइड लिखे गए हैं, लेकिन वे सभी अलग-अलग दृष्टिकोणों से समान चीजों को समझाते हैं। दुर्भाग्य से, रूसी में बहुत कम जानकारी का अनुवाद किया गया है। मैनुअल की प्रचुरता के बावजूद, भाषा सरल है, मानक पुस्तकालयों के विवरण के साथ इसका विवरण केवल 270 पृष्ठ (9) लेता है।

बहुत सारी जानकारी मानक पुस्तकालयों के लिए दस्तावेज में भी निहित है (10)।

मुझे खुशी होगी अगर लेख किसी की मदद करता है या सिर्फ दिलचस्प लगता है, टिप्पणियों और आलोचना का स्वागत है।

Ps जिसे मैंने हास्केल दुनिया में "टाइप बिल्डर" कहा जाता है, उसे " टाइप कंस्ट्रक्टर " कहा जाता है। यह ओओपी से लिया गया "डिजाइनर" शब्द के अर्थ को भूलना आसान बनाने के लिए किया जाता है, ये पूरी तरह से अलग चीजें हैं। स्थिति इस तथ्य से जटिल है कि प्रकार के निर्माणकर्ताओं के अलावा, ऐसे डेटा निर्माता भी हैं जिनका ओओपी से कोई लेना-देना नहीं है।

संदर्भ

अपडेट: (SPOILER!)

जैसा कि मुझे टिप्पणियों में सही ढंग से संकेत दिया गया था, मोनड्स पर मैनुअल के लिए नाम का विकल्प पूरी तरह से सफल नहीं है। चूंकि भिक्षुओं के विषय का खुलासा नहीं किया गया है, इसलिए समझ की भावना बनी हुई है।

तो, शब्द "मोनाड" ऑपरेटरों का एक सेट है

 >>= >> return fail

और किसी भी प्रकार का डेटा जिस पर वे परिभाषित हैं। उदाहरण के लिए, आईओ।

इस शब्द के आसपास, एक बहुत अच्छी आभा विकसित नहीं हुई है, लेकिन वास्तव में इसका कोई गुप्त अर्थ नहीं है। यह बस एक प्रोग्रामिंग पैटर्न का नाम है, जिसे बिना मोनाड के समझाया जा सकता है।

upd2:
अफिसन ने एक दिलचस्प प्रस्तुति का लिंक दिया
हास्केल के बारे में ।

बिना साधुओं के हास्केल