क्या हास्केल वास्तव में असुरक्षित कार्यक्षमता पर विचार कर एक पूरी तरह कार्यात्मक भाषा है?

Question

हास्केल को आम तौर पर पूरी तरह कार्यात्मक भाषा के उदाहरण के रूप में संदर्भित किया जाता है। System.IO.Unsafe.unsafePerformIO के अस्तित्व के बाद इसे कैसे उचित ठहराया जा सकता है?

संपादित करें: मैंने "पूरी तरह कार्यात्मक" के साथ सोचा था कि इसका मतलब यह था कि कार्यक्रम के कार्यात्मक हिस्से में अशुद्ध कोड पेश करना असंभव है।

Answer 1

बोली हम कॉल हास्केल

unsafePerformIOविदेश समारोह इंटरफ़ेस विनिर्देश, नहीं कोर Haskell 98 विनिर्देश का हिस्सा है। इसका उपयोग स्थानीय साइड इफेक्ट्स करने के लिए किया जा सकता है जो पूरी तरह से कार्यात्मक इंटरफेस का पर्दाफाश करने के लिए कुछ गुंजाइश से बचते नहीं हैं। यही है, हम इसका उपयोग प्रभाव को छिपाने के लिए करते हैं जब टाइप चेकर हमारे लिए ऐसा नहीं कर सकता (एसटी मोनैड के विपरीत, जो स्थिर गारंटी के साथ प्रभाव छुपाता है)।

सटीक रूप से कई भाषाओं को चित्रित करने के लिए जिन्हें हम "हास्केल" कहते हैं, नीचे दी गई छवि पर विचार करें। प्रत्येक अंगूठी कम्प्यूटेशनल विशेषताओं के एक विशिष्ट सेट, सुरक्षा द्वारा आदेशित, और अभिव्यक्ति शक्ति से संबंधित क्षेत्र के साथ मेल खाती है (यानी यदि आपके पास यह सुविधा है तो प्रोग्राम की संख्या)।

हास्केल 98 के नाम से जाना जाने वाला भाषा मध्य में नीचे निर्दिष्ट है, कुल और आंशिक कार्यों को स्वीकार करता है। Agda (या Epigram), जहां केवल कुल कार्यों की अनुमति है, कम अभिव्यक्तिपूर्ण है, लेकिन "अधिक शुद्ध" और अधिक सुरक्षित है। जबकि हास्केल के रूप में हम इसका उपयोग करते हैं, आज एफएफआई में सबकुछ शामिल है, जहां असुरक्षितफॉर्मियो जी रहता है। यही है, आप आधुनिक Haskell में कुछ भी लिख सकते हैं, हालांकि यदि आप बाहरी छल्ले से चीजों का उपयोग करते हैं, तो आंतरिक सुरक्षा के लिए सुरक्षा और सुरक्षा गारंटी को सरल बनाना मुश्किल होगा।

तो, हास्केल प्रोग्रामों को आम तौर 100% referentially पारदर्शी कोड से बनाया नहीं कर रहे हैं, हालांकि, यह केवल मामूली आम भाषा शुद्ध डिफ़ॉल्ट से है।

Answer 2

भाषा/कार्यान्वयन पूरी तरह कार्यात्मक है। इसमें एक "भागने की टोपी" शामिल है, जिसे आप उपयोग नहीं करना चाहते हैं, यदि आप नहीं चाहते हैं।

Answer 3

दुर्भाग्य से भाषा को कुछ असली दुनिया का काम करना है, और इसका मतलब बाहरी पर्यावरण से बात करना है।

अच्छी बात यह है कि आप अपने "शैली के बाहर" कोड के उपयोग को सीमित कर सकते हैं (और चाहिए) अपने प्रोग्राम के कुछ विशिष्ट अच्छी तरह से प्रलेखित भागों में।

Answer 4

मैं के साथ "पूरी तरह कार्यात्मक" यह मतलब था कि यह असंभव है अशुद्ध कोड लागू करने के लिए सोचा था ...

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

मैं कैसे दुष्प्रभाव और/ओ हास्केल में फिट IO इकाई के माध्यम से की व्यापक तस्वीर के रूप में, मुझे लगता है कि सबसे आसान तरीका है हास्केल के बारे में सोचना है कि यह एक शुद्ध भाषा कि का वर्णन करता है effectful संगणना है। जब वर्णित गणना main है, तो रन-टाइम सिस्टम उन प्रभावों को ईमानदारी से करता है।

