टाइप इनफरेंस: Difference between revisions

Revision as of 11:53, 17 July 2023

प्रकार अनुमान का तात्पर्य औपचारिक भाषा में अभिव्यक्ति के प्रकार का स्वचालित पता लगाना है। इनमें प्रोग्रामिंग भाषाएं और गणितीय प्रकार की प्रणालियाँ शामिल हैं, लेकिन कंप्यूटर विज्ञान और भाषा विज्ञान की कुछ शाखाओं में प्राकृतिक भाषाएँ भी शामिल हैं।

गैरतकनीकी स्पष्टीकरण

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

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

टाइपिंग में, एक अभिव्यक्ति एक प्रकार का विरोध करती है। उदाहरण के लिए, $4$ , $2+2$ , और $2\cdot 2$ सभी प्रकार के साथ अलग-अलग शब्द हैं $\mathrm {nat}$ प्राकृतिक संख्याओं के लिए. परंपरागत रूप से, अभिव्यक्ति के बाद कोलन और उसका प्रकार आता है, जैसे $2:\mathrm {nat}$ . इसका मतलब यह है कि मूल्य $2$ प्रकार का है $\mathrm {nat}$ . इस फॉर्म का उपयोग नए नामों की घोषणा करने के लिए भी किया जाता है, जैसे $n:\mathrm {nat}$ , बहुत कुछ जासूस डेकर शब्दों द्वारा एक दृश्य में एक नए चरित्र को पेश करने जैसा है ।

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

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

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

प्रकार-जाँच बनाम प्रकार-अनुमान

टाइपिंग में, एक अभिव्यक्ति E, टाइप T के विपरीत होती है, जिसे औपचारिक रूप से E : T के रूप में लिखा जाता है। आमतौर पर टाइपिंग केवल कुछ संदर्भों में ही समझ में आती है, जिसे यहां छोड़ दिया गया है।

इस सेटिंग में, निम्नलिखित प्रश्न विशेष रूप से रुचिकर हैं:

E : T? इस मामले में, अभिव्यक्ति E और प्रकार T दोनों दिए गए हैं। अब, क्या E वास्तव में एक T है? इस परिदृश्य को प्रकार-जाँच के रूप में जाना जाता है।
E : _? यहाँ केवल अभिव्यक्ति ही ज्ञात है। यदि ई के लिए प्रकार प्राप्त करने का कोई तरीका है, तो हमने प्रकार अनुमान पूरा कर लिया है।
_ : T? विपरीत स्थिति। केवल एक प्रकार दिया गया है, क्या इसके लिए कोई अभिव्यक्ति है या प्रकार का कोई मूल्य नहीं है? क्या कोई T का उदाहरण है?

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

प्रोग्रामिंग भाषाओं में प्रकार

प्रकार कुछ दृढ़तापूर्वक सांख्यिकीय रूप से टाइप की गई भाषाओं में मौजूद एक विशेषता है। यह अक्सर सामान्य रूप से कार्यात्मक प्रोग्रामिंग भाषाओं की विशेषता होती है। कुछ भाषाएँ जिनमें प्रकार का अनुमान शामिल है उनमें C23, ^[1] C++11,^[2] C# (संस्करण 3.0 से शुरू), चैपल, क्लीन, क्रिस्टल, डी, एफ#, ^[3] फ्रीबेसिक, गो, हास्केल, जावा (शुरू) शामिल हैं। संस्करण 10 के साथ), जूलिया, ^[4] कोटलिन,^[5] एमएल, निम, ओकैमल, ओपा, क्यू#, आरपाइथॉन, रस्ट, ^[6] स्काला,^[7] स्विफ्ट,^[8] टाइपस्क्रिप्ट,^[9] वैला, ^[10] डार्ट, ^[11] और विज़ुअल बेसिक [12] (संस्करण 9.0 से शुरू)। उनमें से अधिकांश प्रकार के अनुमान के सरल रूप का उपयोग करते हैं; हिंडले-मिलनर प्रकार प्रणाली अधिक पूर्ण प्रकार का अनुमान प्रदान कर सकती है। प्रकारों का अनुमान लगाने की क्षमता स्वचालित रूप से कई प्रोग्रामिंग कार्यों को आसान बनाती है, जिससे प्रोग्रामर प्रकार की जांच की अनुमति देते हुए प्रकार एनोटेशन को छोड़ने के लिए स्वतंत्र हो जाता है।

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

int add_one(int x) {
    int result; /* declare integer result */

    result = x + 1;
    return result;
}

