“एक प्रमाण एक कार्यक्रम है; सूत्र यह साबित करता है कि कार्यक्रम के लिए एक प्रकार है ”

Question

यह एक दार्शनिक प्रकार का प्रश्न हो सकता है, लेकिन मेरा मानना ​​है कि इसका एक वस्तुनिष्ठ उत्तर है।

यदि आप हास्केल के बारे में विकिपीडिया लेख पढ़ते हैं, तो आप निम्नलिखित पा सकते हैं:

भाषा हास्केल करी और उनके बौद्धिक वंशजों की टिप्पणियों में निहित है, कि "एक प्रमाण एक कार्यक्रम है; जो सूत्र यह साबित करता है वह कार्यक्रम के लिए एक प्रकार है"

अब, मैं जो पूछ रहा हूं वह यह है: क्या यह वास्तव में सभी प्रोग्रामिंग भाषाओं पर बहुत अधिक लागू नहीं होता है? हास्केल की कौन सी विशेषता (या सुविधाओं का समूह) इस कथन के अनुरूप है? दूसरे शब्दों में, ध्यान देने योग्य तरीके क्या हैं जिनमें इस कथन ने भाषा के डिजाइन को प्रभावित किया है?

Comments

किसी को भी समझाने की परवाह है कि "करीबी" वोट क्यों?

@ ग्रिगरी जवादन: मैंने मतदान बंद नहीं किया, लेकिन यह शायद इसलिए है क्योंकि यह प्रश्न एसओ के लिए सीमा-विषय है - दार्शनिक प्रश्न, उद्देश्यपूर्ण उत्तर देने या अन्यथा, आमतौर पर यहां उपयुक्त नहीं हैं। इस मामले में, मुझे लगता है कि यह उचित है, हालांकि, क्योंकि उत्तर में गहरे व्यावहारिक निहितार्थ हैं कि हास्केल वास्तव में कैसे उपयोग किया जाता है।

@ समूह: यदि यह प्रश्न वास्तविक समाधान (कोड में) के साथ एक वास्तविक समस्या थी, तो यह SO पर रह सकता है। प्रोग्रामर्स को बंद करने और स्थानांतरित करने के लिए वोट दिया गया।

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

— विलोपनवादी बहस की पुनरावृत्ति

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

— सीए मैक्कैन

Answer 1

आवश्यक अवधारणा सार्वभौमिक रूप से कुछ फैशन में लागू होती है, हाँ, लेकिन शायद ही कभी एक उपयोगी तरीके से।

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

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

हास्केल इस बात में असामान्य है कि यह कितनी प्रकार की जानकारी प्रदान करने की उम्मीद करता है - विशेष रूप से, फ़ंक्शन इसके तर्कों के अलावा निर्दिष्ट किसी भी मूल्य पर निर्भर नहीं कर सकता है। दूसरी ओर, परिवर्तनशील वैश्विक चर वाली भाषा में, कोई भी कार्य उन मूल्यों का निरीक्षण (संभावित) कर सकता है और तदनुसार व्यवहार को बदल सकता है। तो प्रकार के साथ एक हास्केल फ़ंक्शन A -> Bको एक लघु कार्यक्रम माना जा सकता है जो यह साबित करता Aहै कि B; कई अन्य भाषाओं में एक समान कार्य केवल हमें यह बताएगा कि Aऔर जो कुछ भी वैश्विक स्थिति है वह संयुक्त रूप से है B।

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

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

यह अवधारणा हास्केल में, साथ ही साथ बहुत आगे ले जाई जा सकती है।

Comments

ध्यान दें कि अपवाद पूरी तरह से एक प्रकार की प्रणाली में एकीकृत किए जा सकते हैं।

— गार्डेनहैड

Answer 2

आप सही हैं कि करी-हावर्ड पत्राचार एक बहुत ही सामान्य बात है। यह अपने आप को इसके इतिहास से थोड़ा परिचित करने के लायक है: http://en.wikipedia.org/wiki/Curry-Howard_correspondence

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

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

