आधुनिक प्रोग्रामिंग लैंग्वेज डेवलपमेंट के लिए प्रोसेस कैल्कुली और पीएल थ्योरी का उपयोग

Question

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

Answer 1

मेरा उत्तर वास्तव में गाइल्स का एक विस्तार है ', जो मैंने अपने लिखे जाने से पहले नहीं पढ़ा था। शायद यह फिर भी मददगार हो।

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

• शुद्ध शोध।

• उत्पाद अनुसंधान और विकास केंद्रित है।

बाद में आमतौर पर उद्योग में एक उत्पाद के रूप में प्रोग्रामिंग भाषाओं को प्रदान करने के उद्देश्य से होता है। Microsoft में Oracle और C # पर जावा विकसित करने वाली टीमें उदाहरण हैं। इसके विपरीत, शुद्ध अनुसंधान उत्पादों से बंधा नहीं है। इसका उद्देश्य प्रोग्रामिंग भाषाओं को आंतरिक रुचि की वस्तुओं के रूप में समझना और सभी प्रोग्रामिंग भाषाओं में अंतर्निहित गणितीय संरचनाओं का पता लगाना है।

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

कोई इस बिंदु पर पूछ सकता है कि दो आयाम इतने भिन्न क्यों हैं और वे फिर भी कैसे संबंधित हैं।

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

• प्रोग्रामिंग का एक नया डोमेन खुल जाता है जिसमें विस्थापित होने का कोई कारण नहीं है। प्राथमिक उदाहरण जावास्क्रिप्ट के अपने सहवर्ती वृद्धि के साथ वेब है।

• भाषा चिपचिपाहट। इससे मेरा मतलब भाषा बदलने की ऊंची कीमत से है। लेकिन कभी-कभी प्रोग्रामर विभिन्न क्षेत्रों में जाते हैं, उनके साथ एक प्रोग्रामिंग भाषा लेते हैं, और नए क्षेत्र में पुरानी भाषा के साथ सफल होते हैं।

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

• एक भाषा सम्मोहक टूल और इको-सिस्टम के साथ आ सकती है। यहाँ भी C # और it .Net और Visual Studio Eco-system को एक उदाहरण के रूप में उल्लेख किया जा सकता है।

• पुरानी भाषाओं में नई सुविधाएँ हैं। जावा के दिमाग में आता है, जो प्रत्येक पुनरावृत्ति में, कार्यात्मक प्रोग्रामिंग परंपरा से अधिक अच्छे विचारों को चुनता है।

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

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

$\lambda$$\pi$$\beta$कार्यात्मक प्रोग्रामिंग, संकल्प / तर्क-प्रोग्रामिंग के लिए एकीकरण, समवर्ती संगणना के लिए नाम से गुजरना) के लिए कटौती। यह समझने के लिए कि क्या स्काला जैसी भाषा में व्यवहार्य पूर्ण प्रकार का निष्कर्ष हो सकता है, हमें जेवीएम के बारे में चिंता करने की आवश्यकता नहीं है। वास्तव में जेवीएम के बारे में सोचने से टाइप-इनफरेंस की बेहतर समझ विकसित होगी। यही कारण है कि छोटे मूल गणना में गणना का अमूर्त महत्वपूर्ण और शक्तिशाली है।

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

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

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

Comments

वाह! उस आरेख को बनाने में कितना समय लगा, और क्या मैं भविष्य में इसका उपयोग कर सकता हूं?

— कोड़ी

@cody ने ओमनीग्राफल के साथ कुछ सेकंड का समय लिया, और इसका उपयोग करने के लिए स्वतंत्र महसूस करें।

— मार्टिन बर्जर

Answer 2

प्रोग्रामिंग भाषा डिजाइन का विज्ञान अपनी प्रारंभिक अवस्था में बहुत अधिक है। थ्योरी (किसी भाषा के अर्थ और कार्यक्रमों की अर्थपूर्णता का अध्ययन) और अनुभववाद (जो प्रोग्रामर प्रबंधन करते हैं या करने का प्रबंधन नहीं करते हैं) एक भाषा डिजाइन करते समय एक या दूसरे तरीके को तौलने के लिए बहुत सारे गुणात्मक तर्क देते हैं। लेकिन हमारे पास तय करने के लिए शायद ही कोई मात्रात्मक कारण है।

