घोषणात्मक भाषाओं के कार्यान्वयन विवरण मूल रूप से अनिवार्य

Question

मैं टॉमस पेट्रिसक & जॉन स्कीट द्वारा 'कार्यात्मक प्रोग्रामिंग' पढ़ रहा हूं और मैं घोषणात्मक & अनिवार्य प्रोग्रामिंग के बीच अंतर को समझता हूं।

मैं क्या सोच रहा था कि आदिम ऑपरेटरों & कार्यान्वित कार्य कैसे हैं, अनिवार्य ऑपरेटरों & कार्यों से निर्मित घोषणात्मक भाषाएं हैं।

चीयर्स

आंगनवाडी

Answer 1

अगर मैं आपके सवाल का सही ढंग से समझ, मुझे नहीं लगता कि एक कठिन और तेजी से नियम है। उदाहरण के लिए, आप स्वयं के लिए एक दुभाषिया बनाने के लिए, लिस्प की तरह एक कार्यात्मक भाषा का उपयोग कर सकते हैं। इस मामले में, कार्यान्वयन विवरण कार्यात्मक तरीके से कार्यान्वित किए जाते हैं (क्योंकि लिस्प एक कार्यात्मक भाषा है)।

इसके अलावा, यदि आपके पास ट्यूरिंग पूर्ण भाषा है, तो आप इसे किसी अन्य भाषा के लिए पार्सर/दुभाषिया/कंपाइलर को लागू करने के लिए उपयोग कर सकते हैं। अनिवार्य ट्यूरिंग-पूर्ण भाषाएं हैं, और कार्यात्मक/घोषणात्मक ट्यूरिंग-पूर्ण भाषाएं हैं।

लेकिन अंततः सभी कोड असेंबली या मशीन कोड के लिए किए जाते हैं, जो मूल रूप से अनिवार्य है। सिद्धांत रूप में, मैंने ऊपर जो कहा वह सच है, लेकिन स्पष्ट रूप से अभ्यास में नहीं :)।

एक दिलचस्प ऐतिहासिक तरफ के रूप में, LISP एक पूरी तरह से सैद्धांतिक निर्माण था; यह कंप्यूटर भाषाओं के लिए एक गणितीय नोटेशन था। यह सैद्धांतिक बने रहे जब तक लिस्प के eval समारोह एक आईबीएम 704 पर स्टीव रसेल द्वारा मशीन कोड में लागू किया गया था:

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

तो एक बार फिर, सिद्धांत और अभ्यास के बीच subtleties। :)

Answer 2

निम्न स्तर की मशीन (सीपीयू, असेंबली भाषा स्तर) अनिवार्य रूप से कुछ बिंदु पर कार्यान्वयन को ध्यान में रखना होगा। हालांकि, Implementing certain kinds of functional languages like Haskell सभ्य प्रदर्शन के साथ रन-टाइम बनाने के लिए कुछ बहुत ही स्पष्ट दृष्टिकोण लेता है।

• Single Static Assignment

यहाँ संकलन योजना (कार्यात्मक) का एक उदाहरण है सीधे करने के लिए:

अजीब पर्याप्त, सबसे जरूरी भाषाओं एक चरण है, जहां सभी कोड अधिक कथात्मक होने के लिए तब्दील हो जाता है के माध्यम से जाना सी कोड (अनिवार्य):

• The 90 minute Scheme to C compiler

Answer 3

आपका प्रश्न थोड़ा अस्पष्ट है। हुड के तहत, प्रोसेसर निर्देश प्रकृति में अनिवार्य हैं। यदि आपका कोड वॉन न्यूमैन मशीन पर चलाना है, तो इसे अंततः अनिवार्य कोड के रूप में चलाया जाना चाहिए।

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

Answer 4

अनिवार्य ऑपरेटरों & फ़ंक्शंस से निर्मित घोषणात्मक भाषाएं हैं?

कभी-कभी। यह कार्यान्वयन की संपत्ति है, भाषा नहीं है।

1 9 80 के दशक में, बहुत से लोगों ने ग्राफ़ को कार्यात्मक प्रोग्राम संकलित किए, फिर ग्राफ को सरल ग्राफ में फिर से लिखें। इस गणना में आम तौर पर ग्राफ को अद्यतन करने में शामिल था, लेकिन अन्यथा यह एक घोषणा के रूप में था जैसा आप चाहें। अधिक जानने के लिए, क्रिस क्लेक और साइमन पेटन जोन्स द्वारा "ग्राफ कमी" देखें या "चार स्ट्रोक कमी इंजन" पढ़ें।

आखिरकार कंपाइलर लेखकों ने सीधे कार्यात्मक कार्यक्रमों को मूल मशीन कोड में संकलित करके बेहतर प्रदर्शन करने के तरीकों का पता लगाया। यदि मूल मशीन एक सामान्य वस्तु मशीन है, तो इसका मतलब सामान्य अनिवार्य संचालन है। हालांकि, यदि आप एमआईटी में प्रोफेसर अरविंद के अग्रणी काम को देखते हैं, तो उनके समूह ने डेटाफ्लो मशीन डिज़ाइन और निर्माण किया जहां मूलभूत कम्प्यूटेशनल ऑपरेशंस प्रकृति में अधिक घोषणात्मक हैं। यह बहुत अच्छा काम था, लेकिन 1 9 80 के दशक में विकसित होने वाले सभी विशेष प्रयोजन आर्किटेक्चरों को महान माइक्रोसॉफ्ट/इंटेल पुण्य चक्र (अधिक सॉफ्टवेयर -> अधिक पीसी बेचे गए -> सस्ता प्रोसेसर -> अधिक पीसी बेचे गए -> .. -> $ 300 नेटबुक जो वास्तव में अच्छी चीजें करते हैं)।

Answer 5

कार्यान्वयन यह है कि 'हुड के नीचे छिपा हुआ है। इसे किसी भी प्रतिमान के साथ बनाया जा सकता है।

घोषणात्मक कार्यक्रम केवल कुछ और कम "सार्वभौमिक" अनिवार्य कार्यान्वयन/vm के लिए एक डेटा है।

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

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

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