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

Latest revision as of 14:25, 28 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]। इसका firstतर्क f पहले तर्क पर लागू होता है, जिसमें सूची तर्क के प्रकार के अनुरूप d प्रकार होना चाहिए, इसलिए कुछ प्रकार के e के लिएf :: d → e (:: का अर्थ "प्रकार का है")। map f का रिटर्न मान, अंततः, जो कुछ भी fउत्पन्न करता है उसकी एक सूची है, इसलिए [e]।

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

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

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

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

प्रकार का अनुमान लगाने के लिए सबसे पहले उपयोग किए जाने वाले एल्गोरिदम को अब अनौपचारिक रूप से हिंडले-मिलनर एल्गोरिदम कहा जाता है, हालांकि एल्गोरिदम का श्रेय उचित रूप से दमास और मिलनर को दिया जाना चाहिए।^[15]

इस एल्गोरिथ्म का मूल सरल रूप से टाइप किए गए लैम्ब्डा कैलकुलस के लिए प्रकार अनुमान एल्गोरिदम है जिसे 1958 में हास्केल करी और रॉबर्ट फेयस द्वारा तैयार किया गया था। 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 1: / Line 1: @@
 {{Short description|Automatic detection of the type of an expression in a formal language}}
 {{Type systems}}
-प्रकार अनुमान से तात्पर्य [[औपचारिक भाषा]] में किसी अभिव्यक्ति के [[प्रकार (प्रकार सिद्धांत)]] की स्वचालित पहचान से है। इनमें [[प्रोग्रामिंग भाषा]]एं और गणितीय प्रकार की प्रणालियां शामिल हैं, लेकिन [[कंप्यूटर विज्ञान]] और भाषाविज्ञान की कुछ शाखाओं में प्राकृतिक भाषाएं भी शामिल हैं।
+[[टाइप इनफरेंस]] का तात्पर्य औपचारिक भाषा में अभिव्यक्ति के [[प्रकार (प्रकार सिद्धांत)|प्रकार]] का स्वचालित पता लगाना है। इनमें प्रोग्रामिंग भाषाएं और गणितीय प्रकार की प्रणालियाँ सम्मिलित हैं, लेकिन [[कंप्यूटर विज्ञान]] और भाषा विज्ञान की कुछ शाखाओं में प्राकृतिक भाषाएँ भी सम्मिलित हैं।
 ==गैरतकनीकी स्पष्टीकरण==
