टाइपस्टेट विश्लेषण

From Vigyanwiki

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

टाइपस्टेट व्यवहार प्रकार के परिशोधन का प्रतिनिधित्व करने में सक्षम हैं जैसे कि विधि A को विधि B से पहले लागू किया जाना चाहिए, और विधि C को बीच में लागू नहीं किया जा सकता है। टाइपस्टेट्स उन संसाधनों का प्रतिनिधित्व करने के लिए उपयुक्त हैं जो ओपन/क्लोज़ अर्थविज्ञान का उपयोग शब्दार्थिक रूप से मान्य अनुक्रमों को लागू करके करते हैं जैसे कि ओपन फिर क्लोज अमान्य अनुक्रमों के विपरीत जैसे कि एक ओपन स्थिति में संचिका छोड़ना है। ऐसे संसाधनों में संचिका प्रणाली तत्व, लेन-देन, संयोजन और विज्ञप्ति सम्मिलित हैं। उदाहरण के लिए, विकासक यह निर्दिष्ट करना चाह सकते हैं कि संचिका या गर्तिका को पढ़ने या लिखे जाने से पहले खोला जाना चाहिए, और अगर उन्हें बंद कर दिया गया है तो उन्हें अब पढ़ा या लिखा नहीं जा सकता है। टाइपस्टेट नाम इस तथ्य से उपजा है कि इस प्रकार का विश्लेषण प्रायः प्रत्येक प्रकार की वस्तु को परिमित स्तिथि मशीन के रूप में प्रतिरूप करता है। इस स्तिथि मशीन में, प्रत्येक स्तिथि में अनुमत विधियों/संदेशों का एक अच्छी तरह से परिभाषित सम्मुच्चय होता है, और विधि आमंत्रण स्तिथि संक्रमण का कारण बन सकता है। शोधन प्रकार के साथ उपयोग के लिए पेट्री जाल को संभावित व्यवहार प्रतिरूप के रूप में भी प्रस्तावित किया गया है। [1]

1983 में रोब स्ट्रोम द्वारा टाइपस्टेट विश्लेषण [2] थॉमस जे. वॉटसन रिसर्च सेंटर आईबीएम की वॉटसन लैब में विकसित नेटवर्क कार्यान्वयन भाषा (NIL) में प्रस्तुत किया गया था। इसे 1986 के एक लेख में स्ट्रोम और येमिनी द्वारा औपचारिक रूप दिया गया था[3] यह वर्णन करता है कि टाइपस्टेट का उपयोग चर के आरंभीकरण की घात को पथानुसरण करने के लिए कैसे किया जाता है, यह प्रत्याभुति देता है कि अनुचित तरीके से आरंभिक डेटा पर संचालन कभी भी लागू नहीं किया जाएगा, और आगे हर्मीस (प्रोग्रामिंग भाषा) प्रोग्रामिंग भाषा में सामान्यीकृत किया जाएगा।

हाल के वर्षों में, विभिन्न अध्ययनों ने उद्देश्य-अभिविन्यस्त भाषाओं में टाइपस्टेट अवधारणा को लागू करने के तरीके विकसित किए हैं। [4][5]


दृष्टिकोण

प्रकार के एक चर के आरंभीकरण से उत्पन्न होने वाली नॉनलाइनियर टाइपस्टेट जाली struct{int x;int y;int z;}.
न्यूनतम तत्व ⊥ स्तिथि के साथ मेल खाता है ∅ कोई संरचना घटक प्रारंभ नहीं हुआ है।

