कार्यात्मक भाषाओं की तुलना में अनिवार्य भाषाएं एक दूसरे से अधिक भिन्न कैसे हैं?


17

मैं साइमन पेटन जोन्स के कार्यात्मक प्रोग्रामिंग भाषाओं के कार्यान्वयन को पढ़ रहा हूं और एक बयान है जिसने मुझे थोड़ा आश्चर्यचकित किया है (पृष्ठ 39 पर):

की तुलना में बहुत अधिक हद तक अनिवार्य भाषाओं के लिए मामला है, कार्यात्मक भाषाएं मोटे तौर पर एक-दूसरे के रूपात्मक रूप से भिन्न होती हैं, जिनमें अपेक्षाकृत कुछ शब्दार्थ अंतर होते हैं।

अब, यह 1987 में लिखा गया था और इस विषय पर मेरे विचार अधिक आधुनिक प्रोग्रामिंग भाषाओं से प्रभावित हो सकते हैं जो तब आसपास या लोकप्रिय नहीं थे। हालाँकि, मुझे यह विश्वास करना थोड़ा कठिन है। उदाहरण के लिए, मुझे लगता है कि वर्णित मिरांडा प्रोग्रामिंग भाषा (हास्केल के लिए एक प्रारंभिक पूर्ववर्ती) के पास एमएल की तरह सख्त भाषा की तुलना में बहुत अधिक शब्दार्थ है, जैसे कि सी को पास्कल है या शायद सी को भी स्मॉलटाक करना है (हालांकि यह cede होगा) C ++ उसकी बात :-) का कुछ सत्यापन प्रदान करता है।

लेकिन फिर, मैं इसे अपनी सहज समझ पर आधारित कर रहा हूं। क्या साइमन पेटन जोन्स यह कहने में काफी हद तक सही हैं, या यह एक विवादास्पद बिंदु है?

जवाबों:


19

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

वी

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

a -> bटीटी()a

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

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

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


10

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

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

साइमन का बयान भी एक महत्वपूर्ण ऐतिहासिक संदर्भ में फिट बैठता है। हास्केल (1987) के जन्म के समय, नॉन-सख्त कार्यात्मक भाषाओं के घोर विरोधी थे - न केवल मिरांडा, बल्कि आलसी एमएल, ऑरवेल, क्लीन, और कई अन्य। कुछ वाक्यात्मक विविधताओं के अलावा, वे सभी एक ही भाषा में बहुत अधिक थे। जो हास्केल समिति के गठन के लिए सटीक प्रेरणा थी। इस पर अधिक जानकारी के लिए, "ए हिस्केल का इतिहास: कक्षा के साथ आलसी होना" देखें: http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/


5

मुझे लगता है कि मुख्य शब्दार्थ के लिए एसपीजे यह कहने में सही है।

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

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

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

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


4

मुझे लगता है कि साइमन पीजे की बोली वास्तव में एक ऑफ-हैंड टिप्पणी है।

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

लगभग सभी कार्यात्मक भाषाएँ कचरा एकत्र स्मृति प्रबंधन और पुनरावर्ती डेटा संरचनाओं (लिस्प द्वारा उत्पन्न) का उपयोग करती हैं, उनमें से अधिकांश "बीजीय" डेटा प्रकार और पैटर्न मिलान (होप द्वारा उत्पन्न) का उपयोग करते हैं, उनमें से बहुत से उच्च-क्रम के कार्यों और बहुरूप कार्यों का उपयोग करते हैं ( ML से उत्पन्न)। इसके अलावा, सर्वसम्मति गायब हो जाती है। वे उपयोग किए जाने वाले मॉड्यूल सिस्टम में भिन्न होते हैं, कैसे राज्य परिवर्तन संचालन और अन्य कम्प्यूटेशनल प्रभाव को संभाला जाना चाहिए, और मूल्यांकन क्रम (कॉल-बाय-नेम बनाम कॉल-बाय-वैल्यू) आदि।

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

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

कार्यात्मक प्रोग्रामिंग के क्लीनर और वर्दी संकेतन को अनिवार्य प्रोग्रामिंग भाषाओं में लाना वास्तव में सार्थक होगा। मैं देख रहा हूं कि स्काला ने उस दिशा में एक शुरुआत की है। यह देखा जाना बाकी है कि क्या रुझान जारी रहेगा।


मुझे इस बात पर आश्चर्य है कि आपने "बीजीय" डेटा प्रकारों में डरावने उद्धरणों का उपयोग क्यों किया?
स्टीवन शॉ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.