-सबसे सामान्य दृश्य में प्रकारों को उस प्रकार की किसी वस्तु के लिए संभावित गतिविधियों का सुझाव देने और प्रतिबंधित करने के लिए निर्दिष्ट उपयोग से जोड़ा जा सकता है। भाषा में कई संज्ञाएँ ऐसे प्रयोगों को निर्दिष्ट करती हैं। उदाहरण के लिए, [[पट्टा]] शब्द कपड़े की रेखा शब्द की तुलना में एक अलग उपयोग को इंगित करता है। किसी चीज़ को [[टेबल (फर्नीचर)]] कहना उसे [[जलाऊ लकड़ी]] कहने की तुलना में एक अन्य पदनाम को इंगित करता है, हालांकि यह भौतिक रूप से एक ही चीज़ हो सकती है। जबकि उनके भौतिक गुण चीजों को कुछ उद्देश्यों के लिए उपयोग करने योग्य बनाते हैं, वे विशेष पदनामों के विषय भी हैं। यह विशेष रूप से अमूर्त क्षेत्रों, अर्थात् गणित और कंप्यूटर विज्ञान, में मामला है, जहां सामग्री अंततः केवल बिट्स या सूत्र हैं।
+सबसे सामान्य दृष्टिकोण में प्रकारों को उस प्रकार की किसी ऑब्जेक्ट के लिए संभावित गतिविधियों का सुझाव देने और प्रतिबंधित करने के लिए निर्दिष्ट उपयोग से जोड़ा जा सकता है। भाषा में कई संज्ञाएँ ऐसे उपयोग निर्दिष्ट करती हैं। उदाहरण के लिए, लीश शब्द लाइन शब्द की तुलना में एक अलग उपयोग को इंगित करता है। किसी चीज़ को मेज़ कहना उसे फायरवुड कहने की तुलना में किसी अन्य पदनाम को इंगित करता है, हालाँकि भौतिक रूप से यह वही चीज़ हो सकती है। जबकि उनके भौतिक गुण चीज़ों को कुछ उद्देश्यों के लिए उपयोग योग्य बनाते हैं, वे विशेष पदनामों के अधीन भी होते हैं। यह विशेष रूप से अमूर्त क्षेत्रों में स्तिथि है, अर्थात् गणित और कंप्यूटर विज्ञान, जहां सामग्री अंततः केवल बिट्स या सूत्र है।
-अवांछित, लेकिन भौतिक रूप से संभव उपयोगों को बाहर करने के लिए, प्रकारों की अवधारणा को कई रूपों में परिभाषित और लागू किया जाता है। गणित में, रसेल के विरोधाभास ने टाइप थ्योरी के शुरुआती संस्करणों को जन्म दिया। प्रोग्रामिंग भाषाओं में, विशिष्ट उदाहरण प्रकार की त्रुटियाँ हैं, जैसे कंप्यूटर को उन मानों का योग करने का आदेश देना जो संख्याएँ नहीं हैं। भौतिक रूप से संभव होते हुए भी, परिणाम अब सार्थक नहीं होगा और शायद समग्र प्रक्रिया के लिए विनाशकारी होगा।
+अवांछित, लेकिन भौतिक रूप से संभावित उपयोगों को बाहर करने के लिए, प्रकारों की अवधारणा को कई रूपों में परिभाषित और लागू किया गया है। गणित में, रसेल के विरोधाभास ने प्रकार सिद्धांत के प्रारंभिक संस्करणों को जन्म दिया। प्रोग्रामिंग भाषाओं में, विशिष्ट उदाहरण "प्रकार की त्रुटियां" हैं, उदाहरण के लिए कंप्यूटर को उन मानों को जोड़ने का आदेश देना जो संख्याएँ नहीं हैं। हालांकि भौतिक रूप से संभव है, परिणाम अब सार्थक नहीं होगा और शायद समग्र प्रक्रिया के लिए विनाशकारी होगा।
-टाइपिंग में, एक अभिव्यक्ति एक प्रकार का विरोध करती है। उदाहरण के लिए, <math>4</math>, <math>2+2</math>, और <math>2\cdot 2</math> सभी प्रकार के साथ अलग-अलग शब्द हैं <math>\mathrm{nat}</math> प्राकृतिक संख्याओं के लिए. परंपरागत रूप से, अभिव्यक्ति के बाद कोलन और उसका प्रकार आता है, जैसे <math>2 : \mathrm{nat}</math>. इसका मतलब यह है कि मूल्य <math>2</math> प्रकार का है <math>\mathrm{nat}</math>. इस फॉर्म का उपयोग नए नामों की घोषणा करने के लिए भी किया जाता है, जैसे <math>n : \mathrm{nat}</math>, बहुत कुछ जासूस डेकर शब्दों द्वारा एक दृश्य में एक नए चरित्र को पेश करने जैसा है ।
+टाइपिंग में, एक अभिव्यक्ति एक प्रकार का विरोध करती है। उदाहरण के लिए, <math>4</math>, <math>2+2</math>, और <math>2\cdot 2</math> सभी प्रकार के साथ अलग-अलग शब्द हैं <math>\mathrm{nat}</math> प्राकृतिक संख्याओं के लिए. परंपरागत रूप से, अभिव्यक्ति के बाद कोलन और उसका प्रकार आता है, जैसे <math>2 : \mathrm{nat}</math>. इसका मतलब यह है कि मूल्य <math>2</math> प्रकार का है <math>\mathrm{nat}</math>. इस फॉर्म का उपयोग नए नामों की घोषणा करने के लिए भी किया जाता है, जैसे <math>n : \mathrm{nat}</math>, बहुत कुछ जासूस डेकर शब्दों द्वारा एक दृश्य में नए चरित्र को प्रस्तुत करने जैसा है ।
-एक कहानी के विपरीत, जहां पदनाम धीरे-धीरे सामने आते हैं, औपचारिक भाषाओं में वस्तुओं को अक्सर शुरुआत से ही उनके प्रकार के साथ परिभाषित करना पड़ता है। इसके अतिरिक्त, यदि अभिव्यक्तियाँ अस्पष्ट हैं, तो इच्छित उपयोग को स्पष्ट करने के लिए प्रकारों की आवश्यकता हो सकती है। उदाहरण के लिए, अभिव्यक्ति <math>2</math> एक प्रकार हो सकता है <math>\mathrm{nat}</math> लेकिन इसे परिमेय या वास्तविक संख्या के रूप में या सादे पाठ के रूप में भी पढ़ा जा सकता है।
+कहानी के विपरीत, जहाँ पदनाम धीरे-धीरे सामने आते हैं, औपचारिक भाषाओं में ऑब्जेक्ट को प्रायः प्रारम्भ से ही उनके प्रकार से परिभाषित करना पड़ता है। इसके अतिरिक्त, यदि अभिव्यक्तियाँ अस्पष्ट हैं, तो इच्छित उपयोग को स्पष्ट करने के लिए प्रकारों की आवश्यकता हो सकती है। उदाहरण के लिए, अभिव्यक्ति 2 का प्रकार n हो सकता है, लेकिन इसे परिमेय या वास्तविक संख्या के रूप में या यहां तक कि सरल पाठ के रूप में भी पढ़ा जा सकता है।
-परिणामस्वरूप, प्रोग्राम या प्रमाण प्रकारों से इतने अधिक बोझिल हो सकते हैं कि उन्हें संदर्भ से निकालना वांछनीय है। यह अलिखित अभिव्यक्ति (अपरिभाषित नामों सहित) के उपयोगों को एकत्रित करके संभव हो सकता है। उदाहरण के लिए, यदि किसी अभिव्यक्ति में अभी तक अपरिभाषित नाम n का उपयोग किया जाता है <math>n + 2</math>, कोई यह निष्कर्ष निकाल सकता है कि n कम से कम एक संख्या है। किसी अभिव्यक्ति और उसके संदर्भ से प्रकार निकालने की प्रक्रिया प्रकार अनुमान है।
+परिणामस्वरूप, प्रोग्राम या प्रमाण प्रकारों से इतने अधिक बोझिल हो सकते हैं कि उन्हें संदर्भ से निकालना वांछनीय है। यह अलिखित अभिव्यक्ति (अपरिभाषित नामों सहित) के उपयोगों को एकत्रित करके संभव हो सकता है। उदाहरण के लिए, यदि किसी अभिव्यक्ति में अभी तक अपरिभाषित नाम n का उपयोग किया जाता है <math>n + 2</math>, कोई यह निष्कर्ष निकाल सकता है कि n न्यूनतम संख्या है। किसी अभिव्यक्ति और उसके संदर्भ से प्रकार निकालने की प्रक्रिया प्रकार अनुमान है।
-सामान्य तौर पर न केवल वस्तुएं, बल्कि गतिविधियां भी प्रकार की होती हैं और इन्हें केवल उनके उपयोग से ही प्रस्तुत किया जा सकता है। स्टार ट्रेक कहानी के लिए, ऐसी अज्ञात गतिविधि उत्साहजनक हो सकती है, जिसे कहानी के प्रवाह के लिए केवल क्रियान्वित किया जाता है और कभी औपचारिक रूप से पेश नहीं किया जाता है। फिर भी जो होता है उसके आधार पर कोई इसके प्रकार (परिवहन) का अनुमान लगा सकता है। इसके अतिरिक्त, वस्तुओं और गतिविधियों दोनों का निर्माण उनके भागों से किया जा सकता है। ऐसी सेटिंग में, प्रकार का अनुमान न केवल अधिक जटिल हो सकता है, बल्कि अधिक सहायक भी हो सकता है, क्योंकि यह एक रचित दृश्य में हर चीज का पूरा विवरण एकत्र करने की अनुमति देता है, जबकि अभी भी विरोधाभासी या अनपेक्षित उपयोगों का पता लगाने में सक्षम है।
+सामान्य तौर पर न केवल ऑब्जेक्ट, बल्कि गतिविधियां भी प्रकार की होती हैं और इन्हें केवल उनके उपयोग से ही प्रस्तुत किया जा सकता है। स्टार ट्रेक कहानी के लिए, ऐसी अज्ञात गतिविधि उत्साहजनक हो सकती है, जिसे कहानी के प्रवाह के लिए केवल क्रियान्वित किया जाता है और कभी औपचारिक रूप से प्रस्तुत नहीं किया जाता है। फिर भी जो होता है उसके आधार पर कोई इसके प्रकार (परिवहन) का अनुमान लगा सकता है। इसके अतिरिक्त, ऑब्जेक्ट और गतिविधियों दोनों का निर्माण उनके भागों से किया जा सकता है। ऐसी सेटिंग में, प्रकार का अनुमान न केवल अधिक जटिल हो सकता है, बल्कि अधिक सहायक भी हो सकता है, क्योंकि यह एक रचित दृश्य में हर चीज का पूरा विवरण एकत्र करने की अनुमति देता है, जबकि अभी भी विरोधाभासी या अनपेक्षित उपयोगों का पता लगाने में सक्षम है।
 ==प्रकार-जाँच बनाम प्रकार-अनुमान==