स्ट्रोम और येमिनी (1986) को किसी दिए गए प्रकार के लिए टाइपस्टेट के सेट को आंशिक रूप से अनुक्रम करने की आवश्यकता थी, ताकि कुछ जानकारी को त्यागकर निम्न टाइपस्टेट को उच्चतर से प्राप्त किया जा सके। उदाहरण के लिए, C में एक int परिवर्त्य में सामान्यतः टाइपस्टेट्स "अनइनिशियलाइज्ड" < "इनिशियलाइज्ड" होते हैं, और एक FILE* सूचक में टाइपस्टेट्स "अनअलोकेटेड" < "आवंटित, लेकिन अनइनिशियलाइज्ड" < "इनिशियलाइज्ड, लेकिन फाइल नहीं खोली गई" < " हो सकती है। इसके अतिरिक्त, स्ट्रोम और येमिनी की आवश्यकता है कि प्रत्येक दो टाइपस्टेट्स की सबसे बड़ी निचली सीमा हो, यानी कि आंशिक क्रम एक मीट-सेमिलैटिस भी हो; और प्रत्येक क्रम में एक न्यूनतम तत्व होता है, जिसे हमेशा "⊥" कहा जाता है।

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

int n;                // here, n has typestate "uninitialized"
if (...) {
    n = 5;            // here, n has typestate   "initialized"
} else {
    /*do nothing*/    // here, n has typestate "uninitialized"
}                     // here, n has typestate "uninitialized" = greatest_lower_bound("initialized","uninitialized")

हर बुनियादी संचालन [note 1] एक टाइपस्टेट परिवर्तन से लैस होना चाहिए, यानी प्रत्येक मापदण्ड के लिए क्रमशः संचालन से पहले और बाद में आवश्यक और सुनिश्चित टाइपस्टेट है। उदाहरण के लिए, एक संचालन fwrite(...,fd) fd टाइपस्टेट संचिका खोलने के लिए आवश्यक है। अधिक सटीक रूप से, एक संचालन के कई 'परिणाम' हो सकते हैं, जिनमें से प्रत्येक को अपने स्वयं के टाइपस्टेट संक्रमण की आवश्यकता होती है। उदाहरण के लिए, सी कोड FILE *fd=fopen("foo","r") सम्मुच्चय fdफ़ाइल खोलने के लिए टाइपस्टेट खोला गया और आवंटित नहीं किया गया यदि उद्घाटन क्रमशः सफल होता है और विफल रहता है।

प्रत्येक दो टाइपस्टेट्स के लिए T1 समुपयोग संबंध <· T2, एक अद्वितीय टाइपस्टेट जबरदस्ती संचालन प्रदान करने की आवश्यकता है, जो टाइपस्टेट T2 की वस्तु पर लागू होने पर, इसके टाइपस्टेट को t1 तक कम कर देता है, संभवतः कुछ संसाधन जारी करके कम कर देता है। उदाहरण के लिए, fclose(fd) कोएर्स fdसंचिका से टाइपस्टेट प्रारंभ करने के लिए खोला गया, लेकिन संचिका नहीं खोली गई।

एक प्रोग्राम निष्पादन को 'टाइपस्टेट-करेक्ट' कहा जाता है यदि

  • प्रत्येक मूल संचालन से पहले, सभी मापदंडों में संचालन के टाइपस्टेट परिवर्तन के लिए आवश्यक टाइपस्टेट होता है, और
  • कार्यक्रम समाप्ति पर, सभी चर टाइपस्टेट ⊥ में हैं। [note 2]

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

प्रस्ताव

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

एक अन्य विषय के रूप में, कुछ कार्यक्रमों के लिए, निष्पादन पथों को अभिसरण करने और संबंधित डाउन-कॉर्सियन संचालन को जोड़ने के लिए सबसे बड़ी निचली सीमा लेने की विधि अपर्याप्त प्रतीत होती है। उदाहरण के लिए, इससे पहले वापसी 1 निम्नलिखित कार्यक्रम में,[note 3] सभी घटक एक्स </ कोड>, वाई, और z का coord आरंभीकृत हैं, लेकिन स्ट्रोम और येमिनी का दृष्टिकोण इसे पहचानने में विफल रहता है, क्योंकि लूप बॉडी में एक स्ट्रक्चर घटक के प्रत्येक प्रारंभन को पहले लूप एंट्री के टाइपस्टेट को पूरा करने के लिए लूप पुनः प्रविष्ट पर डाउन-कॉर्स्ड करना पड़ता है। अर्थात। ⊥। एक संबंधित समस्या यह है कि इस उदाहरण में टाइपस्टेट परिवर्तन के अति भराई की आवश्यकता होगी; उदाहरण के लिए, parse_int_attr( x ,&coord->x) एक टाइपस्टेट को बदलता है कोई घटक x घटक के लिए आरंभीकृत नहीं होता है, बल्कि y घटक को x और y घटक के लिए आरंभीकृत किया जाता है।