उस समय के बीच देरी हो रही है जब कोई सिद्धांत एक व्यावहारिक प्रोग्रामिंग भाषा में एक नवाचार के लिए पर्याप्त हो जाता है, और जिस समय यह नवाचार "मुख्यधारा" भाषाओं में दिखाई देने लगता है। उदाहरण के लिए, कचरा संग्रहण के साथ स्वचालित स्मृति प्रबंधन को 1960 के दशक के मध्य में औद्योगिक उपयोग के लिए परिपक्व कहा जा सकता है, लेकिन केवल 1995 में जावा के साथ मुख्यधारा में पहुंच गया। 1970 के दशक के अंत में पैरामीट्रिक बहुरूपता को अच्छी तरह से समझा गया था और इसे बनाया गया था। 200 के दशक के मध्य में जावा में। एक शोधकर्ता के करियर के पैमाने पर, 30 साल एक लंबा समय है।

भाषा के व्यापक पैमाने पर औद्योगिक अपनाने का अध्ययन करने के लिए समाजशास्त्रियों के लिए एक मामला है, और यह विज्ञान अपनी प्रारंभिक अवस्था में और भी अधिक है। बाजार के विचार एक महत्वपूर्ण कारक हैं - यदि सूर्य, Microsoft या Apple किसी भाषा को धक्का देते हैं, तो यह किसी भी संख्या में POPL और PLDI कागजात की तुलना में बहुत अधिक प्रभाव डालता है। यहां तक ​​कि एक प्रोग्रामर के लिए जो एक विकल्प है, लाइब्रेरी उपलब्धता आमतौर पर भाषा डिजाइन की तुलना में कहीं अधिक महत्वपूर्ण है। यह कहना नहीं है कि भाषा डिजाइन महत्वपूर्ण नहीं है: एक अच्छी तरह से डिजाइन की गई भाषा एक राहत है! यह आमतौर पर निर्णायक कारक नहीं है।

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

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

क्या बेहतर सॉफ्टवेयर बनाने के लिए रिसर्च एडवांस की जरूरत है? सब के बाद वहाँ एक अरब डॉलर का उद्योग है कि आकाश में एक पाई से पीआई पथरी नहीं बता सकता है। फिर, वह उद्योग अरबों डॉलर के कीड़े को ठीक करने में खर्च करता है।

"क्या उन्हें कभी ज़रूरत होगी" शोध में एक सार्थक प्रश्न नहीं है। अग्रिम में यह अनुमान लगाना असंभव है कि दीर्घकालिक परिणाम क्या होंगे। मैं आगे भी कहूंगा कि यह एक सुरक्षित धारणा है कि किसी भी शोध के परिणाम एक दिन होंगे - हमें अभी यह नहीं पता है कि वह दिन अगले साल आएगा या अगली सहस्राब्दी।

Answer 3

मुझे वहां पाई-कैलकुलस पर बहुत सारे वेरिएंट दिखाई देते हैं और बहुत सारे सक्रिय शोध हैं, लेकिन क्या उन्हें कभी महत्वपूर्ण अनुप्रयोगों की आवश्यकता होगी या नहीं?

मेरे द्वारा पूछे जाने का कारण यह है क्योंकि मुझे प्रोग्रामिंग भाषाओं को विकसित करना पसंद है और वास्तविक लक्ष्य वास्तव में पीएल बनाने के लिए सिद्धांत का उपयोग करना होगा। मेरे द्वारा लिखे गए सामान के लिए, वास्तव में सिद्धांत पर कोई संबंध नहीं है।

यह एक पेचीदा सवाल है! मैं आपको अपनी निजी राय बताऊंगा, और मैं इस बात पर जोर देता हूं कि यह मेरी राय है ।

मुझे नहीं लगता कि समवर्ती प्रोग्रामिंग के लिए pi-पथरी सीधे संकेतन के रूप में उपयुक्त है। हालाँकि, मुझे लगता है कि समवर्ती प्रोग्रामिंग भाषा डिजाइन करने से पहले आपको इसका अध्ययन जरूर करना चाहिए । कारण यह है कि पाई-पथरी एक निम्न स्तर देता है --- लेकिन महत्वपूर्ण रूप से, रचनात्मक! --- संगामिति का हिसाब। नतीजतन, यह सब कुछ आप चाहते हैं व्यक्त कर सकते हैं, लेकिन हमेशा आसानी से नहीं।

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

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

$A \multimap B$$A^\bot ⅋ B$

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

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

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

Comments