-टाइपिंग में, एक अभिव्यक्ति ई, टाइप टी के विपरीत है, जिसे औपचारिक रूप से ई: टी के रूप में लिखा जाता है। आमतौर पर टाइपिंग केवल कुछ संदर्भ में ही समझ में आती है, जिसे यहां छोड़ दिया गया है।
+टाइपिंग में, एक अभिव्यक्ति E, टाइप T के विपरीत होती है, जिसे औपचारिक रूप से E : T के रूप में लिखा जाता है। सामान्यतः टाइपिंग केवल कुछ संदर्भों में ही समझ में आती है, जिसे यहां छोड़ दिया गया है।
-इस सेटिंग में, निम्नलिखित प्रश्न विशेष रुचि के हैं:
+इस सेटिंग में, निम्नलिखित प्रश्न विशेष रूप से रुचिकर हैं:
-# ई : टी? इस मामले में, अभिव्यक्ति E और प्रकार T दोनों दिए गए हैं। अब, क्या E वास्तव में एक T है? इस परिदृश्य को [[ प्रकार-चेकिंग ]] के रूप में जाना जाता है।
+# E : T? इस स्तिथि में, अभिव्यक्ति E और प्रकार T दोनों दिए गए हैं। अब, क्या E वास्तव में एक T है? इस परिदृश्य को प्रकार-जाँच के रूप में जाना जाता है।
-# इ : _? यहाँ तो केवल अभिव्यक्ति ही ज्ञात होती है। यदि ई के लिए एक प्रकार प्राप्त करने का कोई तरीका है, तो हमने प्रकार का अनुमान पूरा कर लिया है।
+# E : _? यहाँ केवल अभिव्यक्ति ही ज्ञात है। यदि ई के लिए प्रकार प्राप्त करने का कोई तरीका है, तो हमने प्रकार अनुमान पूरा कर लिया है।
-# _ : टी? दूसरी तरफ से। केवल एक प्रकार को देखते हुए, क्या इसके लिए कोई अभिव्यक्ति है या प्रकार का कोई मान नहीं है? क्या टी का कोई उदाहरण है?
+# _ : T?  विपरीत स्थिति। केवल एक प्रकार दिया गया है, क्या इसके लिए कोई अभिव्यक्ति है या प्रकार का कोई मूल्य नहीं है? क्या कोई T का उदाहरण है?
-सरलता से टाइप किए गए लैम्ब्डा कैलकुलस के लिए, सभी तीन प्रश्न एक सिद्धांत की निर्णायकता (तर्क)#निर्णायकता हैं। जब अधिक अभिव्यंजक प्रकारों की अनुमति दी जाती है तो स्थिति उतनी आरामदायक नहीं होती है।
+सरलता से टाइप किए गए लैम्ब्डा कैलकुलस के लिए, सभी तीन प्रश्न निर्णायक हैं। जब अधिक अभिव्यंजक प्रकारों की अनुमति दी जाती है तो स्थिति उतनी सहज नहीं होती।
 ==प्रोग्रामिंग भाषाओं में प्रकार==