इस फ़ंक्शन परिभाषा का प्रकार हस्ताक्षर, int add_one(int x), यह घोषणा करता है add_one एक फ़ंक्शन है जो एक तर्क, एक पूर्णांक (कंप्यूटर विज्ञान) लेता है, और एक पूर्णांक लौटाता है। int result; घोषित करता है कि स्थानीय चर result एक पूर्णांक है. प्रकार के अनुमान का समर्थन करने वाली एक काल्पनिक भाषा में, कोड को इस तरह लिखा जा सकता है:

add_one(x) {
    var result;  /* inferred-type variable result */
    var result2; /* inferred-type variable result #2 */

    result = x + 1;
    result2 = x + 1.0;  /* this line won't work (in the proposed language) */
    return result;
}

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

उस काल्पनिक भाषा में जिसमें अंतिम उदाहरण लिखा गया है, संकलक यह मान लेगा कि, इसके विपरीत जानकारी के अभाव में, + दो पूर्णांक लेता है और एक पूर्णांक लौटाता है। (उदाहरण के लिए, ओकैमल में यह इसी तरह काम करता है।) इससे, प्रकार का अनुमान लगाने वाला यह अनुमान लगा सकता है कि x + 1 का प्रकार एक पूर्णांक है, जिसका अर्थ है कि resultएक पूर्णांक है और इस प्रकार add_one का वापसी मान एक पूर्णांक है। इसी तरह, चूंकि + के लिए आवश्यक है कि उसके दोनों तर्क एक ही प्रकार के हों, x एक पूर्णांक होना चाहिए, और इस प्रकार, add_one एक पूर्णांक को एक तर्क के रूप में स्वीकार करता है।

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

हालाँकि, अक्सर, विकृत प्रकार-अनुमान एल्गोरिदम का उपयोग किया जाता है जो पीछे नहीं जा सकता है और इसके बजाय ऐसी स्थिति में एक त्रुटि संदेश उत्पन्न करता है। यह व्यवहार बेहतर हो सकता है क्योंकि प्रकार का अनुमान हमेशा एल्गोरिदमिक रूप से तटस्थ नहीं हो सकता है, जैसा कि पिछले फ़्लोटिंग-पॉइंट परिशुद्धता मुद्दे द्वारा दर्शाया गया है।

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

अंत में, जटिल प्रकार-अनुमान एल्गोरिदम का एक महत्वपूर्ण नकारात्मक पक्ष यह है कि परिणामी प्रकार अनुमान संकल्प मनुष्यों के लिए स्पष्ट नहीं होगा (विशेष रूप से बैकट्रैकिंग के कारण), जो हानिकारक हो सकता है क्योंकि कोड मुख्य रूप से मनुष्यों के लिए समझने योग्य है।

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

एक संस्करण जो पूर्णांक इनपुट स्वीकार करता है और अंतर्निहित प्रकार रूपांतरण का उपयोग करता है।

एक संस्करण जो फ़्लोटिंग-पॉइंट नंबर को इनपुट के रूप में स्वीकार करता है और पूरे फ़्लोटिंग पॉइंट निर्देशों का उपयोग करता है।

तकनीकी विवरण

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

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

उच्च-क्रम प्रोग्रामिंग और बहुरूपता (कंप्यूटर विज्ञान) के जटिल रूपों में, संकलक के लिए उतना अनुमान लगाना हमेशा संभव नहीं होता है, और कभी-कभी अस्पष्टता के लिए टाइप एनोटेशन आवश्यक होते हैं। उदाहरण के लिए, बहुरूपी पुनरावर्तन के साथ प्रकार का अनुमान अनिर्णीत माना जाता है। इसके अलावा, स्पष्ट प्रकार के एनोटेशन का उपयोग कंपाइलर को अनुमान से अधिक विशिष्ट (तेज़/छोटे) प्रकार का उपयोग करने के लिए मजबूर करके कोड को अनुकूलित करने के लिए किया जा सकता है।^[12] प्रकार अनुमान की कुछ विधियाँ बाधा संतुष्टि समस्या पर आधारित हैं^[13] या संतुष्टि मॉड्यूलो सिद्धांत।^[14]

उदाहरण

उदाहरण के तौर पर, हास्केल (प्रोग्रामिंग भाषा) फ़ंक्शन map सूची के प्रत्येक तत्व पर एक फ़ंक्शन लागू करता है, और इसे इस प्रकार परिभाषित किया जा सकता है:

map f [] = []
map f (first:rest) = f first : map f rest

पर अनुमान टाइप करें map फ़ंक्शन निम्नानुसार आगे बढ़ता है। map दो तर्कों का एक फ़ंक्शन है, इसलिए इसका प्रकार फॉर्म के रूप में बाध्य है a → b → c. हास्केल में, पैटर्न [] और (first:rest) हमेशा सूचियों से मेल खाते हैं, इसलिए दूसरा तर्क एक सूची प्रकार होना चाहिए: b = [d] किसी प्रकार के लिए d. यह पहला तर्क है f तर्क के लिए फ़ंक्शन अनुप्रयोग है first, जिसका प्रकार होना चाहिए d, सूची तर्क में प्रकार के अनुरूप, इसलिए f :: d → e (:: किसी प्रकार के लिए साधन ) प्रकार का है e. का वापसी मूल्य map f, अंततः, जो कुछ भी है उसकी एक सूची है f पैदा करता है, इसलिए [e].

