क्या अपर्याप्त रूप से अभिव्यक्त होने वाली स्थिर टाइपिंग वाली भाषाओं के लिए AY नोटेशन है? [बन्द है]

Question

एरिक लिपर्ट के लेख में हंगेरियन नोटेशन के साथ क्या है? , वह बताता है कि हंगेरियन नोटेशन (अच्छा प्रकार) का उद्देश्य है

भंडारण प्रतिनिधित्व सूचना के अलावा अर्थ सूचना को शामिल करने के लिए "प्रकार" की अवधारणा का विस्तार करें।

एक सरल उदाहरण एक चर का उपसर्ग होगा जो "x" के साथ एक एक्स-समन्वय का प्रतिनिधित्व करता है और एक चर जो "y" के साथ एक Y- समन्वय का प्रतिनिधित्व करता है, भले ही वे चर पूर्णांक या फ़्लोट हों या जो भी हों, ताकि जब आप गलती से लिखें। xFoo + yBarकोड स्पष्ट रूप से गलत दिखता है।

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

तो, हंगेरियन नोटेशन प्रोग्रामिंग भाषाओं के लिए सिर्फ एक बैंड-सहायता है, जिनके प्रकार सिस्टम अर्थ सूचना को सांकेतिक नहीं कर सकते हैं? या हंगेरियन नोटेशन एक स्थिर प्रकार की प्रणाली जैसे कि हास्केल की पेशकश कर सकता है, उससे परे कुछ प्रदान करता है?

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

---

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

Comments

पास्कल - यद्यपि यदि आप पास्कल में परिभाषित एक XCood और YCoord प्रकार जोड़ते हैं तो आप बस एक संकलक चेतावनी IIRC प्राप्त करेंगे

— mcottle

blog.moertel.com/articles/2006/10/18/… हास्केल में टाइप सिस्टम में "एप्स आयु " के समान कुछ करने के बारे में एक लेख है।

— लोगन कैपल्डो

F # में यह स्टाइल फीचर भी है।

— रंगोरिक

यह वास्तव में एक अच्छा लेख लिंक है (moertel.com एक) बिल्कुल उसी तरह की चीज दिखा रहा है जिसके बारे में मैं सोच रहा था: स्ट्रिंग-इंटरपोलेशन सुरक्षा कमजोरियों और जैसे संकलन-समय त्रुटियों को चालू करने के लिए टाइप सिस्टम का उपयोग करना। लिंक के लिए धन्यवाद।

— रयान सी। थॉम्पसन

मुझे लगता है कि शब्दार्थ के लिए हंगेरियन संकेतन के साथ बहुत सारे OO पकड़े गए, क्योंकि आज आप शायद लिखेंगे: Foo.Position.X + Bar.Position.Y।

— पीटर बी

Answer 1

मैं हाँ कहूँगा"।

जैसा कि आप कहते हैं, हंगेरियन नोटेशन का उद्देश्य उस नाम में जानकारी को एनकोड करना है जो टाइप में एनकोड नहीं किया जा सकता है। हालांकि, मूल रूप से दो मामले हैं:

1. वह जानकारी महत्वपूर्ण है।
2. वह जानकारी महत्वपूर्ण नहीं है।

चलो पहले मामले 2 से शुरू करते हैं: यदि वह जानकारी महत्वपूर्ण नहीं है, तो हंगेरियन नोटेशन केवल शानदार शोर है।

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

जो हमें एरिक लिपर्ट बोली में वापस लाता है:

भंडारण प्रतिनिधित्व सूचना के अलावा अर्थ सूचना को शामिल करने के लिए "प्रकार" की अवधारणा का विस्तार करें।

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

Comments

C, जहां हंगेरियन अंकन AFAIK सबसे अधिक इस्तेमाल किया गया था, हालांकि एक OO भाषा नहीं है।

— Péter Török

@ PéterTörök: OO एक डिज़ाइन पैटर्न है, न कि किसी भाषा की विशेषता, हालांकि आधुनिक भाषाओं को डिज़ाइन करना आसान है, जबकि C नहीं है।

— Jan Hudec

@ PéterTörök: मैंने प्लेन सी में काफी ऑब्जेक्ट ओरिएंटेड कोड लिखे। मुझे नहीं पता कि मैं किस बारे में बात कर रहा हूं।

— जन हडेक

हालांकि यह सच हो सकता है कि महत्वपूर्ण जानकारी को अपने नाम के बजाय एक चर के प्रकार में एम्बेड किया जाना चाहिए, कई महत्वपूर्ण चीजें हैं जिन्हें कहा जाना चाहिए, लेकिन कौन से प्रकार सिस्टम व्यक्त नहीं कर सकते हैं। उदाहरण के लिए, यदि S1ब्रह्मांड में कहीं भी एकमात्र संदर्भ है char[], जिसका धारक वांछित होने पर उसे बदल सकता है और बदल सकता है, लेकिन कभी भी बाहरी कोड को उजागर नहीं करना चाहिए, और S2यह एक संदर्भ है char[]जिसे किसी को कभी भी बदलना नहीं चाहिए, लेकिन जिसे साझा किया जा सकता है वस्तुओं है कि इसे बदलने के लिए नहीं वादा के साथ, चाहिए S1और S2एक ही "कुछ ऐसी बातें" के रूप में अर्थ की दृष्टि से माना जा?

