मोनैड को आईओ से निपटने के लिए हैकेल समाधान के रूप में वर्णित किया गया है। मैं सोच रहा था कि शुद्ध कार्यात्मक भाषा में आईओ से निपटने के अन्य तरीके हैं या नहीं।शुद्ध कार्यात्मक प्रोग्रामिंग में आईओ का उपयोग करने के लिए मोनैड का विकल्प क्या है?
क्या विकल्प एक शुद्ध कार्यात्मक भाषा में आई/ओ के लिए monads को देखते हैं?
मैं साहित्य में दो विकल्पों के बारे में पता कर रहा हूँ:
एक एक तथाकथित रैखिक प्रकार प्रणाली है। विचार यह है कि रैखिक प्रकार का मान बिल्कुल एक बार उपयोग किया जाना चाहिए: आप इसे अनदेखा नहीं कर सकते हैं, और आप इसे दो बार उपयोग नहीं कर सकते हैं। इस विचार को ध्यान में रखते हुए, आप दुनिया की स्थिति को एक सार प्रकार (उदा।, World) देते हैं, और आप इसे रैखिक बनाते हैं। यदि मैं एक स्टार के साथ रैखिक प्रकारों को चिह्नित करता हूं, तो यहां कुछ I/O संचालन के प्रकार हैं:
getChar :: World* -> (Char, World*)
putChar :: Char -> World* -> World*
और इसी तरह। कंपाइलर यह सुनिश्चित करने के लिए व्यवस्थित करता है कि आप कभी भी दुनिया की प्रतिलिपि नहीं बनाते हैं, और फिर यह उस कोड को संकलित करने की व्यवस्था कर सकता है जो दुनिया को अद्यतन करता है, जो सुरक्षित है क्योंकि केवल एक प्रति है।
भाषा Clean भाषा में विशिष्टता टाइपिंग रैखिकता पर आधारित है।
इस प्रणाली में कुछ फायदे हैं; विशेष रूप से, यह मोनैड की घटनाओं पर कुल क्रम को लागू नहीं करता है। यह "IO पाप बिन" से बचने के लिए भी जाता है, जिसे आप हास्केल में देखते हैं, जहां सभी प्रभावशाली गणना IO मोनैड में फेंक दी जाती है और वे सभी पूरी तरह से आदेश देते हैं कि आप कुल आदेश चाहते हैं या नहीं।
अन्य प्रणाली मैं पहले का है monads के बारे में पता है और स्वच्छ और विचार पर आधारित है कि एक इंटरैक्टिव कार्यक्रम (संभवत: अनंत) अनुरोध (संभवत: अनंत) के अनुक्रम के के अनुक्रम से एक समारोह है कर रहा हूँ प्रतिक्रिया। इस प्रणाली, जिसे "संवाद" कहा जाता था, कार्यक्रम के लिए शुद्ध नरक था। कोई भी इसे याद नहीं करता है, और इसमें विशेष रूप से इसकी सिफारिश करने के लिए कुछ भी नहीं था। इसके दोषों को the paper that introduced monadic I/O (Imperative Functional Programming) में वैडलर और पेटन जोन्स द्वारा अच्छी तरह से समझाया गया है। इस पेपर में निरंतरता के आधार पर एक आई/ओ प्रणाली का भी उल्लेख किया गया है जिसे येल हास्केल समूह द्वारा पेश किया गया था, लेकिन जो अल्पकालिक था।
विशिष्टता टाइपिंग हैं "शुद्ध" क्या आपका मतलब है "referentially पारदर्शी" द्वारा, वह है, और Clean
में प्रयोग किया जाता है एक व्यावहारिक समारोह इसके का मूल्यांकन परिणाम के साथ स्वतंत्र रूप से परस्पर विनिमय है कि (इसलिए है कि एक ही साथ एक समारोह बुला तर्कों का हर बार एक ही परिणाम होता है), राज्यव्यापी आईओ की किसी भी अवधारणा को परिभाषा से काफी दूर रखा जाता है।
दो किसी न किसी रणनीति है कि मैं के बारे में पता कर रहा हूँ रहे हैं:
एक समारोह चलो आईओ करते हैं, लेकिन यकीन है कि यह दो बार ठीक उसी तर्क के साथ कभी नहीं कहा जा सकता है; इस पक्ष को कार्य को छोटे पैमाने पर "संदर्भित पारदर्शी" देकर समस्या को हल करता है।
संपूर्ण कार्यक्रम को एक शुद्ध शुद्ध कार्य के रूप में "सभी इनपुट प्राप्त" लेने के लिए एक तर्क के रूप में और "उत्पादन के सभी आउटपुट" को वापस लेते हुए, दोनों आलसी प्रवाह की अनुमति देने के लिए आलसी धारा के कुछ रूपों के प्रतिनिधित्व के साथ व्यवहार करें।
वहाँ दोनों दृष्टिकोण, साथ ही ओवरलैप के कुछ डिग्री लागू करने के तरीकों की एक किस्म है - जैसे, दूसरे मामले में, कार्यों मैं पर काम/ओ धाराओं के साथ दो बार कहा जा की संभावना नहीं है धारा का एक ही हिस्सा। इसे देखने का कौन सा तरीका अधिक समझ में आता है इस पर निर्भर करता है कि भाषा आपको किस प्रकार का समर्थन देती है।
हास्केल में, IO इकाई का एक प्रकार है कि स्वचालित रूप से कोड के माध्यम से अनुक्रमिक राज्य थ्रेड्स (कार्यात्मक शुद्ध State इकाई के समान) है, ऐसा है कि, धारणात्मक, एक अन्यथा अशुद्ध कार्य करने के लिए प्रत्येक कॉल अंतर्निहित का एक अलग मूल्य हो जाता है "बाहरी दुनिया की स्थिति"।
अन्य लोकप्रिय दृष्टिकोण जो मुझे पता है, linear types जैसे कुछ समान उपयोग करता है; यह सुनिश्चित करना कि अशुद्ध कार्यों को कभी भी वही तर्क प्राप्त नहीं होते हैं जिनकी प्रतिलिपि या नकल नहीं की जा सकती है, ताकि "बाहरी दुनिया की स्थिति" के पुराने मूल्यों को चारों ओर रखा जा सके और पुन: उपयोग नहीं किया जा सके।
Imperative Functional Programming पेटन जोन्स और वाडलर द्वारा यदि आप कार्यात्मक आईओ में रूचि रखते हैं तो इसे पढ़ना आवश्यक है। दूसरे दृष्टिकोण है कि वे के बारे में बात कर रहे हैं:
type Dialogue = [Response] -> [Request]
main :: Dialogue
निरंतरता - प्रत्येक IO आपरेशन एक निरंतरता लेता है तर्क के रूप में
रैखिक प्रकार - प्रकार प्रणाली आपको इस तरह से प्रतिबंधित करती है कि आप बाहरी स्थिति की प्रतिलिपि या नष्ट नहीं कर सकते हैं, जिसका अर्थ है कि आप एक ही स्थिति के साथ दो बार फ़ंक्शन को कॉल नहीं कर सकते हैं।
रैखिक प्रकार के अलावा, वहाँ भी effect system है।
Functional Reactive Programming इसे संभालने का एक और तरीका है।
मैंने कभी "फंक्शन रिएक्टिव प्रोग्रामिंग" शब्द नहीं सुना है। क्या आप इसे "कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग" में बदल सकते हैं? महान जवाब अन्यथा। –
कोई समस्या नहीं, ध्यान देने के लिए धन्यवाद। कोई विचार नहीं कि मैंने इसे कैसे गलत लिखा है। –
मोनैड बाध्यकारी के माध्यम से अनुक्रम बहुत अधिक टाइप-चेक निरंतरता-गुजरने वाली शैली है, है ना? मेरी धारणा यह थी कि मोनैड और निरंतरताएं अधिकतर अदलाबदल योग्य होती हैं, सिवाय इसके कि निरंतरता सामान्य रूप से गर्म या * अस्पष्ट नहीं होती है। –
निरंतरता एक मोनड बनाते हैं लेकिन मोनैड निश्चित रूप से * नहीं * निरंतरताएं हैं। सीपीएस रास्ता अधिक शक्तिशाली है क्योंकि आपको चीजों की प्रतियां बनाने की अनुमति है (निरंतरता सहित!)। मोनाड्स केवल टाइप-चेकिंग की तुलना में चीजों को अधिक गंभीर रूप से प्रतिबंधित करते हैं। –
"मोनाड्स निश्चित रूप से निरंतरता नहीं हैं" - नहीं, लेकिन रिश्ते सिर्फ एक उदाहरण नहीं है। सी एफ http://lambda-the-ultimate.org/node/3235 लॉवर थ्योरीज एंड मोनाड्स, हाइलैंड एंड पावर, 2007. –