भागों को एक साथ रखने से परिणाम मिलता है map :: (d → e) → [d] → [e]. प्रकार चर के बारे में कुछ भी विशेष नहीं है, इसलिए इसे पुनः लेबल किया जा सकता है

map :: (a → b) → [a] → [b]

यह पता चला है कि यह भी सबसे सामान्य प्रकार है, क्योंकि कोई और बाधा लागू नहीं होती है। जैसा कि अनुमान लगाया गया है map पैरामीट्रिक बहुरूपता है, तर्कों और परिणामों का प्रकार f अनुमान नहीं लगाया गया है, लेकिन प्रकार चर के रूप में छोड़ दिया गया है, इत्यादि map विभिन्न प्रकार के कार्यों और सूचियों पर लागू किया जा सकता है, जब तक कि प्रत्येक आह्वान में वास्तविक प्रकार मेल खाते हों।

हिंडले-मिलनर प्रकार अनुमान एल्गोरिथ्म

पहले प्रकार का अनुमान लगाने के लिए उपयोग किए जाने वाले एल्गोरिदम को अब अनौपचारिक रूप से हिंडले-मिलनर एल्गोरिदम कहा जाता है, हालांकि एल्गोरिदम को उचित रूप से दमास और मिलनर को जिम्मेदार ठहराया जाना चाहिए।^[15] इस एल्गोरिदम का मूल सरल रूप से टाइप किए गए लैम्ब्डा कैलकुलस के लिए प्रकार अनुमान एल्गोरिदम है जिसे 1958 में हास्केल करी और रॉबर्ट फेयस द्वारा तैयार किया गया था।^{[citation needed]} 1969 में जे. रोजर हिंडले ने इस काम को आगे बढ़ाया और साबित किया कि उनका एल्गोरिदम हमेशा सबसे सामान्य प्रकार का अनुमान लगाता है। 1978 में रॉबिन मिलनर,^[16] हिंडले के काम से स्वतंत्र, एक समतुल्य एल्गोरिदम, एल्गोरिदम डब्ल्यू प्रदान किया गया। 1982 में लुई दामास^[15]अंततः साबित हुआ कि मिलनर का एल्गोरिदम पूर्ण है और इसे बहुरूपी संदर्भों वाले सिस्टम का समर्थन करने के लिए विस्तारित किया गया है।

सबसे सामान्य प्रकार का उपयोग करने के दुष्प्रभाव

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

फ़्लोटिंग-पॉइंट को एक सामान्य प्रकार का पूर्णांक माना जाता है, जबकि फ़्लोटिंग-पॉइंट सटीक मुद्दों को पेश करेगा
भिन्न/गतिशील प्रकारों को अन्य प्रकारों के एक सामान्य प्रकार के रूप में माना जा रहा है, जो कास्टिंग नियमों और तुलनाओं को पेश करेगा जो भिन्न हो सकते हैं, उदाहरण के लिए ऐसे प्रकार संख्यात्मक जोड़ और स्ट्रिंग संयोजन दोनों के लिए '+' ऑपरेटर का उपयोग करते हैं, लेकिन कौन सा ऑपरेशन किया जाता है स्थिर के बजाय गतिशील रूप से निर्धारित किया जाता है

प्राकृतिक भाषाओं के लिए प्रकार का अनुमान

प्राकृतिक भाषाओं के साथ-साथ प्रोग्रामिंग भाषाओं का विश्लेषण करने के लिए प्रकार अनुमान एल्गोरिदम का उपयोग किया गया है।^[17]^[18]^[19] कुछ व्याकरण प्रेरण में प्रकार अनुमान एल्गोरिदम का भी उपयोग किया जाता है^[20]^[21] और प्राकृतिक भाषाओं के लिए बाधा-आधारित व्याकरण प्रणालियाँ।^[22]

संदर्भ

