टेनेंट के पत्राचार सिद्धांत का अच्छा विवरण क्या है?

Question

मैंने खुद को यह देखने के लिए संघर्ष करते हुए देखा कि इस सिद्धांत के बारे में क्या है और यह भाषा डिजाइन के लिए इतना महत्वपूर्ण क्यों है।

मूल रूप से, यह बताता है कि exprभाषा में प्रत्येक अभिव्यक्ति के लिए यह निर्माण बिल्कुल वैसा ही होना चाहिए:

(function () { return expr; })()

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

Comments

मैं यह नहीं देख सकता कि यह विषय क्यों है, क्या कोई इसे मुझे समझा सकता है?

— एंड्रयू

कुछ मुद्दे हैं; मैंने इसे छुआ है और इसे प्रोग्रामर्स को भेज रहा हूं, जहां इस तरह की चर्चाओं का थोड़ा और स्वागत है।

— बंद हुआ

रूबी इस सिद्धांत का पालन नहीं करती है: मान लें exprकि वर्तमान स्टैक ट्रेस मिलता है।

— लांडेई

Answer 1

मैंने "टेनेंट कॉरेस्पोंडेंस प्रिंसिपल" से पहले कभी नहीं सुना है और यहां तक ​​कि भाषा डिजाइन में भी कम महत्वपूर्ण नहीं है। भावों को देखते हुए लगता है कि सभी को 2006 के एक नील गेर के ब्लॉग का नेतृत्व करना चाहिए जो यह सोचता है कि वह क्या सोचता है और यह कैसे सोचता है कि इसे बंद करने के लिए भी लागू होना चाहिए। और फ़ोरम के अन्य सभी लोग गेयर की प्रविष्टि का उल्लेख करते हैं।

हालांकि यहां डगलस क्रॉकफोर्ड (एक नाम जिसे मैं जानता हूं और विश्वास करता हूं): http://java.sys-con.com/node/793338/ द्वारा "टीसीपी" का उल्लेख किया गया है । भाग में

कुछ चीजें हैं जो उस तरह से संलग्न नहीं की जा सकती हैं, जैसे कि रिटर्न स्टेटमेंट और ब्रेक स्टेटमेंट, जो कि टेनेंट के कॉरेस्पॉन्डेंस प्रिंसिपल (या टीसीपी) के दावे के अधिवक्ताओं के लिए एक बुरी गंध का एक लक्षण है। Yow! घ्राण मतिभ्रम से निपटने के बिना भाषा डिजाइन पहले से ही काफी कठिन है। इसलिए समस्या को बेहतर ढंग से समझने के लिए, मैंने टेनेंट की 1981 की पुस्तक, प्रोग्रामिंग लैंग्वेज के सिद्धांतों की एक प्रति खरीदी।

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

इसलिए ऐसा लगता है कि "टेनेंट कॉरेस्पॉन्डेंस प्रिंसिपल" नाम का गलत इस्तेमाल हुआ है, और जो भी नील बात करता है, उसे संभवतः "गॉगरेज इमेजिनरी एंड पॉसिबल जनरलाइज्ड टीसीपी" कहा जाना चाहिए ... या कुछ ऐसे। किसी भी घटना में एक आउट-ऑफ-प्रिंट पुस्तक नाम-पर्दा के पीछे छिपाने के लिए पर्याप्त नहीं है

Comments

+1 के लिए "गॉटर की इमेजिनेटेड एंड पॉसिबल जनरलाइज्ड टीसीपी"

— जेकोरा

Answer 2

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

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

Answer 3

क्लॉज रिंक: टेनेन्ट के "भाषा डिजाइन सिमेंटिक सिद्धांतों पर आधारित" के बारे में सिद्धांतों की
दिलचस्प व्याख्या देता है:
"पत्राचार वह सिद्धांत है जो हमें यह कहने देता है कि

let(this=obj, x=5) { .. }  

तथा

((function(x) { .. }).call(obj,5))  

समतुल्य होना चाहिए, और यह कि हम औपचारिक पैरामीटर सूचियों में कुछ भी कर सकते हैं, हमें घोषणाओं में भी सक्षम होना चाहिए, और इसके विपरीत। "[यह भी देखें, नीचे रिंकी, देखें]]

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

क्लॉस रिंकी: "हास्केल पर कार्यात्मक प्रोग्रामिंग, भाषा डिजाइन और दृढ़ता" पर

Comments

क्लॉस रिंकी: "हस्केल पर कार्यात्मक प्रोग्रामिंग, भाषा डिजाइन, और दृढ़ता" पर समुदाय.

— क्रिश

Answer 4

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

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

टीसीपी के किसी भी उल्लंघन से भविष्य में कुछ प्रोग्रामर को चोट लगने की संभावना है, जब वह उम्मीद करता है कि वह नॉन-क्लोजर कोड की तरह काम करना बंद कर देगा, लेकिन पाता है कि टीसीपी के उल्लंघन में, वे नहीं करते हैं।

Answer 5

आरई पायथन इस सिद्धांत का पालन नहीं कर रहा है। आम तौर पर, यह सिद्धांत का पालन करता है। मूल उदाहरण:

>>> x = ['foo']
>>> x
['foo']
>>> x = (lambda: ['foo'])()
>>> x
['foo']

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

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

एक समझदार वाक्य रचना का उपयोग करके एक आश्चर्य का सामना किया जा सकता है, हालांकि मेरा मानना ​​है कि यह टेनेंट सिद्धांत का उल्लंघन नहीं है। उदाहरण:

>>> [x for x in xrange(10)]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> [f() for f in [lambda: x for x in xrange(10)]]  # surprise!
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
>>> # application of Tennent principle to first expression
... [(lambda: x)() for x in xrange(10)]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> [f() for f in [(lambda x: lambda: x)(x) for x in xrange(10)]]  # force-rebind x
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> map(lambda f:f(), map(lambda x: lambda: x, xrange(10)))  # no issue with this form
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

आश्चर्य यह है कि सूची समझ कैसे परिभाषित की जाती है। उपरोक्त 'आश्चर्य' की समझ इस कोड के बराबर है:

>>> result = []
>>> for x in xrange(10):
...   # the same, mutable, variable x is used each time
...   result.append(lambda: x)
... 
>>> r2 = []
>>> for f in result:
...   r2.append(f())
... 
>>> r2
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]

इस तरह से देखें, तो ऊपर दिए गए 'आश्चर्य' की आशंका कम आश्चर्यजनक है, न कि टेन्नेन्ट सिद्धांत का उल्लंघन।