जीएचसी

Question

की गैर-आलसी शाखा मैंने सुना है कि जीएचसी की एक शाखा है जो डिफ़ॉल्ट रूप से सख्त कोड को संकलित करती है जबकि आलस्य द्वारा आलस्य सक्षम किया जा सकता है। (आईआईआरसी, उन्होंने कहा कि एक वित्तीय कंपनी शाखा विकसित करती है और इसे उत्पादन कोड के लिए उपयोग करती है।) क्या यह सच है? मुझे यह नहीं मिल रहा है।

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

सख्त हास्केल पर मुझे जो कुछ मिलता है वह $! और rnf जैसी स्पष्ट चीजें हैं। जबकि मुझे आलसी मूल्यांकन बहुत ही सुरुचिपूर्ण लगता है, मैं हास्केल में एक प्रोग्राम विकसित करना चाहता हूं जहां मैं अंतरिक्ष लीक से बचना चाहता हूं और अनुमानित प्रदर्शन करना चाहता हूं।

अस्वीकरण: मैं कठोरता के लिए कोई मामला नहीं बना रहा हूं, मैं बस सख्त हास्केल या ऐसा कुछ देखना चाहता हूं।

Answer 1

आप Disciple के लिए देख रहे हैं।

तो हास्केल में अंतर करने के लिए दो प्रकार की आलस्य हैं। आलसी I/O है, जो एक घृणा है और इसे इटेटेट लाइब्रेरीज़ द्वारा हल किया जाता है (निर्बाध प्लग: मेरी pipes लाइब्रेरी समेत)। तो फिर वहाँ शुद्ध संगणना, जो अभी भी बहस के लिए खुला है में आलस्य है, लेकिन मैं आलस्य के प्रमुख लाभ संक्षेप में प्रस्तुत करने के बाद आप पहले से ही नुकसान से परिचित हैं की कोशिश करेंगे:

आलस्य और अधिक कुशल है

एक सरल उदाहरण है:

any = foldr (||) False 

any पाता है एक सूची में किसी भी मूल्य True है। यह केवल पहले True तक के तत्वों का मूल्यांकन करता है, इसलिए इससे कोई फर्क नहीं पड़ता कि सूची बहुत लंबी है या नहीं।

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

यह वास्तव में यही कारण है कि iteratee पुस्तकालय बहुत संसाधन-कुशल हैं। वे केवल उतना ही काम करते हैं जितना कि उन्हें परिणाम उत्पन्न करना पड़ता है, और इससे बहुत ही आसान स्मृति और डिस्क उपयोग बहुत आसानी से उपयोग किए जाने वाले अर्थशास्त्र के साथ होता है।

आलस्य स्वाभाविक अधिक composable

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

यह सच कारण है कि मेरा मानना ​​है कि सामान्य रूप से आलस्य वास्तव में प्रोग्रामिंग का भविष्य है, हालांकि मुझे अभी भी लगता है कि यह एक खुला सवाल है कि हास्केल ने आलस्य "दाएं" को लागू किया है या नहीं।

Answer 2

अगर मैं इसे सही ढंग से समझता हूं, तो सख्त हास्केल में मैनाडिक I/O नहीं हो सकता क्योंकि हम इसे जानते हैं।हास्केल में विचार यह है कि सभी हास्केल कोड शुद्ध है (जिसमें आईओ क्रियाएं शामिल हैं, जो राज्य मोनैड की तरह काम करती हैं) और "मुख्य" रनटाइम के प्रकार IO() का मान देता है जो फिर अनुक्रमिक ऑपरेटर पर बार-बार बल देता है = ।

टेकोमो पोस्ट के प्रतिबिंब के लिए आप रॉबर्ट हार्पर के ब्लॉग, * http://existentialtype.wordpress.com/2011/04/24/the-real-point-of-laziness/ और संबंधित से देख सकते हैं। यह दोनों तरीकों से चला जाता है।

मेरे अनुभव में, आलस्य पहली बार में मुश्किल है, लेकिन फिर आप इसकी आदत हो और यह ठीक है।

आलस्य के लिए क्लासिक वकालत टुकड़ा ह्यूजेस के कागज है "क्यों कार्यात्मक प्रोग्रामिंग मैटर्स" जिसे आप आसानी से खोजने के लिए सक्षम होना चाहिए।

Answer 3

कुछ अच्छी चीजों के बारे में तुम क्यों हास्केल के आलस्य से संकोच नहीं करना चाहिए कहा गया है, लेकिन मुझे लगता है कि मूल प्रश्न अनुत्तरित बना हुआ है।

हास्केल में फ़ंक्शन एप्लिकेशन गैर-सख्त है; यानी, फ़ंक्शन तर्क का मूल्यांकन केवल तभी किया जाता है जब आवश्यक हो।

~ Haskell Report 2010 > Predefined Types and Classes # Strict Evaluation

हालांकि यह एक छोटे से भ्रामक है,। कार्यान्वयन आवश्यक होने से पहले फ़ंक्शन तर्क का मूल्यांकन कर सकते हैं, लेकिन केवल सीमित सीमा तक। आपको गैर-सख्त अर्थशास्त्र को संरक्षित करना होगा: इसलिए यदि किसी तर्क के लिए अभिव्यक्ति एक अनंत लूप का परिणाम देती है, और उस तर्क का उपयोग नहीं किया जाता है, तो उस तर्क के साथ एक फ़ंक्शन कॉल अनंत लूप नहीं होना चाहिए।

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

• Eager Haskell, हास्केल प्रोग्रामिंग भाषा का कार्यान्वयन जो डिफ़ॉल्ट रूप से उत्सुक मूल्यांकन का उपयोग करता है। मेरा मानना ​​है कि आप यही सोच रहे थे (हालांकि यह जीएचसी की शाखा नहीं है)।
• Speculative Execution और सट्टा समानता (देखें उदाहरण के लिए speculation पैकेज)।
• Optimistic Evaluation, कठोरता अनुकूलन के साथ GHC को तेज करने के बारे में SPJ से एक कागज।

Answer 4

ऐसा लगता है जैसे आपने रॉबर्ट एननाल्स के PhD thesis on speculative evaluation के बारे में जीएचसी के साथ सुना है। उन्होंने जीएचसी का एक कांटा बनाया जिसे "spec_eval" कांटा कहा जाता है, जहां सट्टा मूल्यांकन किया गया था। चूंकि हास्केल स्पष्ट रूप से आलसी के बजाय गैर-सख्त है, spec_eval उस बिंदु तक सख्त था जहां वास्तव में यह अंतर आया। हालांकि यह सभी मामलों में तेजी से था, लेकिन इसे जीएचसी में बड़े बदलाव की आवश्यकता थी और कभी विलय नहीं किया गया था।

इस प्रश्न पर इस साइट पर been answered before है।