↑ "WG14-N3007 : Type inference for object definitions". open-std.org. 2022-06-10. Archived from the original on December 24, 2022.
↑ "प्लेसहोल्डर प्रकार विनिर्देशक (C++11 के बाद से) - cppreference.com". en.cppreference.com. Retrieved 2021-08-15.
↑ cartermp. "अनुमान प्रकार - एफ#". docs.microsoft.com (in English). Retrieved 2020-11-21.
↑ "Inference · The Julia Language". docs.julialang.org. Retrieved 2020-11-21.
↑ "कोटलिन भाषा विशिष्टता". kotlinlang.org. Retrieved 2021-06-28.
↑ "कथन - जंग संदर्भ". doc.rust-lang.org. Retrieved 2021-06-28.
↑ "अनुमान टाइप करें". Scala Documentation. Retrieved 2020-11-21.
↑ "The Basics — The Swift Programming Language (Swift 5.5)". docs.swift.org. Retrieved 2021-06-28.
↑ "दस्तावेज़ीकरण - प्रकार अनुमान". www.typescriptlang.org (in English). Retrieved 2020-11-21.
↑ "Projects/Vala/Tutorial - GNOME Wiki!". wiki.gnome.org. Retrieved 2021-06-28.
↑ "डार्ट प्रकार प्रणाली". dart.dev. Retrieved 2020-11-21.
↑ Bryan O'Sullivan; Don Stewart; John Goerzen (2008). "Chapter 25. Profiling and optimization". वास्तविक विश्व हास्केल. O'Reilly.
↑ Talpin, Jean-Pierre, and Pierre Jouvelot. "Polymorphic type, region and effect inference." Journal of functional programming 2.3 (1992): 245-271.
↑ Hassan, Mostafa; Urban, Caterina; Eilers, Marco; Müller, Peter (2018). "MaxSMT-Based Type Inference for Python 3". कंप्यूटर सहायता प्राप्त सत्यापन. Lecture Notes in Computer Science. Vol. 10982. pp. 12–19. doi:10.1007/978-3-319-96142-2_2. ISBN 978-3-319-96141-5.
↑ ^15.0 ^15.1 Damas, Luis; Milner, Robin (1982), "Principal type-schemes for functional programs", POPL '82: Proceedings of the 9th ACM SIGPLAN-SIGACT symposium on principles of programming languages (PDF), ACM, pp. 207–212
↑ Milner, Robin (1978), "A Theory of Type Polymorphism in Programming", Journal of Computer and System Sciences, 17 (3): 348–375, doi:10.1016/0022-0000(78)90014-4
↑ Center, Artificiał Intelligence. Parsing and type inference for natural and computer languages. Diss. Stanford University, 1989.
↑ Emele, Martin C., and Rémi Zajac. "Typed unification grammars." Proceedings of the 13th conference on Computational linguistics-Volume 3. Association for Computational Linguistics, 1990.
↑ Pareschi, Remo. "Type-driven natural language analysis." (1988).
↑ Fisher, Kathleen, et al. "Fisher, Kathleen, et al. "From dirt to shovels: fully automatic tool generation from ad hoc data." ACM SIGPLAN Notices. Vol. 43. No. 1. ACM, 2008." ACM SIGPLAN Notices. Vol. 43. No. 1. ACM, 2008.
↑ Lappin, Shalom; Shieber, Stuart M. (2007). "सार्वभौमिक व्याकरण में अंतर्दृष्टि के स्रोत के रूप में मशीन लर्निंग सिद्धांत और अभ्यास" (PDF). Journal of Linguistics. 43 (2): 393–427. doi:10.1017/s0022226707004628. S2CID 215762538.
↑ Stuart M. Shieber (1992). Constraint-based Grammar Formalisms: Parsing and Type Inference for Natural and Computer Languages. MIT Press. ISBN 978-0-262-19324-5.

बाहरी संबंध

Archived e-mail message by Roger Hindley, explains history of type inference
Polymorphic Type Inference by Michael Schwartzbach, gives an overview of Polymorphic type inference.
Basic Typechecking paper by Luca Cardelli, describes algorithm, includes implementation in Modula-2
Implementation of Hindley-Milner type inference in Scala, by Andrew Forrest (retrieved July 30, 2009)
Implementation of Hindley-Milner in Perl 5, by Nikita Borisov at the Wayback Machine (archived February 18, 2007)
What is Hindley-Milner? (and why is it cool?) Explains Hindley-Milner, examples in Scala

[1] "WG14-N3007 : Type inference for object definitions". open-std.org. 2022-06-10. Archived from the original on December 24, 2022.

[2] "प्लेसहोल्डर प्रकार विनिर्देशक (C++11 के बाद से) - cppreference.com". en.cppreference.com. Retrieved 2021-08-15.

[3] rtermp. "अनुमान प्रकार - एफ#". docs.microsoft.com (in English). Retrieved 2020-11-21.

[4] "Inference · The Julia Language". docs.julialang.org. Retrieved 2020-11-21.

[5] "कोटलिन भाषा विशिष्टता". kotlinlang.org. Retrieved 2021-06-28.

[6] "कथन - जंग संदर्भ". doc.rust-lang.org. Retrieved 2021-06-28.

[7] "अनुमान टाइप करें". Scala Documentation. Retrieved 2020-11-21.

