वास्तव में एक टाइपकेचर के लिए शुद्धता का प्रमाण क्या साबित होना चाहिए?

Question

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

मेरा सवाल यह है कि अगर मैं एक प्रोग्रामिंग भाषा के लिए एक प्रकार का आक्षेप और जाँच कार्यक्रम लिखने की कोशिश करता हूं, और मैं यह साबित करना चाहता हूं कि मेरा टाइपसेकर काम करता है, तो वास्तव में मैं क्या प्रमाण देख रहा हूं?

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

Comments

शायद आप स्पष्ट कर सकते हैं कि क्या आप जानना चाहते हैं (1) क्या आपका कार्यान्वयन किसी दिए गए टाइपिंग सिस्टम लागू करता है , या (2) क्या आपका टाइपिंग सिस्टम उन त्रुटियों को रोकता है जो आपको लगता है कि इसे करना चाहिए? वे अलग सवाल हैं। $T$$T$

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

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

— विवेक ग्यासस

(1) वास्तव में कार्यक्रम सत्यापन में एक सवाल है और टाइपिंग के साथ बहुत कम है। बस यह दिखाने की जरूरत है कि आपका कार्यान्वयन इसके विनिर्देशन को पूरा करता है। जैसा कि, (2), पहले परिभाषित करें कि तात्कालिक प्रकार की त्रुटि होने का क्या मतलब है (जैसे 2 + "hello"कि शब्द 'अटक')। एक बार जब यह औपचारिक हो जाता है, तो आप टाइप साउंडनेस प्रमेय साबित कर सकते हैं। इसका मतलब है कि कोई भी टाइप करने योग्य कार्यक्रम कभी भी तत्काल प्रकार की त्रुटि में विकसित नहीं हो सकता है। औपचारिक रूप से, आप को साबित है कि यदि एक कार्यक्रम typable है, और किसी भी के लिए : अगर रन चरणों बनने के लिए , तो एक तत्काल प्रकार की त्रुटि नहीं है। (१/२)$M$$n \geq$$M$$n$$N$$N$

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

यह आमतौर पर पर इंडक्शन द्वारा और टाइपिंग जुडेमेंट की व्युत्पत्ति पर सिद्ध होता है। (२/२)$n$

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

धन्यवाद! आपके स्पष्टीकरण के आधार पर, ऐसा लगता है कि (2) वास्तव में मैं क्या देख रहा था। क्या आप कृपया इसका उत्तर दे सकते हैं? (और शायद आपको लगता है कि उपयोगी हो सकता है किसी भी विवरण में जोड़ें।) मुझे लगता है कि जवाब के रूप में स्वीकार करेंगे! :)

— विवेक ग्यासस

Answer 1

प्रश्न की व्याख्या दो तरीकों से की जा सकती है:

• क्या कार्यान्वयन किसी दिए गए टाइपिंग सिस्टम को लागू करता है ?$T$
• क्या टाइपिंग सिस्टम उन त्रुटियों को रोकता है जो आपको लगता है कि इसे करना चाहिए?$T$

पूर्व वास्तव में कार्यक्रम सत्यापन में एक सवाल है और टाइपिंग के साथ बहुत कम है। बस यह दिखाने की जरूरत है कि आपका क्रियान्वयन इसके विनिर्देशन को पूरा करता है, पपीज का जवाब देखें।

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

• सबसे पहले, आप औपचारिक रूप से परिभाषित करते हैं कि प्रोग्राम के लिए तात्कालिक टाइपिंग त्रुटि होने का क्या मतलब है । इसे परिभाषित करने के कई तरीके हैं - यह आपके ऊपर है। आमतौर पर हम जैसे कार्यक्रमों को रोकना चाहते हैं 2 + "hello"। दूसरे शब्दों में, आपको कार्यक्रमों के एक सबसेट को परिभाषित करने की आवश्यकता है, उन्हें बुरा कहें , जिसमें तत्काल टाइपिंग त्रुटि वाले कार्यक्रम शामिल हैं।

• तब आपको यह साबित करना होगा कि जो प्रोग्राम टाइप किए जा सकते हैं वे कभी भी बैड में प्रोग्राम में विकसित नहीं हो सकते हैं । आइए इसको औपचारिक रूप दें। अपने टाइपिंग निर्णय होने दो याद रखें कि इसे पढ़ा जाना चाहिए: प्रोग्राम M में टाइप α है , यह मानते हुए कि मुक्त चर पर्यावरण typ द्वारा दिए गए हैं । फिर जो प्रमेय आप सिद्ध करना चाहते हैं वह है:$\Gamma \vdash M : \alpha.$$M$$\alpha$$\Gamma$

  प्रमेय। जब भी और एम → ⋯ → एन तो एन ∉ बुरा ।$\Gamma \vdash M : \alpha$$M \rightarrow \cdots \rightarrow N$$N \notin$

  इस प्रमेय को कैसे साबित किया जाए यह भाषा के विवरण, टाइपिंग सिस्टम और बैड के विकल्प पर निर्भर करता है ।

परिभाषित करने का एक मानक तरीका बुरा कहने के लिए है: एक शब्द एक तत्काल प्रकार की त्रुटि है तो यह न तो एक मूल्य है और न ही कमी कदम है एम → एन । (इस मामले में एम को अक्सर अटक के रूप में संदर्भित किया जाता है ।) यह केवल छोटे चरण के संचालन शब्दार्थ के लिए काम करता है। प्रमेय साबित करने का एक मानक तरीका यह दिखाना है$M$$M \rightarrow N$$M$

• और एम → एन एक साथ मतलब गामा ⊢ एन : α । इसे "विषय में कमी" कहा जाता है। यह आमतौर पर टाइपिंग फैसले की व्युत्पत्ति, और कटौती की लंबाई पर एक साथ प्रेरण द्वारा सिद्ध होता है।$\Gamma \vdash M : \alpha$$M \rightarrow N$$\Gamma \vdash N : \alpha$

