2010-07-01 12 views
65

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

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

+3

मैं वास्तव में प्रश्न को नापसंद करता हूं, लेकिन यह पहले से ही कुछ शानदार और रोशनीपूर्ण प्रतिक्रियाओं को नेट करता है, इसलिए मैं भी बदनाम हो रहा हूं :) – Brian

+7

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

+7

मुझे सवाल पसंद है क्योंकि मुझे लगता है कि लगभग हर कोई जिसने अभी सीखना शुरू किया है # में दो विचार हैं: "वाह, एफ # इतना शक्तिशाली है!" और "डब्ल्यूटीएफ, क्यों एफ # इस मूर्खतापूर्ण अनुमान नहीं कर सकता ?!" :) –

उत्तर

49

"हास्केल के समान शक्तिशाली अनुमान" के संबंध में, मुझे नहीं लगता हास्केल

  • OO शैली गतिशील subtyping से निपटने के लिए है (प्रकार कक्षाएं कुछ इसी तरह की चीजें कर सकते हैं, लेकिन प्रकार कक्षाएं टाइप करने के लिए आसान कर रहे हैं/अनुमान)
  • विधि, अधिक भार (प्रकार कक्षाएं कुछ इसी तरह की चीजें कर सकते हैं लेकिन प्रकार वर्गों को प्रकार/अनुमानित करना आसान होता है)

यही है, मुझे लगता है कि एफ # को कुछ कठिन चीजों से निपटना है जो हास्केल नहीं करता है। (लगभग निश्चित रूप से, हास्केल को कुछ कठिन चीजों से निपटना है जो एफ # नहीं करता है।)