[8] "The Basics — The Swift Programming Language (Swift 5.5)". docs.swift.org. Retrieved 2021-06-28.

[9] "दस्तावेज़ीकरण - प्रकार अनुमान". www.typescriptlang.org (in English). Retrieved 2020-11-21.

[10] "Projects/Vala/Tutorial - GNOME Wiki!". wiki.gnome.org. Retrieved 2021-06-28.

[11] "डार्ट प्रकार प्रणाली". dart.dev. Retrieved 2020-11-21.

[12] Bryan O'Sullivan; Don Stewart; John Goerzen (2008). "Chapter 25. Profiling and optimization". वास्तविक विश्व हास्केल. O'Reilly.

[13] Talpin, Jean-Pierre, and Pierre Jouvelot. "Polymorphic type, region and effect inference." Journal of functional programming 2.3 (1992): 245-271.

[14] Hassan, Mostafa; Urban, Caterina; Eilers, Marco; Müller, Peter (2018). "MaxSMT-Based Type Inference for Python 3". कंप्यूटर सहायता प्राप्त सत्यापन. Lecture Notes in Computer Science. Vol. 10982. pp. 12–19. doi:10.1007/978-3-319-96142-2_2. ISBN 978-3-319-96141-5.

[Damas-and-Milner-1982-15] 15.0 ^15.1 Damas, Luis; Milner, Robin (1982), "Principal type-schemes for functional programs", POPL '82: Proceedings of the 9th ACM SIGPLAN-SIGACT symposium on principles of programming languages (PDF), ACM, pp. 207–212

[16] Milner, Robin (1978), "A Theory of Type Polymorphism in Programming", Journal of Computer and System Sciences, 17 (3): 348–375, doi:10.1016/0022-0000(78)90014-4

[17] Center, Artificiał Intelligence. Parsing and type inference for natural and computer languages. Diss. Stanford University, 1989.

[18] Emele, Martin C., and Rémi Zajac. "Typed unification grammars." Proceedings of the 13th conference on Computational linguistics-Volume 3. Association for Computational Linguistics, 1990.

[19] Pareschi, Remo. "Type-driven natural language analysis." (1988).

[20] Fisher, Kathleen, et al. "Fisher, Kathleen, et al. "From dirt to shovels: fully automatic tool generation from ad hoc data." ACM SIGPLAN Notices. Vol. 43. No. 1. ACM, 2008." ACM SIGPLAN Notices. Vol. 43. No. 1. ACM, 2008.

[21] Lappin, Shalom; Shieber, Stuart M. (2007). "सार्वभौमिक व्याकरण में अंतर्दृष्टि के स्रोत के रूप में मशीन लर्निंग सिद्धांत और अभ्यास" (PDF). Journal of Linguistics. 43 (2): 393–427. doi:10.1017/s0022226707004628. S2CID 215762538.

[Shieber1992-22] Stuart M. Shieber (1992). Constraint-based Grammar Formalisms: Parsing and Type Inference for Natural and Computer Languages. MIT Press. ISBN 978-0-262-19324-5.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

@@ Line 50: / Line 50: @@
      return result;
 }</syntaxhighlight>