किस अर्थ में आपको -calculus में कॉल स्टैक का प्रबंधन करने की आवश्यकता है ? इस के मिलनर के कूट में अपने आप होता है में और भी नए वान Bakel / अल्बर्टो Vigliotti एन्कोडिंग में। कार्य -calculus में वाक्यात्मक चीनी का एक बिल्कुल अच्छा रूप है । λ π $\pi$$\lambda$$\pi$$\pi$

— मार्टिन बर्जर

इसके अलावा, -calculus कॉल / सीसी जैसे अनुक्रमिक नियंत्रण ऑपरेटरों का वास्तव में अजीब खाता है। ऐसे ऑपरेटर बहुत अधिक आसानी से और स्वाभाविक रूप से -caluclus में व्यक्त किए जाते हैं, क्योंकि कूदना स्पष्ट रूप से संदेश पारित करने का एक रूप है। -calculus के नाम की एक स्वाभाविक धारणा नहीं है जिसे आप कूद सकते हैं, इसलिए आपको इसे funciton एप्लिकेशन के रूप में कोड करना होगा, या आपको अतिरिक्त सामान जोड़ना होगा। π $\lambda\mu$$\pi$$\lambda$

— मार्टिन बर्गर

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

— मार्टिन बर्गर

सभी ने कहा, निश्चित रूप से कोई भी कच्चे -calculus में कच्चे -calusus की तुलना में किसी भी अधिक में कार्यक्रम नहीं करना चाहता है । दोनों औपचारिकताएं सरलीकरण हैं जो हमें दूसरों के बहिष्करण पर गणना की कुछ विशेषताओं पर ध्यान केंद्रित करने में सक्षम बनाती हैं। $\pi$$\lambda$

— मार्टिन बर्गर

@MartinBerger: मैं जवाब देने के लिए आपको समझाने की उम्मीद कर रहा था! मेरा मतलब है कि यदि आप कच्चे में प्रोग्राम करना चाहते थे , और फ़ंक्शंस का उपयोग भी करना चाहते थे, तो आप उन शब्दों को लिखना बंद कर देंगे जो मिलनर अनुवाद की छवि में हैं, और इसलिए आपको "स्टैक का प्रबंधन" करना होगा इस अर्थ में कि आप अनिवार्य रूप से निरंतरता और स्पष्ट प्रतिस्थापन का प्रबंधन करेंगे। (एक तरफ के रूप में, मैं वैन बेकल / विग्लियोटी पेपर के बारे में नहीं जानता था - धन्यवाद!)$\pi$

— नील कृष्णस्वामी

Answer 4

आप कहते हैं कि " सही अंत लक्ष्य वास्तव में पीएल बनाने के लिए सिद्धांत का उपयोग करना होगा।" तो, आप संभवतः मानते हैं कि अन्य लक्ष्य हैं?

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

पाई-कैलकुलस के बारे में आपके सवाल के साथ, मुझे लगता है कि पीआई-कैलकुलस अभी भी भाषा डिजाइन में एप्लिकेशन खोजने में थोड़ा नया है। अनुकरणीय-पथरी पर विकिपीडिया पृष्ठ अनुकरणीय-पथरी का उपयोग कर भाषा डिजाइन के रूप में उल्लेख BPML और occam-अनुकरणीय है। लेकिन आप इसके पूर्ववर्ती CCS के पृष्ठों को भी देख सकते हैं, और अन्य प्रक्रिया जैसे CSP, पथरी और अन्य को जोड़ते हैं, जिनका उपयोग कई प्रोग्रामिंग भाषा डिज़ाइनों में किया गया है। तुम भी Sangiorgi और वॉकर किताब के "ऑब्जेक्ट्स और पाई-कैलकुलस" खंड को देख सकते हैं कि पी-कैलकुलस मौजूदा प्रोग्रामिंग भाषाओं से कैसे संबंधित है।

Answer 5

मुझे जंगली में प्रक्रिया के व्यावहारिक कार्यान्वयन के लिए खोज करना पसंद है :) (सिद्धांत के बारे में पढ़ने के अलावा)।

1. Clojure async चैनल CSP पर आधारित है: http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html
2. गोलंग के पास सीएसपी पर आधारित चैनल हैं (यह मुझे लगता है कि क्लोजर के लिए प्रेरित रिच हिकी): http://www.informit.com/articles/printerfriendly/1768317
3. वहाँ एक आदमी है जो scala (सदस्यता) के लिए एक एसीपी आधारित विस्तार किया है, लेकिन मैं लिंक पोस्ट करने के लिए पर्याप्त प्रतिष्ठा नहीं है ...

आदि।