जैसा कि अन्य उत्तरों द्वारा वर्णित है, अधिकांश प्रमुख .NET भाषाओं में विजुअल स्टूडियो टूलींग एक प्रमुख भाषा डिजाइन प्रभाव के रूप में है (उदाहरण के लिए LINQ को SQL-y के बजाय "से चुनें ..." चुनें ... ", प्रोग्राम उपसर्ग से इंटेलिजेंस प्राप्त करके प्रेरित)। Intellisense, त्रुटि squiggles, और त्रुटि संदेश संवेदना सभी टूलींग कारक हैं जो एफ # डिजाइन को सूचित करते हैं।

बेहतर करना और बेहतर करना संभव है (अन्य अनुभवों पर बलिदान के बिना), लेकिन मुझे नहीं लगता कि यह भाषा के भविष्य के संस्करणों के लिए हमारी उच्च प्राथमिकताओं में से एक है। (हास्केलर एफ # प्रकार अनुमान को कुछ हद तक कमजोर देख सकते हैं, लेकिन संभवतः वे सी # ers से अधिक संख्या में हैं जो एफ # प्रकार अनुमान को बहुत मजबूत मानते हैं। :))

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

+1

यह भी देखें http://lorgonblog.wordpress.com/2009/10/25/overview-of-type-inference-in-f/ – Brian

+1

ओह विधि के बिना हास्केल के लिए थोड़ा अधिक अधिभारित करना। फ़ंक्शन परिभाषा (पैरामीटर और रिटर्न प्रकार) स्पष्ट रूप से समझ में आती हैं .. – nawfal

16

एफ # एक पास संकलन ऐसी है कि आप केवल प्रकार या कार्य करता है जो फ़ाइल में परिभाषित किया गया है या तो पहले आप रहे संदर्भित कर सकते हैं वर्तमान में या जो में पहले निर्दिष्ट किया जाता है एक फ़ाइल में दिखाई का उपयोग करता है संकलन आदेश।

मैंने हाल ही में प्रकार अनुमान प्रक्रिया को बेहतर बनाने के लिए कई स्रोत पास बनाने के बारे में डॉन सिमे से पूछा। उनका जवाब था "हाँ, यह बहु-पास प्रकार निष्कर्ष करने के लिए संभव है। वहाँ भी एकल-पास विविधताओं कि बाधाओं के एक परिमित सेट उत्पन्न करते हैं।

हालांकि इन तरीकों बुरा त्रुटि संदेश देने के लिए जाते हैं और खराब इंटेलिजेंस परिणाम संपादक में परिणाम। "

http://www.markhneedham.com/blog/2009/05/02/f-stuff-i-get-confused-about/#comment-16153

+2

दिलचस्प। मुझे वैसे भी सादा एफ # कार्यों के लिए महान इंटेलिजेंस मदद नहीं मिलती है; ज्यादातर ऐसा लगता है जब आप Module.somefunc करते हैं या एक वर्ग का उपयोग करते हैं (जो मूल रूप से टाइप अनुमान को मारता है)। मुझे आश्चर्य है कि यह डिज़ाइन पसंद कैसे सेट-इन-पत्थर है। –

+1

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

18

मुझे लगता है कि एफ # द्वारा प्रयोग किया जाता एल्गोरिथ्म लाभ यह है कि यह करने के लिए आसान है कि (कम से कम मोटे तौर पर) बताएं कि यह कैसे, काम करता है ताकि एक बार आप इसे समझते हैं, आप के बारे में कुछ उम्मीदें हैं कर सकते हैं परिणाम।

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

इस पर एक और विचार यह है कि ऊपर से नीचे तक कोड की जांच करना इस बात से मेल खाता है कि हम कोड कैसे पढ़ते हैं (कम से कम कभी-कभी)। तो, शायद तथ्य यह है कि हम कोड को इस तरह लिखते हैं कि टाइप-इनफरेंस कोड को लोगों के लिए अधिक पठनीय बनाता है ...

+9

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

+3

आपके द्वारा पसंद किया जाने वाला ऑर्डर कॉल-बाय-नाम के साथ सबसे स्वाभाविक है क्योंकि यह मूल्यांकन के क्रम को दर्शाता है। कॉल-बाय-वैल्यू के साथ एफ # रास्ता अधिक प्राकृतिक है - खासकर जब परिभाषाओं के तत्काल प्रभाव हो सकते हैं। – RD1

51

क्या एफ # के डिजाइन या विचारधारा के बारे में कुछ भी अलग है जो इसका कारण बन रहा है?

हां। एफ # संरचनात्मक टाइपिंग के बजाय नाममात्र का उपयोग करता है क्योंकि यह सरल है और इसलिए, केवल प्राणियों के उपयोग के लिए आसान है।

इस एफ # उदाहरण पर विचार करें:

let lengths (xss: _ [] []) = Array.map (fun xs -> xs.Length) xss 

let lengths (xss: _ [] []) = xss |> Array.map (fun xs -> xs.Length) 

पूर्व संकलन नहीं है क्योंकि गुमनाम समारोह अंदर xs के प्रकार का पता नहीं लगाया जा सकता है एफ # प्रकार "एक Length सदस्य के साथ कुछ वर्ग" व्यक्त नहीं कर सकते क्योंकि।

इसके विपरीत, OCaml प्रत्यक्ष समकक्ष व्यक्त कर सकते हैं:

let lengths xss = Array.map (fun xs -> xs#length) xss 

क्योंकि OCaml (यह <length: 'a ..> लिखा है) कि प्रकार व्यक्त कर सकते हैं। ध्यान दें कि वर्तमान में F # या Haskell की तुलना में इसके लिए अधिक शक्तिशाली प्रकार अनुमान की आवश्यकता है, उदा। ओकैमल योग प्रकार का अनुमान लगा सकता है।

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

+4

दिलचस्प। सभी चीजों को माना जाता है, क्या आप एफ # के नाममात्र टाइपिंग या ओकैमल की संरचनात्मक टाइपिंग पसंद करते हैं? –

+13

मेरे में अकादमिक ओकैमल तरीका पसंद करता है क्योंकि यह बहुत अधिक संक्षिप्त हो सकता है (उदा। 'सिस्टम। विन्डोज़.कंट्रोल। स्क्रॉलबायर दृश्यता। दृश्यमान' .NET पर ओसीएमएल में सिर्फ 'दृश्यमान' है)। मेरे उद्यमी एफ # तरीके को पसंद करते हैं क्योंकि वाणिज्यिक व्यवहार्यता के लिए मेरे ग्राहकों के लिए आसानी से उपयोग करना आवश्यक है। शायद हालांकि एक बेहतर समझौता है। –

12

संक्षिप्त उत्तर यह है कि एफ # एसएमएल और ओकैमल की परंपरा पर आधारित है, जबकि हास्केल मिरांडा, गोफर और इसी तरह की एक अलग दुनिया से आता है। ऐतिहासिक परंपरा में मतभेद सूक्ष्म, लेकिन व्यापक हैं। यह भेद अन्य आधुनिक भाषाओं में भी समान है, जैसे कि एमएल-जैसे कोक, जिसमें हास्केल जैसी एजडा बनाम वही ऑर्डरिंग प्रतिबंध है जो नहीं करता है।

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

+1

@ng: "... ऐसे बहुत सारे लोग हैं जो सोचते हैं कि इन चीजों को स्पष्ट करना बेहतर है"। बहुत से लोग सख्तता और अशुद्धियों की तुलना में आलस्य को स्पष्ट रूप से एनोटेट करेंगे क्योंकि आलस्य बहुत ही कम उपयोगी होती है जबकि सख्तता और अशुद्धता सर्वव्यापी होती हैं (असली हास्केल कोड में भी)। –

+5

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