— सुपरकैट

@ सुपरकैट - आप विशिष्टता के प्रकारों का वर्णन कर रहे हैं।

— जैक

Answer 2

प्रकारों का पूरा उद्देश्य (एक डिज़ाइन टूल के रूप में) अर्थ संबंधी जानकारी को एनकोड करना है!

मुझे यह उत्तर पसंद आया और मैं इस उत्तर का अनुसरण करना चाहता था ...

हास्केल के बारे में मुझे कुछ पता नहीं है, लेकिन आप xFoo + yBarकिसी भी भाषा में उदाहरण की तरह कुछ कर सकते हैं जो कुछ प्रकार की सुरक्षा का समर्थन करता है जैसे सी, सी ++ या जावा। C ++ में आप XDir और YDir वर्गों को अतिभारित '+' ऑपरेटरों के साथ परिभाषित कर सकते हैं जो केवल अपने प्रकार की वस्तुओं को लेते हैं। सी या जावा में, आपको '+' ऑपरेटर के बजाय एक ऐड () फ़ंक्शन / विधि का उपयोग करके अपना अतिरिक्त करने की आवश्यकता होगी।

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

Comments

ऑब्जेक्ट-ओरिएंटेड होना न तो xFoo + yBarउपयोगकर्ता-परिभाषित प्रकारों के लिए अनुमति देने के लिए किसी भाषा के लिए आवश्यक है और न ही , उदाहरण के लिए काम करने के लिए C ++ का OO पहलू आवश्यक है।

— ल्यूक डैंटन

आप सही हैं यह ओओ नहीं है यह प्रकार की सुरक्षा है। मैंने अपना उत्तर संपादित किया।

— BHS

हम्म। यह एक अच्छी बात है कि आप xFoo + yBarकिसी भी भाषा में एक संकलित त्रुटि (या कम से कम एक रनटाइम त्रुटि) कर सकते हैं। हालाँकि, XDir और YDir वर्गों के साथ गणित करेगा, कहते हैं, जावा या C ++ गणित की तुलना में कच्चे नंबरों से धीमी होगी? मेरी समझ यह है कि हास्केल में, प्रकारों का संकलन समय पर किया जाता है, और फिर रनटाइम में, यह बिना किसी प्रकार की जाँच के कच्चा माल होगा, और इसलिए नियमित संख्याओं को जोड़ने की तुलना में कोई धीमा नहीं है।

— रयान सी। थॉम्पसन

C ++ में, टाइप चेकिंग को संकलन समय पर भी किया जाएगा, और रूपांतरण और ऐसे अधिकांश मामलों में अनुकूलित किया जाएगा। जावा ऐसा नहीं करता है, क्योंकि यह ऑपरेटर को ओवरलोडिंग की अनुमति नहीं देता है और जैसे - तो आप XCoordinateउदाहरण के लिए एक नियमित इंट के रूप में इलाज नहीं कर सकते हैं ।

— cHao

Answer 3

मुझे एहसास है कि वाक्यांश "हंगेरियन नोटेशन" का अर्थ कुछ अलग है जो मूल है , लेकिन मैं सवाल का "नहीं" जवाब दूंगा। शब्दांश या कम्प्यूटेशनल प्रकार के साथ नामकरण चर SML या हास्केल शैली टाइपिंग के समान काम नहीं करता है। यह एक बैंडेड भी नहीं है। एक उदाहरण के रूप में सी लेते हुए, आप एक चर gpszTitle नाम दे सकते हैं, लेकिन उस चर में वैश्विक गुंजाइश नहीं हो सकती है, यह एक अशक्त-समाप्त स्ट्रिंग के लिए एक बिंदु का गठन भी नहीं कर सकता है।

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

Answer 4

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

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

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

उदाहरण के लिए, जॉल्स के प्रसिद्ध लेख में एप्स हंगेरियन की प्रशंसा करते हुए, वह एचटीएमएल-इंजेक्शन को रोकने के usलिए एक असुरक्षित स्ट्रिंग के लिए उपसर्ग का उदाहरण और sएक सुरक्षित (html एन्कोडेड) स्ट्रिंग का उपयोग करता है। डेवलपर HTML-इंजेक्शन गलतियों को केवल सावधानीपूर्वक कोड का निरीक्षण करके सुनिश्चित कर सकता है और यह सुनिश्चित करता है कि चर उपसर्ग मेल खाते हैं। उनका उदाहरण VBScript में है, जो अब अप्रचलित भाषा है जो शुरू में कस्टम कक्षाओं की अनुमति नहीं देती थी। एक आधुनिक भाषा में समस्या को एक कस्टम प्रकार के साथ तय किया जा सकता है, और वास्तव में ऐसा एस्पेक्ट HtmlStringक्लास के साथ करता है । इस तरह संकलक स्वचालित रूप से त्रुटि को ढूंढ लेगा, जो कि अधिक सुरक्षित है जो मानव नेत्रगोलक पर निर्भर है। तो स्पष्ट रूप से कस्टम प्रकार वाली भाषा इस मामले में "एप्स हंगेरियन" की आवश्यकता को समाप्त करती है।