-{{More citations needed section|date=November 2020}}
+प्रकार कुछ दृढ़तापूर्वक सांख्यिकीय रूप से टाइप की गई भाषाओं में उपस्थित एक विशेषता है। यह प्रायः सामान्य रूप से [[कार्यात्मक प्रोग्रामिंग भाषा|कार्यात्मक प्रोग्रामिंग]] भाषाओं की विशेषता होती है। कुछ भाषाएँ जिनमें प्रकार का अनुमान सम्मिलित है उनमें C23, <ref>{{cite web |title=WG14-N3007 : Type inference for object definitions |url=https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm |website=open-std.org |archive-url=https://web.archive.org/web/20221224105654/https://open-std.org/JTC1/SC22/WG14/www/docs/n3007.htm |archive-date=December 24, 2022 |date=2022-06-10 |url-status=live}}</ref> C++11,<ref>{{Cite web|title=प्लेसहोल्डर प्रकार विनिर्देशक (C++11 के बाद से) - cppreference.com|url=https://en.cppreference.com/w/cpp/language/auto|access-date=2021-08-15|website=en.cppreference.com}}</ref> C# (संस्करण 3.0 से प्रारम्भ), चैपल, क्लीन, [[क्रिस्टल (प्रोग्रामिंग भाषा)|क्रिस्टल]], [[डी (प्रोग्रामिंग भाषा)|डी]], एफ#, <ref>{{Cite web|last=cartermp|title=अनुमान प्रकार - एफ#|url=https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/type-inference|access-date=2020-11-21|website=docs.microsoft.com|language=en-us}}</ref> [[फ्रीबेसिक]], गो, [[हास्केल (प्रोग्रामिंग भाषा)|हास्केल]], जावा (प्रारम्भ) सम्मिलित हैं। संस्करण 10 के साथ), जूलिया, <ref>{{Cite web|title=Inference · The Julia Language|url=https://docs.julialang.org/en/v1/devdocs/inference/|access-date=2020-11-21|website=docs.julialang.org}}</ref> [[कोटलिन (प्रोग्रामिंग भाषा)|कोटलिन]],<ref>{{Cite web|title=कोटलिन भाषा विशिष्टता|url=https://kotlinlang.org/spec/type-inference.html|access-date=2021-06-28|website=kotlinlang.org}}</ref> [[एमएल (प्रोग्रामिंग भाषा)|एमएल]], [[निम (प्रोग्रामिंग भाषा)|निम]], [[ओकैमल]], [[ओपा (प्रोग्रामिंग भाषा)|ओपा]], क्यू#, आरपाइथॉन, रस्ट, <ref>{{Cite web|title=कथन - जंग संदर्भ|url=https://doc.rust-lang.org/reference/statements.html?highlight=inference#let-statements|access-date=2021-06-28|website=doc.rust-lang.org}}</ref> [[स्काला (प्रोग्रामिंग भाषा)|स्काला]],<ref>{{Cite web|title=अनुमान टाइप करें|url=https://docs.scala-lang.org/tour/type-inference.html|access-date=2020-11-21|website=Scala Documentation}}</ref> [[स्विफ्ट (प्रोग्रामिंग भाषा)|स्विफ्ट]],<ref>{{Cite web|title=The Basics — The Swift Programming Language (Swift 5.5)|url=https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html#ID322|access-date=2021-06-28|website=docs.swift.org}}</ref> टाइपस्क्रिप्ट,<ref>{{Cite web|title=दस्तावेज़ीकरण - प्रकार अनुमान|url=https://www.typescriptlang.org/docs/handbook/type-inference.html|access-date=2020-11-21|website=www.typescriptlang.org|language=en}}</ref> वैला, <ref>{{Cite web|title=Projects/Vala/Tutorial - GNOME Wiki!|url=https://wiki.gnome.org/Projects/Vala/Tutorial#Type_Inference|access-date=2021-06-28|website=wiki.gnome.org}}</ref> [[डार्ट (प्रोग्रामिंग भाषा)|डार्ट]], <ref>{{Cite web|title=डार्ट प्रकार प्रणाली|url=https://dart.dev/guides/language/type-system|access-date=2020-11-21|website=dart.dev}}</ref> और विज़ुअल बेसिक [12] (संस्करण 9.0 से प्रारम्भ)। उनमें से अधिकांश प्रकार के अनुमान के सरल रूप का उपयोग करते हैं; हिंडले-मिलनर प्रकार प्रणाली अधिक पूर्ण प्रकार का अनुमान प्रदान कर सकती है। प्रकारों का अनुमान लगाने की क्षमता स्वचालित रूप से कई प्रोग्रामिंग कार्यों को आसान बनाती है, जिससे प्रोग्रामर प्रकार की जांच की अनुमति देते हुए प्रकार एनोटेशन को छोड़ने के लिए स्वतंत्र हो जाता है।
-प्रकार कुछ दृढ़ता से टाइप की गई प्रोग्रामिंग भाषा टाइप सिस्टम#स्टेटिक टाइपिंग भाषाओं में मौजूद एक विशेषता है। यह अक्सर सामान्य रूप से [[कार्यात्मक प्रोग्रामिंग भाषा]]ओं की विशेषता होती है। कुछ भाषाएँ जिनमें प्रकार का अनुमान शामिल है उनमें C23 (C_standard_revision), शामिल हैं<ref>{{cite web |title=WG14-N3007 : Type inference for object definitions |url=https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm |website=open-std.org |archive-url=https://web.archive.org/web/20221224105654/https://open-std.org/JTC1/SC22/WG14/www/docs/n3007.htm |archive-date=December 24, 2022 |date=2022-06-10 |url-status=live}}</ref> [[सी++11]],<ref>{{Cite web|title=प्लेसहोल्डर प्रकार विनिर्देशक (C++11 के बाद से) - cppreference.com|url=https://en.cppreference.com/w/cpp/language/auto|access-date=2021-08-15|website=en.cppreference.com}}</ref> सी शार्प 3.0#स्थानीय चर प्रकार अनुमान|सी# (संस्करण 3.0 से शुरू), [[चैपल (प्रोग्रामिंग भाषा)]], क्लीन (प्रोग्रामिंग भाषा), [[क्रिस्टल (प्रोग्रामिंग भाषा)]], [[डी (प्रोग्रामिंग भाषा)]], एफ शार्प (प्रोग्रामिंग भाषा)|एफ#,<ref>{{Cite web|last=cartermp|title=अनुमान प्रकार - एफ#|url=https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/type-inference|access-date=2020-11-21|website=docs.microsoft.com|language=en-us}}</ref> [[फ्रीबेसिक]], गो (प्रोग्रामिंग भाषा), [[हास्केल (प्रोग्रामिंग भाषा)]], [[जावा (प्रोग्रामिंग भाषा)]] (संस्करण 10 से शुरू), [[जूलिया (प्रोग्रामिंग भाषा)]],<ref>{{Cite web|title=Inference · The Julia Language|url=https://docs.julialang.org/en/v1/devdocs/inference/|access-date=2020-11-21|website=docs.julialang.org}}</ref> [[कोटलिन (प्रोग्रामिंग भाषा)]],<ref>{{Cite web|title=कोटलिन भाषा विशिष्टता|url=https://kotlinlang.org/spec/type-inference.html|access-date=2021-06-28|website=kotlinlang.org}}</ref> [[एमएल (प्रोग्रामिंग भाषा)]], [[निम (प्रोग्रामिंग भाषा)]], [[ओकैमल]], [[ओपा (प्रोग्रामिंग भाषा)]], क्यू#, [[आरपीथॉन]], रस्ट (प्रोग्रामिंग भाषा),<ref>{{Cite web|title=कथन - जंग संदर्भ|url=https://doc.rust-lang.org/reference/statements.html?highlight=inference#let-statements|access-date=2021-06-28|website=doc.rust-lang.org}}</ref> [[स्काला (प्रोग्रामिंग भाषा)]],<ref>{{Cite web|title=अनुमान टाइप करें|url=https://docs.scala-lang.org/tour/type-inference.html|access-date=2020-11-21|website=Scala Documentation}}</ref> [[स्विफ्ट (प्रोग्रामिंग भाषा)]],<ref>{{Cite web|title=The Basics — The Swift Programming Language (Swift 5.5)|url=https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html#ID322|access-date=2021-06-28|website=docs.swift.org}}</ref> [[ टाइपप्रति ]],<ref>{{Cite web|title=दस्तावेज़ीकरण - प्रकार अनुमान|url=https://www.typescriptlang.org/docs/handbook/type-inference.html|access-date=2020-11-21|website=www.typescriptlang.org|language=en}}</ref> [[वाला (प्रोग्रामिंग भाषा)]],<ref>{{Cite web|title=Projects/Vala/Tutorial - GNOME Wiki!|url=https://wiki.gnome.org/Projects/Vala/Tutorial#Type_Inference|access-date=2021-06-28|website=wiki.gnome.org}}</ref> [[डार्ट (प्रोग्रामिंग भाषा)]],<ref>{{Cite web|title=डार्ट प्रकार प्रणाली|url=https://dart.dev/guides/language/type-system|access-date=2020-11-21|website=dart.dev}}</ref> और विज़ुअल बेसिक .NET#2008 (VB 9.0)<ref>{{Cite web|last=KathleenDollard|title=स्थानीय प्रकार का अनुमान - विज़ुअल बेसिक|url=https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/variables/local-type-inference|access-date=2021-06-28|website=docs.microsoft.com|language=en-us}}</ref> (संस्करण 9.0 से प्रारंभ)।
+कुछ प्रोग्रामिंग भाषाओं में, सभी मानों में [[संकलन समय]] पर स्पष्ट रूप से घोषित एक [[डेटा प्रकार]] होता है, जो रन टाइम (प्रोग्राम जीवनचक्र चरण) | रन-टाइम पर एक विशेष अभिव्यक्ति द्वारा ग्रहण किए जा सकने वाले मानों को सीमित करता है। तेजी से, [[सही समय पर संकलन]] रन टाइम और कंपाइल टाइम के बीच अंतर को धुंधला कर देता है। हालाँकि, ऐतिहासिक रूप से, यदि किसी मान का प्रकार केवल रन-टाइम पर ज्ञात होता है, तो ये भाषाएँ गतिशील रूप से टाइप की जाती हैं। अन्य भाषाओं में, अभिव्यक्ति का प्रकार केवल संकलन के समय ही ज्ञात होता है; ये भाषाएँ स्थिर रूप से टाइप की गई हैं। अधिकांश सांख्यिकीय रूप से टाइप की गई भाषाओं में, इनपुट और आउटपुट प्रकार के फ़ंक्शन और [[स्थानीय चर]] को सामान्यतः टाइप एनोटेशन द्वारा स्पष्ट रूप से प्रदान किया जाना चाहिए। उदाहरण के लिए, [[एएनएसआई सी]] में:<syntaxhighlight lang="c">
-उनमें से अधिकांश प्रकार के अनुमान के सरल रूप का उपयोग करते हैं; हिंडले-मिलनर प्रकार प्रणाली अधिक पूर्ण प्रकार का अनुमान प्रदान कर सकती है। प्रकारों का अनुमान लगाने की क्षमता स्वचालित रूप से कई प्रोग्रामिंग कार्यों को आसान बनाती है, जिससे प्रोग्रामर प्रकार की जाँच की अनुमति देते हुए प्रकार के हस्ताक्षर को छोड़ने के लिए स्वतंत्र हो जाता है।
-कुछ प्रोग्रामिंग भाषाओं में, सभी मानों में [[संकलन समय]] पर स्पष्ट रूप से घोषित एक [[डेटा प्रकार]] होता है, जो रन टाइम (प्रोग्राम जीवनचक्र चरण) | रन-टाइम पर एक विशेष अभिव्यक्ति द्वारा ग्रहण किए जा सकने वाले मानों को सीमित करता है। तेजी से, [[सही समय पर संकलन]] रन टाइम और कंपाइल टाइम के बीच अंतर को धुंधला कर देता है। हालाँकि, ऐतिहासिक रूप से, यदि किसी मान का प्रकार केवल रन-टाइम पर ज्ञात होता है, तो ये भाषाएँ गतिशील रूप से टाइप की जाती हैं। अन्य भाषाओं में, अभिव्यक्ति का प्रकार केवल संकलन के समय ही ज्ञात होता है; ये भाषाएँ स्थिर रूप से टाइप की गई हैं। अधिकांश सांख्यिकीय रूप से टाइप की गई भाषाओं में, इनपुट और आउटपुट प्रकार के फ़ंक्शन और [[स्थानीय चर]] को आमतौर पर टाइप एनोटेशन द्वारा स्पष्ट रूप से प्रदान किया जाना चाहिए। उदाहरण के लिए, [[एएनएसआई सी]] में:
-<syntaxhighlight lang="c">
 int add_one(int x) {
      int result; /* declare integer result */
@@ Line 54: / 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 से इसे सही माना जाता है। यह पिछले अनुमानों पर दोबारा गौर करता है और शुरू से ही सबसे सामान्य प्रकार का उपयोग करता है: इस मामले में फ्लोटिंग- बिंदु। हालाँकि इसके हानिकारक प्रभाव हो सकते हैं, उदाहरण के लिए शुरू से ही फ़्लोटिंग-पॉइंट का उपयोग करने से सटीक समस्याएं आ सकती हैं जो पूर्णांक प्रकार के साथ नहीं होतीं।
+हालाँकि, अगली पंक्ति में दशमलव जोड़कर परिणाम2 की गणना की जाती है <code>1.0</code> [[फ़्लोटिंग-पॉइंट अंकगणित]] के साथ, जिसके उपयोग में विरोध उत्पन्न होता है <code>x</code> पूर्णांक और फ़्लोटिंग-पॉइंट अभिव्यक्ति दोनों के लिए। ऐसी स्थिति के लिए सही प्रकार-अनुमान एल्गोरिदम को #हिंडले-मिलनर प्रकार अनुमान एल्गोरिदम के रूप में जाना जाता है और 1982 से इसे सही माना जाता है। यह पिछले अनुमानों पर दोबारा गौर करता है और प्रारम्भ से ही सबसे सामान्य प्रकार का उपयोग करता है: इस स्तिथि में फ्लोटिंग- बिंदु। हालाँकि इसके हानिकारक प्रभाव हो सकते हैं, उदाहरण के लिए प्रारम्भ से ही फ़्लोटिंग-पॉइंट का उपयोग करने से सटीक समस्याएं आ सकती हैं जो पूर्णांक प्रकार के साथ नहीं होतीं।
-हालाँकि, अक्सर, विकृत प्रकार-अनुमान एल्गोरिदम का उपयोग किया जाता है जो पीछे नहीं जा सकता है और इसके बजाय ऐसी स्थिति में एक त्रुटि संदेश उत्पन्न करता है। यह व्यवहार बेहतर हो सकता है क्योंकि प्रकार का अनुमान हमेशा एल्गोरिदमिक रूप से तटस्थ नहीं हो सकता है, जैसा कि पिछले फ़्लोटिंग-पॉइंट परिशुद्धता मुद्दे द्वारा दर्शाया गया है।
+हालाँकि, प्रायः, विकृत प्रकार-अनुमान एल्गोरिदम का उपयोग किया जाता है जो पीछे नहीं जा सकता है और इसके बजाय ऐसी स्थिति में एक त्रुटि संदेश उत्पन्न करता है। यह व्यवहार बेहतर हो सकता है क्योंकि प्रकार का अनुमान हमेशा एल्गोरिदमिक रूप से तटस्थ नहीं हो सकता है, जैसा कि पिछले फ़्लोटिंग-पॉइंट परिशुद्धता मुद्दे द्वारा दर्शाया गया है।
-मध्यवर्ती सामान्यता का एक एल्गोरिदम स्पष्ट रूप से परिणाम 2 को एक फ़्लोटिंग-पॉइंट वैरिएबल के रूप में घोषित करता है, और इसके अतिरिक्त रूपांतरित होता है <code>x</code> एक तैरते बिंदु पर. यह सही हो सकता है यदि कॉलिंग संदर्भ कभी भी फ़्लोटिंग पॉइंट तर्क प्रदान नहीं करते हैं। ऐसी स्थिति प्रकार अनुमान के बीच अंतर दिखाती है, जिसमें [[प्रकार रूपांतरण]] शामिल नहीं होता है, और [[अंतर्निहित प्रकार रूपांतरण]], जो डेटा को एक अलग डेटा प्रकार पर मजबूर करता है, अक्सर बिना किसी प्रतिबंध के।
+मध्यवर्ती व्यापकता का एक एल्गोरिदम स्पष्ट रूप से परिणाम 2 को एक फ़्लोटिंग-पॉइंट वैरिएबल के रूप में घोषित करता है, और इसके अलावा<code>x</code> को फ़्लोटिंग पॉइंट में परिवर्तित करता है। यह सही हो सकता है यदि कॉलिंग संदर्भ कभी भी फ़्लोटिंग पॉइंट तर्क प्रदान न करें। ऐसी स्थिति प्रकार अनुमान के बीच अंतर को दर्शाती है, जिसमें प्रकार रूपांतरण सम्मिलित नहीं है, और अंतर्निहित प्रकार रूपांतरण, जो डेटा को एक अलग प्रायः बिना किसी प्रतिबंध के डेटा प्रकार पर विवश करता है, ।
 अंत में, जटिल प्रकार-अनुमान एल्गोरिदम का एक महत्वपूर्ण नकारात्मक पक्ष यह है कि परिणामी प्रकार अनुमान संकल्प मनुष्यों के लिए स्पष्ट नहीं होगा (विशेष रूप से बैकट्रैकिंग के कारण), जो हानिकारक हो सकता है क्योंकि कोड मुख्य रूप से मनुष्यों के लिए समझने योग्य है।
-जस्ट-इन-टाइम संकलन का हालिया उद्भव हाइब्रिड दृष्टिकोण की अनुमति देता है जहां विभिन्न कॉलिंग संदर्भ द्वारा आपूर्ति किए गए तर्कों के प्रकार को संकलन समय पर जाना जाता है, और एक ही फ़ंक्शन के बड़ी संख्या में संकलित संस्करण उत्पन्न कर सकते हैं। फिर प्रत्येक संकलित संस्करण को विभिन्न प्रकार के सेट के लिए अनुकूलित किया जा सकता है। उदाहरण के लिए, JIT संकलन add_one के कम से कम दो संकलित संस्करण होने की अनुमति देता है:
+जस्ट-इन-टाइम संकलन का हालिया प्रवर्तन हाइब्रिड दृष्टिकोणों की अनुमति देता है जहां विभिन्न कॉलिंग संदर्भ द्वारा प्रदान किए गए तर्कों के प्रकार को संकलन समय पर जाना जाता है, और एक ही फ़ंक्शन के बड़ी संख्या में संकलित संस्करण उत्पन्न कर सकते हैं। प्रत्येक संकलित संस्करण को विभिन्न प्रकारों के सेट के लिए अनुकूलित किया जा सकता है। उदाहरण के लिए, जस्ट-इन-टाइमसंकलन add_one के न्यूनतम दो संकलित संस्करण की अनुमति देता है:
 :एक संस्करण जो पूर्णांक इनपुट स्वीकार करता है और अंतर्निहित प्रकार रूपांतरण का उपयोग करता है।
@@ Line 72: / Line 68: @@
 ==तकनीकी विवरण==
-प्रकार अनुमान, संकलन समय पर किसी अभिव्यक्ति के प्रकार को आंशिक या पूर्ण रूप से स्वचालित रूप से निकालने की क्षमता है। कंपाइलर अक्सर किसी चर के प्रकार या किसी फ़ंक्शन के प्रकार के हस्ताक्षर का अनुमान लगाने में सक्षम होता है, बिना स्पष्ट प्रकार के एनोटेशन दिए। कई मामलों में, किसी प्रोग्राम से टाइप एनोटेशन को पूरी तरह से हटाना संभव है यदि टाइप अनुमान प्रणाली पर्याप्त रूप से मजबूत है, या प्रोग्राम या भाषा काफी सरल है।
+प्रकार अनुमान, संकलन समय पर किसी अभिव्यक्ति के प्रकार को आंशिक रूप से या पूरी तरह से स्वचालित रूप से निकालने की क्षमता है। कंपाइलर प्रायः किसी चर के प्रकार या फ़ंक्शन के प्रकार के हस्ताक्षर का अनुमान लगाने में सक्षम होता है, बिना किसी स्पष्ट प्रकार के एनोटेशन दिए। कई स्थितियों में, किसी प्रोग्राम से टाइप एनोटेशन को पूरी तरह से हटाना संभव है यदि टाइप इंट्रेंस सिस्टम पर्याप्त सशक्त है, या प्रोग्राम या भाषा काफी सरल है।
-किसी अभिव्यक्ति के प्रकार का अनुमान लगाने के लिए आवश्यक जानकारी प्राप्त करने के लिए, संकलक या तो इस जानकारी को उसके उप-अभिव्यक्तियों के लिए दिए गए प्रकार के एनोटेशन के समग्र और बाद में कमी के रूप में एकत्र करता है, या विभिन्न परमाणु मूल्यों के प्रकार की अंतर्निहित समझ के माध्यम से (उदाहरण के लिए सत्य: बूल; 42 : पूर्णांक; 3.14159 : वास्तविक; आदि)। यह अंतर्निहित रूप से टाइप किए गए परमाणु मूल्यों के लिए अभिव्यक्तियों की अंतिम कमी की पहचान के माध्यम से है कि एक प्रकार की अनुमान लगाने वाली भाषा के लिए कंपाइलर एक प्रोग्राम को टाइप एनोटेशन के बिना पूरी तरह से संकलित करने में सक्षम है।
+किसी अभिव्यक्ति के प्रकार का अनुमान लगाने के लिए आवश्यक जानकारी प्राप्त करने के लिए, कंपाइलर या तो इस जानकारी को उसके उप-अभिव्यक्तियों के लिए दिए गए प्रकार के एनोटेशन के समग्र और बाद में कमी के रूप में इकट्ठा करता है, या विभिन्न परमाणु मूल्यों के प्रकार की अंतर्निहित समझ के माध्यम से (उदाहरण के लिए सत्य: बूल; 42: पूर्णांक; 3.14159: वास्तविक; आदि)। यह अंतर्निहित रूप से टाइप किए गए परमाणु मानों के लिए अभिव्यक्तियों की अंतिम कमी की पहचान के माध्यम से है कि एक प्रकार की अनुमान लगाने वाली भाषा के लिए कंपाइलर एक प्रोग्राम को बिना टाइप एनोटेशन के पूरी तरह से संकलित करने में सक्षम है।
-[[उच्च-क्रम प्रोग्रामिंग]] और [[बहुरूपता (कंप्यूटर विज्ञान)]] के जटिल रूपों में, संकलक के लिए उतना अनुमान लगाना हमेशा संभव नहीं होता है, और कभी-कभी अस्पष्टता के लिए टाइप एनोटेशन आवश्यक होते हैं। उदाहरण के लिए, [[बहुरूपी पुनरावर्तन]] के साथ प्रकार का अनुमान अनिर्णीत माना जाता है। इसके अलावा, स्पष्ट प्रकार के एनोटेशन का उपयोग कंपाइलर को अनुमान से अधिक विशिष्ट (तेज़/छोटे) प्रकार का उपयोग करने के लिए मजबूर करके कोड को अनुकूलित करने के लिए किया जा सकता है।<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>
+[[उच्च-क्रम प्रोग्रामिंग]] और [[बहुरूपता (कंप्यूटर विज्ञान)|बहुरूपता]] के जटिल रूपों में, कंपाइलर के लिए उतना अनुमान लगाना हमेशा संभव नहीं होता है, और कभी-कभी अस्पष्टता के लिए प्रकार की टिप्पणियां आवश्यक होती हैं। उदाहरण के लिए, [[बहुरूपी पुनरावर्तन|बहुरूपी]] प्रत्यावर्तन के साथ प्रकार का अनुमान अनिर्णीत माना जाता है। इसके अतिरिक्त, स्पष्ट प्रकार के एनोटेशन का उपयोग कंपाइलर को उसके अनुमान से अधिक विशिष्ट (तेज/छोटे) प्रकार का उपयोग करने के लिए मजबूर करके कोड को अनुकूलित करने के लिए किया जा सकता है।<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> सूची के प्रत्येक तत्व पर एक फ़ंक्शन लागू करता है, और इसे इस प्रकार परिभाषित किया जा सकता है:
+उदाहरण के तौर पर, हास्केल फ़ंक्शन <code>map</code>किसी सूची के प्रत्येक घटक पर एक फ़ंक्शन लागू करता है, और इसे इस प्रकार परिभाषित किया जा सकता है:
 <syntaxhighlight lang="haskell">
 map f [] = []
 map f (first:rest) = f first : map f rest
 </syntaxhighlight>
-पर अनुमान टाइप करें <code>map</code> फ़ंक्शन निम्नानुसार आगे बढ़ता है। <code>map</code> दो तर्कों का एक फ़ंक्शन है, इसलिए इसका प्रकार फॉर्म के रूप में बाध्य है <code>a → b → c</code>. हास्केल में, पैटर्न <code>[]</code> और <code>(first:rest)</code> हमेशा सूचियों से मेल खाते हैं, इसलिए दूसरा तर्क एक सूची प्रकार होना चाहिए: <code>b = [d]</code> किसी प्रकार के लिए <code>d</code>. यह पहला तर्क है <code>f</code> तर्क के लिए [[फ़ंक्शन अनुप्रयोग]] है <code>first</code>, जिसका प्रकार होना चाहिए <code>d</code>, सूची तर्क में प्रकार के अनुरूप, इसलिए <code>f :: d → e</code> (<code>::</code> किसी प्रकार के लिए साधन ) प्रकार का है <code>e</code>. का वापसी मूल्य <code>map f</code>, अंततः, जो कुछ भी है उसकी एक सूची है <code>f</code> पैदा करता है, इसलिए <code>[e]</code>.
+<code>map</code>फ़ंक्शन पर अनुमान टाइप करना निम्नानुसार आगे बढ़ता है। <code>map</code>दो तर्कों का एक फ़ंक्शन है, इसलिए इसका प्रकार<code>a → b → c</code> के रूप में बाध्य है। हास्केल में, पैटर्न<code>[]</code>और<code>(first:rest)</code> हमेशा सूचियों से मेल खाते हैं, इसलिए दूसरा तर्क एक सूची प्रकार होना चाहिए: कुछ प्रकार डी के लिए <code>b = [d]</code>। इसका <code>first</code>तर्क <code>f</code> पहले तर्क पर लागू होता है, जिसमें सूची तर्क के प्रकार के अनुरूप <code>d</code> प्रकार होना चाहिए, इसलिए कुछ प्रकार के <code>e</code> के लिए<code>f :: d → e</code> (<code>::</code> का अर्थ "प्रकार का है")। <code>map f</code> का रिटर्न मान, अंततः, जो कुछ भी <code>f</code>उत्पन्न करता है उसकी एक सूची है, इसलिए <code>[e]</code>।
-भागों को एक साथ रखने से परिणाम मिलता है <code>map :: (d → e) → [d] → [e]</code>. प्रकार चर के बारे में कुछ भी विशेष नहीं है, इसलिए इसे पुनः लेबल किया जा सकता है
+भागों को एक साथ रखने से :<code>map :: (d → e) → [d] → [e]</code> बनता है। प्रकार चर के बारे में कुछ भी खास नहीं है, इसलिए इसे इस प्रकार पुनः लेबल किया जा सकता है।
 <syntaxhighlight lang="haskell">
 map :: (a → b) → [a] → [b]
 </syntaxhighlight>
-यह पता चला है कि यह भी सबसे सामान्य प्रकार है, क्योंकि कोई और बाधा लागू नहीं होती है। जैसा कि अनुमान लगाया गया है <code>map</code> [[पैरामीट्रिक बहुरूपता]] है, तर्कों और परिणामों का प्रकार <code>f</code> अनुमान नहीं लगाया गया है, लेकिन प्रकार चर के रूप में छोड़ दिया गया है, इत्यादि <code>map</code> विभिन्न प्रकार के कार्यों और सूचियों पर लागू किया जा सकता है, जब तक कि प्रत्येक आह्वान में वास्तविक प्रकार मेल खाते हों।
+यह पता चला है कि यह सबसे सामान्य प्रकार भी है क्योंकि कोई और बाधा लागू नहीं होती है। चूँकि अनुमानित प्रकार का <code>map</code> [[पैरामीट्रिक बहुरूपता|पैरामीट्रिक]] रूप से बहुरूपी है, <code>f</code>के तर्कों और परिणामों के प्रकार का अनुमान नहीं लगाया गया है, लेकिन प्रकार चर के रूप में छोड़ दिया गया है, और <code>map</code>मानचित्र को विभिन्न प्रकार के कार्यों और सूचियों पर लागू किया जा सकता है, जब तक कि वास्तविक प्रकार प्रत्येक आह्वान में मेल खाते हैं।
-=={{anchor|algorithm}}हिंडले-मिलनर प्रकार अनुमान एल्गोरिथ्म ==
+==हिंडले-मिलनर प्रकार अनुमान एल्गोरिथ्म ==
-{{Main|Hindley–Milner type system}}
+{{Main|हिंडले-मिलनर प्रकार प्रणाली}}
-पहले प्रकार का अनुमान लगाने के लिए उपयोग किए जाने वाले एल्गोरिदम को अब अनौपचारिक रूप से हिंडले-मिलनर एल्गोरिदम कहा जाता है, हालांकि एल्गोरिदम को उचित रूप से दमास और मिलनर को जिम्मेदार ठहराया जाना चाहिए।<ref name="Damas-and-Milner-1982">{{Citation
+प्रकार का अनुमान लगाने के लिए सबसे पहले उपयोग किए जाने वाले एल्गोरिदम को अब अनौपचारिक रूप से हिंडले-मिलनर एल्गोरिदम कहा जाता है, हालांकि एल्गोरिदम का श्रेय उचित रूप से दमास और मिलनर को दिया जाना चाहिए।<ref name="Damas-and-Milner-1982">{{Citation
   |last1= Damas |first1= Luis
   |last2= Milner |first2= Robin
@@ Line 106: / Line 101: @@
   |url= http://groups.csail.mit.edu/pag/6.883/readings/p207-damas.pdf
   }}</ref>
-इस एल्गोरिदम का मूल सरल रूप से टाइप किए गए लैम्ब्डा कैलकुलस के लिए प्रकार अनुमान एल्गोरिदम है जिसे 1958 में [[हास्केल करी]] और [[रॉबर्ट फेयस]] द्वारा तैयार किया गया था।{{Citation needed|reason=This probably refers to [Combinatory Logic Volume 1 https://www.worldcat.org/title/combinatory-logic-vol-1-haskell-b-curry-and-robert-feys-with-two-sections-by-william-craig/oclc/769219250], however this actual claim is hard to find - it's 417 pages and has no table of contents. Please add a citation with page numbers if you can confirm this is a valid source. Also update [[Hindley–Milner type system]] as this claim is present there too.|date=February 2021}}
-में जे. रोजर हिंडले ने इस काम को आगे बढ़ाया और साबित किया कि उनका एल्गोरिदम हमेशा सबसे सामान्य प्रकार का अनुमान लगाता है।
+इस एल्गोरिथ्म का मूल सरल रूप से टाइप किए गए लैम्ब्डा कैलकुलस के लिए प्रकार अनुमान एल्गोरिदम है जिसे 1958 में [[हास्केल करी]] और [[रॉबर्ट फेयस]] द्वारा तैयार किया गया था। 1969 में जे. रोजर हिंडले ने इस कार्य को आगे बढ़ाया और साबित किया कि उनका एल्गोरिथ्म हमेशा सबसे सामान्य प्रकार का अनुमान लगाता है। 1978 में [[रॉबिन मिलनर]],<ref>{{Citation
-में [[रॉबिन मिलनर]],<ref>{{Citation
   |last1= Milner |first1= Robin
   |title= A Theory of Type Polymorphism in Programming
@@ Line 118: / Line 112: @@
   |doi=10.1016/0022-0000(78)90014-4
   |doi-access= free
-  }}</ref> हिंडले के काम से स्वतंत्र, एक समतुल्य एल्गोरिदम, एल्गोरिदम डब्ल्यू प्रदान किया गया।
+  }}</ref> ने हिंडले के काम से स्वतंत्र रूप से एक समतुल्य एल्गोरिदम, एल्गोरिदम डब्ल्यू प्रदान किया। 1982 में लुइस डेमास<ref name="Damas-and-Milner-1982" /> ने अंततः साबित कर दिया कि मिलनर का एल्गोरिदम पूर्ण है और इसे बहुरूपी संदर्भों के साथ सिस्टम का समर्थन करने के लिए विस्तारित किया गया था।
-में [[लुई दामास]]<ref name="Damas-and-Milner-1982" />अंततः साबित हुआ कि मिलनर का एल्गोरिदम पूर्ण है और इसे बहुरूपी संदर्भों वाले सिस्टम का समर्थन करने के लिए विस्तारित किया गया है।
 ==सबसे सामान्य प्रकार का उपयोग करने के दुष्प्रभाव==
-डिज़ाइन के अनुसार, प्रकार का अनुमान, विशेष रूप से सही (बैकट्रैकिंग) प्रकार का अनुमान सबसे सामान्य प्रकार के उपयुक्त उपयोग का परिचय देगा, हालांकि इसके निहितार्थ हो सकते हैं क्योंकि अधिक सामान्य प्रकार हमेशा एल्गोरिदमिक रूप से तटस्थ नहीं हो सकते हैं, विशिष्ट मामले ये हैं:
+डिज़ाइन के अनुसार, प्रकार का अनुमान, विशेष रूप से सही (बैकट्रैकिंग) प्रकार का अनुमान सबसे सामान्य प्रकार के उपयुक्त उपयोग को प्रस्तुत करेगा, हालाँकि, इसके निहितार्थ हो सकते हैं क्योंकि अधिक सामान्य प्रकार हमेशा एल्गोरिथम रूप से तटस्थ नहीं हो सकते हैं, विशिष्ट स्तिथि ये हैं:
-* फ़्लोटिंग-पॉइंट को एक सामान्य प्रकार का पूर्णांक माना जाता है, जबकि फ़्लोटिंग-पॉइंट सटीक मुद्दों को पेश करेगा
+* फ़्लोटिंग-पॉइंट को एक सामान्य प्रकार का पूर्णांक माना जा रहा है, जबकि फ़्लोटिंग-पॉइंट सटीक मुद्दों को प्रस्तुत करेगा।
-* भिन्न/गतिशील प्रकारों को अन्य प्रकारों के एक सामान्य प्रकार के रूप में माना जा रहा है, जो कास्टिंग नियमों और तुलनाओं को पेश करेगा जो भिन्न हो सकते हैं, उदाहरण के लिए ऐसे प्रकार संख्यात्मक जोड़ और स्ट्रिंग संयोजन दोनों के लिए '+' ऑपरेटर का उपयोग करते हैं, लेकिन कौन सा ऑपरेशन किया जाता है स्थिर के बजाय गतिशील रूप से निर्धारित किया जाता है
+*भिन्न/गतिशील प्रकारों को अन्य प्रकारों के एक सामान्य प्रकार के रूप में माना जा रहा है, जो कास्टिंग नियमों और तुलनाओं को प्रस्तुत करेगा जो भिन्न हो सकते हैं, उदाहरण के लिए, इस प्रकार के प्रकार संख्यात्मक परिवर्धन और स्ट्रिंग संयोजन दोनों के लिए '+' ऑपरेटर का उपयोग करते हैं, लेकिन कौन सा ऑपरेशन किया जाता है यह स्थिर के बजाय गतिशील रूप से निर्धारित किया जाता है।
-==प्राकृतिक भाषाओं के लिए प्रकार का अनुमान==
-प्राकृतिक भाषाओं के साथ-साथ प्रोग्रामिंग भाषाओं का विश्लेषण करने के लिए प्रकार अनुमान एल्गोरिदम का उपयोग किया गया है।<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>
+==प्राकृतिक भाषाओं के लिए प्रकार अनुमान==
+प्राकृतिक भाषाओं के साथ-साथ प्रोग्रामिंग भाषाओं का विश्लेषण करने के लिए टाइप इंट्रेंस एल्गोरिदम का उपयोग किया गया है।<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}}
 ==बाहरी संबंध==
 * [http://www.cis.upenn.edu/~bcpierce/types/archives/1988/msg00042.html Archived e-mail message] by Roger Hindley, explains history of type inference
@@ Line 143: / Line 132: @@
 {{DEFAULTSORT:Type Inference}}
-<!--Categories-->[[Category: अनुमान प्रकार| अनुमान प्रकार]] [[Category: सिस्टम टाइप करें]] [[Category: प्रकार सिद्धांत]] [[Category: अनुमान]] [[Category: उदाहरण सी कोड वाले लेख]] [[Category: उदाहरण हास्केल कोड वाले लेख]] [[Category: उदाहरण जावास्क्रिप्ट कोड वाले लेख]]
+<!--Categories-->
-[[Category: Machine Translated Page]]
+[[Category:Articles with hatnote templates targeting a nonexistent page|Type Inference]]
-[[Category:Created On 08/07/2023]]
+[[Category:CS1 English-language sources (en)]]
+[[Category:Created On 08/07/2023|Type Inference]]
+[[Category:Lua-based templates|Type Inference]]
+[[Category:Machine Translated Page|Type Inference]]
+[[Category:Pages with script errors|Type Inference]]
+[[Category:Templates Vigyan Ready|Type Inference]]
+[[Category:Templates that add a tracking category|Type Inference]]
+[[Category:Templates that generate short descriptions|Type Inference]]
+[[Category:Templates using TemplateData|Type Inference]]
+[[Category:Webarchive template wayback links|Type Inference]]
+[[Category:अनुमान|Type Inference]]
+[[Category:अनुमान प्रकार| अनुमान प्रकार]]
+[[Category:उदाहरण जावास्क्रिप्ट कोड वाले लेख|Type Inference]]
+[[Category:उदाहरण सी कोड वाले लेख|Type Inference]]
+[[Category:उदाहरण हास्केल कोड वाले लेख|Type Inference]]
+[[Category:प्रकार सिद्धांत|Type Inference]]
+[[Category:सिस्टम टाइप करें|Type Inference]]

Anonymous

Search

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

Namespaces

More

Page actions

Latest revision as of 14:25, 28 July 2023

Contents

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

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

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

तकनीकी विवरण

उदाहरण

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

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

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

संदर्भ

बाहरी संबंध

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

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

Latest revision as of 14:25, 28 July 2023

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

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

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

तकनीकी विवरण

उदाहरण

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

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

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

संदर्भ

बाहरी संबंध

Navigation

Wiki tools

Page tools

Other projects

Categories