-यह डार्ट भाषा (प्रोग्रामिंग भाषा) में कोड लिखने के तरीके के समान है, सिवाय इसके कि यह नीचे वर्णित कुछ अतिरिक्त बाधाओं के अधीन है। संकलन समय पर सभी चरों के प्रकारों का अनुमान लगाना संभव होगा। उपरोक्त उदाहरण में, संकलक इसका अनुमान लगाएगा <code>result</code> और <code>x</code> स्थिरांक के बाद से पूर्णांक प्रकार है <code>1</code> पूर्णांक प्रकार है, और इसलिए वह <code>add_one</code> एक फ़ंक्शन है <code>int -> int</code>. परिवर्तनशील <code>result2</code> इसका उपयोग कानूनी तरीके से नहीं किया गया है, इसलिए इसका कोई प्रकार नहीं होगा।
+यह उसी तरह है जैसे डार्ट भाषा में कोड लिखा जाता है, सिवाय इसके कि यह नीचे वर्णित कुछ अतिरिक्त बाधाओं के अधीन है। संकलन समय पर सभी वेरिएबल्स के प्रकारों का अनुमान लगाना संभव होगा। उपरोक्त उदाहरण में, कंपाइलर उस <code>result</code> का अनुमान लगाएगा और <code>x</code> में पूर्णांक प्रकार है क्योंकि स्थिरांक 1 प्रकार पूर्णांक है, और इसलिए <code>add_one</code> एक फ़ंक्शन <code>int -> int</code> है। वेरिएबल<code>result2</code>का उपयोग कानूनी तरीके से नहीं किया जाता है, इसलिए इसका कोई प्रकार नहीं होगा।
-जिस काल्पनिक भाषा में अंतिम उदाहरण लिखा गया है, उसमें संकलक यह मान लेगा कि, इसके विपरीत जानकारी के अभाव में, <code>+</code> दो पूर्णांक लेता है और एक पूर्णांक लौटाता है। (उदाहरण के लिए, OCaml में यह इसी प्रकार काम करता है।) इससे, प्रकार का अनुमान लगाने वाला अनुमान लगा सकता है कि किस प्रकार का <code>x + 1</code> एक पूर्णांक है, जिसका अर्थ है <code>result</code> एक पूर्णांक है और इस प्रकार का वापसी मूल्य है <code>add_one</code> एक पूर्णांक है. इसी तरह, जब से <code>+</code> इसके लिए आवश्यक है कि इसके दोनों तर्क एक ही प्रकार के हों<!--integers-->, <code>x</code> एक पूर्णांक होना चाहिए, और इस प्रकार, <code>add_one</code> एक पूर्णांक को तर्क के रूप में स्वीकार करता है।
+उस काल्पनिक भाषा में जिसमें अंतिम उदाहरण लिखा गया है, संकलक यह मान लेगा कि, इसके विपरीत जानकारी के अभाव में, <code>+</code> दो पूर्णांक लेता है और एक पूर्णांक लौटाता है। (उदाहरण के लिए, ओकैमल में यह इसी तरह काम करता है।) इससे, प्रकार का अनुमान लगाने वाला यह अनुमान लगा सकता है कि <code>x + 1</code> का प्रकार एक पूर्णांक है, जिसका अर्थ है कि <code>result</code>एक पूर्णांक है और इस प्रकार <code>add_one</code> का वापसी मान एक पूर्णांक है। इसी तरह, चूंकि <code>+</code> के लिए आवश्यक है कि उसके दोनों तर्क एक ही प्रकार के हों, <code>x</code> एक पूर्णांक होना चाहिए, और इस प्रकार, <code>add_one</code> एक पूर्णांक को एक तर्क के रूप में स्वीकार करता है।
 हालाँकि, अगली पंक्ति में दशमलव जोड़कर परिणाम2 की गणना की जाती है <code>1.0</code> [[फ़्लोटिंग-पॉइंट अंकगणित]] के साथ, जिसके उपयोग में विरोध उत्पन्न होता है <code>x</code> पूर्णांक और फ़्लोटिंग-पॉइंट अभिव्यक्ति दोनों के लिए। ऐसी स्थिति के लिए सही प्रकार-अनुमान एल्गोरिदम को #हिंडले-मिलनर प्रकार अनुमान एल्गोरिदम के रूप में जाना जाता है और 1982 से इसे सही माना जाता है। यह पिछले अनुमानों पर दोबारा गौर करता है और शुरू से ही सबसे सामान्य प्रकार का उपयोग करता है: इस मामले में फ्लोटिंग- बिंदु। हालाँकि इसके हानिकारक प्रभाव हो सकते हैं, उदाहरण के लिए शुरू से ही फ़्लोटिंग-पॉइंट का उपयोग करने से सटीक समस्याएं आ सकती हैं जो पूर्णांक प्रकार के साथ नहीं होतीं।
@@ Line 58: / Line 58: @@
 हालाँकि, अक्सर, विकृत प्रकार-अनुमान एल्गोरिदम का उपयोग किया जाता है जो पीछे नहीं जा सकता है और इसके बजाय ऐसी स्थिति में एक त्रुटि संदेश उत्पन्न करता है। यह व्यवहार बेहतर हो सकता है क्योंकि प्रकार का अनुमान हमेशा एल्गोरिदमिक रूप से तटस्थ नहीं हो सकता है, जैसा कि पिछले फ़्लोटिंग-पॉइंट परिशुद्धता मुद्दे द्वारा दर्शाया गया है।