unsafePerformIO एक असुरक्षित तरीके से प्रभाव प्राप्त करने का एक तरीका है; जहां "असुरक्षित" का अर्थ है "प्रोग्रामर द्वारा सुरक्षा की गारंटी दी जानी चाहिए" — कंपाइलर द्वारा कुछ भी चेक नहीं किया गया है। यदि आप एक समझदार प्रोग्रामर हैं और भारी प्रमाण दायित्वों को पूरा करने के इच्छुक हैं, तो आप unsafePerformIO का उपयोग कर सकते हैं। लेकिन उस समय आप हास्केल में प्रोग्रामिंग नहीं कर रहे हैं; आप एक असुरक्षित भाषा में प्रोग्रामिंग कर रहे हैं जो हास्केल की तरह दिखता है।

Answer 5

मुझे एहसास है कि मैं यह कहने के लिए बहुत अलोकप्रिय हूं कि मैं क्या कहने वाला हूं, लेकिन मुझे लगा कि मुझे यहां प्रस्तुत कुछ (मेरी राय में गलत जानकारी) का जवाब देना पड़ा।

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

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

तो नोर्मन रैमसे कहते हैं, आधिकारिक स्थिति यह साबित हुई कि असुरक्षित पैराफॉर्मियो का उपयोग करना ठीक था, बशर्ते कुछ सबूत दायित्व किसी भी व्यक्ति द्वारा संतुष्ट हो जाएं (मुख्य रूप से ऐसा करने से इनलाइनिंग और सामान्य उप जैसे महत्वपूर्ण संकलक परिवर्तनों को अमान्य नहीं किया जाता है -प्रदर्शन उन्मूलन)। अब तक इतना अच्छा है, या तो कोई सोच सकता है। असली किकर यह है कि इन सबूत दायित्वों संतुष्ट नहीं हो सकते हैं असुरक्षित पैराफॉर्मियो के लिए शायद सबसे आम उपयोग केस क्या है, जो मेरे अनुमान के अनुसार जंगली में सभी असुरक्षित पैराफॉर्मियो के 50% से अधिक के लिए खाते हैं। मैं अपमानजनक मुहावरे के बारे में बात कर रहा हूं जिसे "असुरक्षितफॉर्मियो हैक" कहा जाता है जो वास्तव में (वास्तव में स्पष्ट रूप से) पूरी तरह से असुरक्षित (इनलाइनिंग और सीएसई की उपस्थिति में) है।

मेरे पास वास्तव में समय, स्थान या झुकाव नहीं है जो "असुरक्षितफॉर्मियो हैक" है या वास्तविक आईओ पुस्तकालयों में इसकी आवश्यकता क्यों है, लेकिन नीचे की रेखा यह है कि जो लोग हास्कल्स आईओ आधारभूत संरचना पर काम करते हैं वे आमतौर पर होते हैं "एक चट्टान और एक कठिन जगह के बीच फंस गया"। वे या तो एक अंतर्निहित सुरक्षित एपीआई प्रदान कर सकते हैं जिसमें कोई सुरक्षित कार्यान्वयन नहीं है (हास्केल में), या वे एक अंतर्निहित असुरक्षित एपीआई प्रदान कर सकते हैं जिसे सुरक्षित रूप से कार्यान्वित किया जा सकता है, लेकिन वे शायद ही कभी क्या कर सकते हैं, दोनों एपीआई डिजाइन और कार्यान्वयन में सुरक्षा प्रदान करते हैं।निराशाजनक नियमितता के आधार पर "असुरफफॉर्मियो हैक" असली दुनिया कोड (हास्केल मानक पुस्तकालयों सहित) में दिखाई देता है, ऐसा लगता है कि दो बुराइयों के कम से कम पूर्व विकल्प का चयन करते हैं, और उम्मीद है कि संकलक मक नहीं करेगा इनलाइनिंग, सीएसई या किसी अन्य परिवर्तन के साथ चीजें।

मेरी इच्छा है कि यह सब ऐसा नहीं था। दुर्भाग्य से, यह है।

Answer 6

मुझे नहीं लगता कि असुरक्षितफॉर्मियो का मतलब है कि किसी भी तरह से हैकेल अशुद्ध हो जाता है। आप अशुद्ध कार्यों से शुद्ध (संदर्भित पारदर्शी) कार्यों को बना सकते हैं।

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

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

मैं समझता हूं कि इसके लिए आपको शुद्ध होने की शुद्ध कमजोर परिभाषा है। यानी शुद्ध कार्य संदर्भित रूप से पारदर्शी होते हैं और कभी भी नहीं कहा जाता है क्योंकि साइड-इफेक्ट (जैसे प्रिंट) के।

Answer 7

जीएचसी का हालिया विस्तार, सुरक्षित हास्केल, इस प्रश्न का एक नया उत्तर देता है। unsafePerformIO जीएचसी हास्केल का एक हिस्सा है, लेकिन सुरक्षित बोली का हिस्सा नहीं है।

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

अधिक जानकारी के लिए: GHC manual, Safe Haskell paper

अपने संपादित के बारे में