• जब भी तो एम में नहीं है बुरा । यह आमतौर पर टाइपिंग फैसले की व्युत्पत्ति पर प्रेरण द्वारा भी साबित होता है।$\Gamma \vdash M : \alpha$$M$

ध्यान दें कि सभी टाइपिंग सिस्टम में "विषय में कमी" नहीं है, उदाहरण के लिए सत्र प्रकार। इस मामले में, अधिक परिष्कृत प्रमाण तकनीकों की आवश्यकता होती है।

Answer 2

यह एक अच्छा सवाल है! यह पूछता है कि हम टाइप भाषा में किस प्रकार की अपेक्षा करते हैं।

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

प्रकारों को समझने के कई तरीके हैं, लेकिन एक प्रोग्रामर के दृष्टिकोण से मुझे लगता है कि निम्नलिखित उपयोगी है। एक विनिर्देश या गारंटी के रूप में एक प्रकार के बारे में सोचें । ऐसा कहा जा सकता प्रकार है एक कहना है कि "हम गारंटी / उम्मीद / मांग है कि ई संपत्ति द्वारा इनकोडिंग संतुष्ट एक "। अक्सर A कुछ सरल होता है , जैसे कि संपत्ति केवल "यह एक पूर्णांक" है।$e$$A$$e$$A$$A$int

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

प्रोग्रामिंग भाषा डिजाइन में प्रकारों की कला, अभिव्यक्ति और सरलता को संतुलित करने में से एक है :

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

सादगी को कम करके आंका नहीं जाना चाहिए, क्योंकि प्रोग्रामिंग प्रोग्राम के सिद्धांत में प्रत्येक प्रोग्रामर के पास पीएचडी नहीं है।

तो चलिए हम आपके सवाल पर वापस आते हैं: आप कैसे जानते हैं कि आपका टाइप सिस्टम अच्छा है ? ठीक है, उन प्रमेयों को सिद्ध करें जो आपके प्रकारों को संतुलित दिखाते हैं। दो प्रकार के प्रमेय होंगे:

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

2. प्रमेय जो कहते हैं कि आपके प्रकार सरल हैं । एक बुनियादी बात यह होगी कि यह निर्णायक है कि क्या किसी दिए गए अभिव्यक्ति का एक प्रकार है। एक अन्य सादगी सुविधा एक प्रकार का जिक्र करने के लिए एक एल्गोरिथ्म देना है। सादगी के बारे में अन्य प्रमेय यह होगा: कि एक अभिव्यक्ति में सबसे अधिक एक प्रकार होता है, या कि एक अभिव्यक्ति का एक प्रमुख प्रकार होता है (यानी, सभी प्रकारों में "सर्वश्रेष्ठ" एक)।

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

Comments

उस विस्तृत उत्तर के लिए धन्यवाद! हालाँकि, मैं अभी भी अपने प्रश्न के उत्तर के बारे में निश्चित नहीं हूं। एक ठोस उदाहरण के रूप में, आइए C - एक सरल पर्याप्त प्रकार की प्रणाली के साथ एक सांख्यिकीय रूप से टाइप की गई भाषा लें। अगर मैंने C के लिए एक टाइप-टेकर लिखा है, तो मैं कैसे साबित करूँगा कि मेरा टाइप-टेकर "सही" है? एचएम कहते हैं कि यह उत्तर कैसे बदलता है यदि मैंने हस्केल के लिए एक प्रकार का चेकर लिखा है, तो एचएम कहें। अब मैं "शुद्धता" कैसे साबित करूँगा?

— विवेक ग्यासस

1. वास्तव में सी के लिए एक गणितीय इकाई के रूप में टाइप सिस्टम को परिभाषित करें (ताकि आप इसके बारे में प्रमेय साबित कर सकें)। 2. अपने टाइपटेकर को लागू करें, या प्रकार की जाँच के लिए एक एल्गोरिथ्म का वर्णन करें। 3. साबित प्रमेय: * मेरी typechecker जांच करता है कि यदि ई प्रकार है एक फिर वहाँ प्रकार प्रणाली में एक व्युत्पत्ति है टी दिखा रहा है कि ई प्रकार है$T$$e$$A$$T$$e$$A$

मैं एक संयोजन के रूप में 2. और 3. करने की सलाह दूंगा। इसके अलावा, CompCert पर एक नजर है ।

— एंड्रेज बॉयर

$T$$e$$A$$e$$A$$e$

$A$$A$$e$

Answer 3

कुछ अलग चीजें हैं जो आप "मेरे टाइपराइटर काम करता है" साबित कर सकते हैं। जो, मुझे लगता है, जो आपका सवाल पूछ रहा है उसका हिस्सा है;)

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

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

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

Comments

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

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

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

— नोआम ज़िलबर्गर

@NoamZeilberger "सवाल यह है," मार्टिन ने कहा, "क्या आप शब्दों को इतनी अलग चीजों से मतलब कर सकते हैं।"

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

जब मैंने टाइपिंग सिस्टम और प्रोग्रामिंग लैंग्वेज शब्दार्थ के बारे में सीखा, तो मुझे यह एहसास हुआ कि मॉडल ऑपरेशनल सिमेंटिक्स के बारे में केवल प्रूफ तकनीक हैं, बजाय खुद को समाप्त करने के, बेहद स्वतंत्र रूप से।

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

ध्वनि और पूर्णता के माध्यम से विभिन्न मॉडलों का संबंध अंतर्दृष्टि के हस्तांतरण के लिए एक महत्वपूर्ण वैज्ञानिक पद्धति है।

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