-मध्यवर्ती सामान्यता का एक एल्गोरिदम स्पष्ट रूप से परिणाम 2 को एक फ़्लोटिंग-पॉइंट वैरिएबल के रूप में घोषित करता है, और इसके अतिरिक्त रूपांतरित होता है <code>x</code> एक तैरते बिंदु पर. यह सही हो सकता है यदि कॉलिंग संदर्भ कभी भी फ़्लोटिंग पॉइंट तर्क प्रदान नहीं करते हैं। ऐसी स्थिति प्रकार अनुमान के बीच अंतर दिखाती है, जिसमें [[प्रकार रूपांतरण]] शामिल नहीं होता है, और [[अंतर्निहित प्रकार रूपांतरण]], जो डेटा को एक अलग डेटा प्रकार पर मजबूर करता है, अक्सर बिना किसी प्रतिबंध के।
+मध्यवर्ती व्यापकता का एक एल्गोरिदम स्पष्ट रूप से परिणाम 2 को एक फ़्लोटिंग-पॉइंट वैरिएबल के रूप में घोषित करता है, और इसके अलावा<code>x</code> को फ़्लोटिंग पॉइंट में परिवर्तित करता है। यह सही हो सकता है यदि कॉलिंग संदर्भ कभी भी फ़्लोटिंग पॉइंट तर्क प्रदान न करें। ऐसी स्थिति प्रकार अनुमान के बीच अंतर को दर्शाती है, जिसमें प्रकार रूपांतरण शामिल नहीं है, और अंतर्निहित प्रकार रूपांतरण, जो डेटा को एक अलग अक्सर बिना किसी प्रतिबंध के डेटा प्रकार पर विवश करता है, ।
 अंत में, जटिल प्रकार-अनुमान एल्गोरिदम का एक महत्वपूर्ण नकारात्मक पक्ष यह है कि परिणामी प्रकार अनुमान संकल्प मनुष्यों के लिए स्पष्ट नहीं होगा (विशेष रूप से बैकट्रैकिंग के कारण), जो हानिकारक हो सकता है क्योंकि कोड मुख्य रूप से मनुष्यों के लिए समझने योग्य है।
-जस्ट-इन-टाइम संकलन का हालिया उद्भव हाइब्रिड दृष्टिकोण की अनुमति देता है जहां विभिन्न कॉलिंग संदर्भ द्वारा आपूर्ति किए गए तर्कों के प्रकार को संकलन समय पर जाना जाता है, और एक ही फ़ंक्शन के बड़ी संख्या में संकलित संस्करण उत्पन्न कर सकते हैं। फिर प्रत्येक संकलित संस्करण को विभिन्न प्रकार के सेट के लिए अनुकूलित किया जा सकता है। उदाहरण के लिए, JIT संकलन add_one के कम से कम दो संकलित संस्करण होने की अनुमति देता है:
+जस्ट-इन-टाइम संकलन का हालिया प्रवर्तन हाइब्रिड दृष्टिकोणों की अनुमति देता है जहां विभिन्न कॉलिंग संदर्भ द्वारा प्रदान किए गए तर्कों के प्रकार को संकलन समय पर जाना जाता है, और एक ही फ़ंक्शन के बड़ी संख्या में संकलित संस्करण उत्पन्न कर सकते हैं। प्रत्येक संकलित संस्करण को विभिन्न प्रकारों के सेट के लिए अनुकूलित किया जा सकता है। उदाहरण के लिए, जस्ट-इन-टाइमसंकलन add_one के कम से कम दो संकलित संस्करण की अनुमति देता है:
 :एक संस्करण जो पूर्णांक इनपुट स्वीकार करता है और अंतर्निहित प्रकार रूपांतरण का उपयोग करता है।