तो एक तरह से, सवाल यह है कि हास्केल ने "एसटीएलसी में" उतने ही सरल तरीके से उतरे। दो बातें दिमाग में आती हैं:

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

एक महत्वपूर्ण तरीका यह भी है कि हास्केल, अधिकांश भाषाओं की तरह, करी-हावर्ड पत्राचार के प्रत्यक्ष आवेदन के संबंध में विफल रहता है। हास्केल, एक ट्यूरिंग-पूर्ण भाषा के रूप में, असीमित पुनरावृत्ति की संभावना है, और इसलिए गैर-समाप्ति की। STLC में एक फ़िक्सपॉइंट ऑपरेटर नहीं है, ट्यूरिंग-पूर्ण नहीं है, और दृढ़ता से सामान्य कर रहा है - जो यह कहना है कि STLC में किसी भी शब्द की कमी समाप्त करने में विफल होगी। पुनरावृत्ति की संभावना का मतलब है कि कोई करी-हावर्ड को "धोखा" दे सकता है। उदाहरण के लिए, let x = x in xप्रकार हैforall a. a- यानी, जब से यह कभी नहीं लौटा, मैं दिखावा कर सकता हूँ यह मुझे कुछ भी देता है! चूंकि हम हास्केल में हमेशा ऐसा कर सकते हैं, इसका मतलब है कि हम हास्केल कार्यक्रम के अनुरूप किसी भी प्रमाण में पूरी तरह से "विश्वास" नहीं कर सकते हैं जब तक कि हमारे पास एक अलग सबूत न हो कि कार्यक्रम स्वयं समाप्त हो रहा है।

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

Comments

यह जोर देने के लिए अच्छा हो सकता है कि गैर-संचय कुछ मायनों में प्रमाण को कम कर देता है, जबकि स्पष्ट रूप से एक तार्किक दृष्टिकोण से विनाशकारी, कई अन्य गुणों को संरक्षित करता है। विशेष रूप से, एक फ़ंक्शन A -> B, एक दिया जाता है A, या तो एक Bया कुछ भी पैदा नहीं करेगा । यह कभी भी उत्पादन नहीं करेगा C, और यह किस प्रकार का मूल्य Bप्रदान करता है, या यदि यह विचलन करता है, तब भी विशेष रूप से Aप्रदान किए गए पर निर्भर करता है।

@camccann - थोड़ा सा नाइटपिक, लेकिन मैं नीचे और "कुछ भी नहीं" के बीच अंतर करूंगा, जो अधिक पसंद है Void, नहीं? आलस्य इसे कम और जटिल दोनों बनाता है। मैं कहूंगा कि A -> B हमेशा एक फ़ंक्शन प्रकार का एक मूल्य पैदा करता है B, लेकिन उस मूल्य में कम जानकारी हो सकती है जिसकी अपेक्षा एक व्यक्ति करता है।

— sclv

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

Answer 3

प्रथम-क्रम सन्निकटन के लिए, अधिकांश अन्य (कमजोर और / या uni-typed) भाषाएँ कतई के बीच सख्त भाषा-स्तरीय परिसीमन का समर्थन नहीं करती हैं

• प्रस्ताव (यानी एक प्रकार)
• एक प्रमाण (यानी एक कार्यक्रम जो यह दर्शाता है कि हम कैसे आदिम और / या अन्य उच्च आदेश निर्माणों के सेट से प्रस्ताव का निर्माण कर सकते हैं )

और दोनों के बीच का सख्त रिश्ता। यदि कुछ भी हो, तो ऐसी अन्य भाषाओं की सर्वोत्तम गारंटी होती है

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

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

एक बालक थोड़ा अधिक कठोर होने के लिए, सामान्य विचार यह है कि (लगभग) सभी कार्यक्रम निर्माणों के लिए एक कठोर अंतर्ज्ञानवादी दृष्टिकोण लागू करके (अर्थात हम केवल यह साबित कर सकते हैं कि हम जो निर्माण कर सकते हैं), और ऐसे में आदिम लोगों के सेट को सीमित करके रास्ता जो हमारे पास है