int parse_coord(struct { int x; int y; int z; } *coord) {
    int seen = 0;     /* remember which attributes have been parsed */

    while (1)
        if      (parse_int_attr("x", &coord->x)) seen |= 1;
        else if (parse_int_attr("y", &coord->y)) seen |= 2;
        else if (parse_int_attr("z", &coord->z)) seen |= 4;
        else break;

    if (seen != 7)    /* some attribute missing, fail */
        return 0;
    ...               /* all attributes present, do some computations and succeed */
    return 1;
}

टाइपस्टेट अनुमान

ऐसे कई दृष्टिकोण हैं जो कार्यक्रमों 

(या अनुबंध जैसी अन्य कलाकृतियों) से टाइपस्टेट्स का अनुमान लगाने की कोशिश कर रहे हैं। उनमें से कई संकलन समय पर टाइपस्टेट्स का अनुमान लगा सकते हैं और अन्य मॉडल को गतिशील रूप से माइन कर सकते हैं।


टाइपस्टेट का समर्थन करने वाली भाषाएं

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

यह भी देखें

टिप्पणियाँ

  1. ↑ these include language constructs, e.g. += in C, and standard library routines, e.g.fopen()
  2. ↑ This aims at ensuring that e.g. all files have been closed, and all malloced memory has been freed. In most programming languages, a variable's lifetime may end before program termination; the notion of typestate-correctness has then to be sharpened accordingly.
  3. ↑ assuming that int parse_int_attr(const char *name,int *val) initializes *val whenever it succeeds


संदर्भ

  1. ↑ Jorge Luis Guevara D´ıaz (2010). "टाइपस्टेट उन्मुख डिजाइन - एक रंगीन पेट्री नेट दृष्टिकोण" (PDF).
  2. ↑ Strom, Robert E. (1983). "Mechanisms for compile-time enforcement of security". Proceedings of the 10th ACM SIGACT-SIGPLAN symposium on Principles of programming languages - POPL '83. pp. 276–284. doi:10.1145/567067.567093. ISBN 0897910907.
  3. ↑ Strom, Robert E.; Yemini, Shaula (1986). "Typestate: A programming language concept for enhancing software reliability" (PDF). IEEE Transactions on Software Engineering. IEEE. 12: 157–171. doi:10.1109/tse.1986.6312929.
  4. ↑ DeLine, Robert; Fähndrich, Manuel (2004). "वस्तुओं के लिए टाइपस्टेट्स". ECOOP 2004: Proceedings of the 18th European Conference on Object-Oriented Programming. Lecture Notes in Computer Science. Springer. 3086: 465–490. doi:10.1007/978-3-540-24851-4_21. ISBN 978-3-540-22159-3.
  5. ↑ Bierhoff, Kevin; Aldrich, Jonathan (2007). "अलियास्ड ऑब्जेक्ट्स की मॉड्यूलर टाइपस्टेट जाँच". OOPSLA '07: Proceedings of the 22nd ACM SIGPLAN Conference on Object-Oriented Programming: Systems, Languages and Applications. 42 (10): 301–320. doi:10.1145/1297027.1297050. ISBN 9781595937865.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=टाइपस्टेट_विश्लेषण&oldid=200692’