@@ Line 74: / Line 74: @@
 [[उच्च-क्रम प्रोग्रामिंग]] और [[बहुरूपता (कंप्यूटर विज्ञान)]] के जटिल रूपों में, संकलक के लिए उतना अनुमान लगाना हमेशा संभव नहीं होता है, और कभी-कभी अस्पष्टता के लिए टाइप एनोटेशन आवश्यक होते हैं। उदाहरण के लिए, [[बहुरूपी पुनरावर्तन]] के साथ प्रकार का अनुमान अनिर्णीत माना जाता है। इसके अलावा, स्पष्ट प्रकार के एनोटेशन का उपयोग कंपाइलर को अनुमान से अधिक विशिष्ट (तेज़/छोटे) प्रकार का उपयोग करने के लिए मजबूर करके कोड को अनुकूलित करने के लिए किया जा सकता है।<ref>{{cite book |author1=Bryan O'Sullivan |author2=Don Stewart |author3=John Goerzen |year=2008 |title=वास्तविक विश्व हास्केल|chapter=Chapter 25. Profiling and optimization |publisher=O'Reilly |chapter-url=http://book.realworldhaskell.org/read/profiling-and-optimization.html}}</ref>
 प्रकार अनुमान की कुछ विधियाँ [[बाधा संतुष्टि समस्या]] पर आधारित हैं<ref>Talpin, Jean-Pierre, and Pierre Jouvelot. "[https://pdfs.semanticscholar.org/57b0/e240c36a26c05b2eb7b6ccf3fabbfd383b25.pdf Polymorphic type, region and effect inference]." Journal of functional programming 2.3 (1992): 245-271.</ref> या [[संतुष्टि मॉड्यूलो सिद्धांत]]।<ref>{{Cite book|chapter-url=https://link.springer.com/chapter/10.1007/978-3-319-96142-2_2|doi=10.1007/978-3-319-96142-2_2|chapter=MaxSMT-Based Type Inference for Python 3|title=कंप्यूटर सहायता प्राप्त सत्यापन|series=Lecture Notes in Computer Science|year=2018|last1=Hassan|first1=Mostafa|last2=Urban|first2=Caterina|last3=Eilers|first3=Marco|last4=Müller|first4=Peter|volume=10982|pages=12–19|isbn=978-3-319-96141-5}}</ref>
 ==उदाहरण==
 उदाहरण के तौर पर, हास्केल (प्रोग्रामिंग भाषा) फ़ंक्शन <code>map</code> सूची के प्रत्येक तत्व पर एक फ़ंक्शन लागू करता है, और इसे इस प्रकार परिभाषित किया जा सकता है:
@@ Line 124: / Line 122: @@
 ==प्राकृतिक भाषाओं के लिए प्रकार का अनुमान==
 प्राकृतिक भाषाओं के साथ-साथ प्रोग्रामिंग भाषाओं का विश्लेषण करने के लिए प्रकार अनुमान एल्गोरिदम का उपयोग किया गया है।<ref>Center, Artificiał Intelligence. [https://www.sri.com/sites/default/files/uploads/publications/pdf/511.pdf Parsing and type inference for natural and computer languages]. Diss. Stanford University, 1989.</ref><ref>Emele, Martin C., and Rémi Zajac. "[https://aclanthology.info/pdf/C/C90/C90-3052.pdf Typed unification grammars]." Proceedings of the 13th conference on Computational linguistics-Volume 3. Association for Computational Linguistics, 1990.</ref><ref>Pareschi, Remo. "[https://www.era.lib.ed.ac.uk/bitstream/handle/1842/19215/PareschiR_1989redux.pdf?sequence=1 Type-driven natural language analysis]." (1988).</ref> कुछ [[व्याकरण प्रेरण]] में प्रकार अनुमान एल्गोरिदम का भी उपयोग किया जाता है<ref>Fisher, Kathleen, et al. "Fisher, Kathleen, et al. "[https://www.cs.princeton.edu/~dpw/papers/learningpopl08-final.pdf From dirt to shovels: fully automatic tool generation from ad hoc data]." ACM SIGPLAN Notices. Vol. 43. No. 1. ACM, 2008." ACM SIGPLAN Notices. Vol. 43. No. 1. ACM, 2008.</ref><ref>{{cite journal | last1 = Lappin | first1 = Shalom | last2 = Shieber | first2 = Stuart M. | year = 2007 | title = सार्वभौमिक व्याकरण में अंतर्दृष्टि के स्रोत के रूप में मशीन लर्निंग सिद्धांत और अभ्यास| url = https://dash.harvard.edu/bitstream/handle/1/2031673/MachineLearning.pdf?sequence=3 | journal = Journal of Linguistics | volume = 43 | issue = 2| pages = 393–427 | doi=10.1017/s0022226707004628| s2cid = 215762538 }}</ref> और प्राकृतिक भाषाओं के लिए [[बाधा-आधारित व्याकरण]] प्रणालियाँ।<ref name="Shieber1992">{{cite book|author=Stuart M. Shieber|title=Constraint-based Grammar Formalisms: Parsing and Type Inference for Natural and Computer Languages|url=https://books.google.com/books?id=QcYl_ylrHmcC&q=%22type+inference%22|year=1992|publisher=MIT Press|isbn=978-0-262-19324-5}}</ref>
 ==संदर्भ==
 {{Reflist}}

Anonymous

Search

टाइप इनफरेंस: Difference between revisions

Namespaces

More

Page actions

Revision as of 11:53, 17 July 2023

Contents

गैरतकनीकी स्पष्टीकरण

प्रकार-जाँच बनाम प्रकार-अनुमान

प्रोग्रामिंग भाषाओं में प्रकार

तकनीकी विवरण

उदाहरण

हिंडले-मिलनर प्रकार अनुमान एल्गोरिथ्म

सबसे सामान्य प्रकार का उपयोग करने के दुष्प्रभाव

प्राकृतिक भाषाओं के लिए प्रकार का अनुमान

संदर्भ

बाहरी संबंध

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

टाइप इनफरेंस: Difference between revisions

Revision as of 11:53, 17 July 2023

गैरतकनीकी स्पष्टीकरण

प्रकार-जाँच बनाम प्रकार-अनुमान

प्रोग्रामिंग भाषाओं में प्रकार

तकनीकी विवरण

उदाहरण

हिंडले-मिलनर प्रकार अनुमान एल्गोरिथ्म

सबसे सामान्य प्रकार का उपयोग करने के दुष्प्रभाव

प्राकृतिक भाषाओं के लिए प्रकार का अनुमान

संदर्भ

बाहरी संबंध

Navigation

Wiki tools

Page tools

Other projects

Categories