• सभी भाषा प्रधानों के लिए सख्त प्रस्ताव
• तंत्र का एक सीमित सूट जिसके द्वारा आदिमों को जोड़ा जा सकता है

हास्केल निर्माण अपने व्यवहार के बारे में तर्क करने के लिए खुद को बहुत अच्छी तरह से उधार देते हैं। अगर हम एक सबूत (पढ़ें: फ़ंक्शन) का निर्माण कर सकते हैं जो यह साबित करता Aहै कि Bयह बहुत उपयोगी गुण है:

• यह हमेशा धारण करता है (जब तक हमारे पास एक है A, हम निर्माण कर सकते हैं B)
• यह निहितार्थ केवल पर निर्भर करता है A, और कुछ नहीं।

इस प्रकार हमें प्रभावी रूप से स्थानीय / वैश्विक आक्रमणकारियों के बारे में तर्क करने की अनुमति मिलती है। मूल प्रश्न पर वापस जाने के लिए; हास्केल की भाषा में इस मानसिकता को सर्वोत्तम रूप से चित्रित किया गया है:

• स्पष्ट निर्माणों में प्रभावों की शुद्धता / विभाजन (प्रभाव दोनों के लिए जिम्मेदार हैं और टाइप किए गए हैं!)
• Haskell संकलक में इन्वेंशन / चेकिंग टाइप करें
• प्रस्ताव / प्रकारों में नियंत्रण और / या डेटा प्रवाह अपरिवर्तकों को एम्बेड करने की क्षमता एक कार्यक्रम साबित करने के लिए सेट कर रहा है: (बहुरूपता के साथ, प्रकार परिवार, जीएडीटी आदि)
• निर्देशात्मक अखंडता

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

यह प्रश्न पर्याप्त रूप से गहन उत्तर देता है, और मैं संभवतः इस संदर्भ में न्याय नहीं कर सकता। मैं साहित्य में विकिपीडिया / पर अधिक पढ़ने का सुझाव दूंगा:

• करी-हावर्ड आइसोमोर्फिज्म
• लम्बा घन
• कंस्ट्रक्टिविस्ट / अंतर्ज्ञानवादी प्रकार का सिद्धांत
• कम्प्यूटेशनल ट्रिनिटेरियनवाद का बॉब हार्पर अवलोकन

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

Answer 4

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

Answer 5

क्लीन पदानुक्रम हमें पता चलता है कि सबूत कार्यक्रमों नहीं कर रहे हैं।

पहला पुनरावर्ती संबंध या तो है:

R1( Program , Iteration )  Program halts at Iteration.
R2( Theorem , Proof ) Proof proves a Theorem.

पहले पुनरावर्ती असंख्य संबंध हैं:

(exists x) R1( Program , x )  Program Halts.
(exists x) R2( Theorem , x)   Theorem is provable.

इसलिए कि एक कार्यक्रम एक प्रमेय है और जो कि मौजूद है उस पर चलने वाला पुनरावृत्ति प्रमाण की तरह है जो मौजूद है जो प्रमेय साबित होता है।

Program = Theorem
Iteration = Proof

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

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

Comments

इस सवाल का जवाब कैसे दिया जाता है, "ध्यान देने योग्य तरीके क्या हैं, जिनमें इस कथन ने भाषा के डिजाइन को प्रभावित किया है?"

— gnat

@gnat - यह उत्तर मूल प्रश्न के भीतर एक अंतर्निहित धारणा को संबोधित करता है, जिसका नाम है: " doesn't this really apply to pretty much all the programming languages?" यह उत्तर दावा करता है / दिखाता है कि अवैध होने का अनुमान है, इसलिए यह उन सवालों के बाकी हिस्सों को संबोधित करने का कोई मतलब नहीं है जो एक त्रुटिपूर्ण आधार पर आधारित हैं ।