Answer 5

हां, हालांकि कई भाषाएं जिनमें अन्यथा मजबूत पर्याप्त प्रकार की प्रणालियां हैं, अभी भी एक समस्या है - नए प्रकार की अभिव्यक्तता जो मौजूदा प्रकारों के समान / समान हैं।

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

अनिवार्य रूप से हमें इन भाषाओं में अच्छी तरह से आयु संकेतन को मारने के लिए किसी प्रकार के टाइप किए गए प्रकारों की आवश्यकता है (एफ # शैली यूओएम यह भी कर सकता है)

Answer 6

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

उन अंधेरे दिनों में, यह जानना उपयोगी था कि एक चर किस प्रकार का उपयोग किया जा रहा था। यदि ठीक से बनाए रखा जाता है (एक BIG अगर रिफ्लेक्टरिंग उपकरणों की कमी के कारण) तो हंगेरियन संकेतन ने आपको वह दिया।

भयानक नामों के इन दिनों की लागत बहुत अधिक है, लेकिन यह अपेक्षाकृत हाल की बात है। बहुत सारे कोड अभी भी मौजूद हैं जो मेरे द्वारा वर्णित आईडीई के विकास से पहले हैं।

Comments

अगर मैं गलत नहीं हूं, तो यह एक और जवाब है जो ओप के बारे में पूछ रहे हैं की तुलना में एक अलग प्रकार के हंगेरियन संकेतन को संबोधित कर रहा है।

— MatrixFrog

यह उत्तर बताता है कि क्या "सिस्टम हंगेरियन" कहा जाता है, जहां उपसर्ग भाषा-स्तर "प्रकार" को दर्शाता है। प्रश्न "एप्स हंगेरियन" के बारे में पूछता है, जहां "प्रकार" शब्द को गलत नहीं समझा गया है और इसका अर्थ है शब्दार्थ प्रकार। सिस्टम हंगेरियन ने इन दिनों लगभग सार्वभौमिक रूप से निंदा की है (और ठीक ही तो; यह हंगेरियन नोटियन के वास्तविक उद्देश्य का एक बार्डराइजेशन है)। एप्स हंगेरियन हालांकि एक अच्छी बात हो सकती है।

— cHao

70 के बाद से अस्तित्व में हैं संपादक बिना sCustomerName (vi और emacs 2 उदाहरण हैं) लेने के लिए sCustomer की खोज करने में सक्षम हैं।

— लैरी कोलमैन

@ लॉरी, हो सकता है, लेकिन आप उन्हें उन सिस्टम पर चलने के लिए नहीं मिल सकते जिन्हें मैं 80 के दशक में प्रोग्रामिंग कर रहा था

— mcottle

@chao, नहीं, यह नहीं है - मेरी बात यह समझाने की कोशिश कर रही थी कि लोग अतिरिक्त जानकारी को आम तौर पर चर नामों में क्यों डालते हैं। मैंने हंगेरियन नोटेशन के किसी भी संस्करण का उल्लेख करने से स्पष्ट रूप से परहेज किया। हो सकता है कि मैंने जो उदाहरण दिया है "क्यों खोज और प्रतिस्थापन स्रोत कोड पर काम नहीं करता है" अनुभाग आपको "सिस्टम हंगेरियन" जैसा दिखता है, लेकिन इसका मतलब नहीं था। मैंने भ्रम से बचने के लिए प्रमुख "s" को हटा दिया है।

— mcottle 5

Answer 7

सही बात!

असेंबलर जैसी पूरी तरह से अप्राप्त भाषाओं के बाहर, हंगेरियन संकेतन शानदार और कष्टप्रद है। संदेह है कि जब आप विचार करते हैं कि अधिकांश आईडीई आपके, एर, प्रकार की सुरक्षा की जाँच करते हैं।

अतिरिक्त "मैं" "डी" और "?" उपसर्ग केवल कोड को कम पठनीय बनाते हैं, और, वास्तव में भ्रामक हो सकते हैं - जैसे कि "काउ-ऑर्कर" इंटिजर से लॉन्ग में iaSumsItems के प्रकार को बदलता है, लेकिन फ़ील्ड नाम को रीक्रिएट करने में परेशान नहीं करता है।

Comments

आपकी प्रतिक्रिया से पता चलता है कि आप मूल, स्मार्ट "एप्स" हंगेरियन और "सिस्टम" हंगेरियन नामक गूंगे कमीने के बीच अंतर को नहीं समझते हैं। पढ़ें joelonsoftware.com/articles/Wrong.html

— रयान