2009-11-11 13 views
14

मैं गो एफएक्यू में this question पर आया, और यह मुझे कुछ ऐसा याद दिलाता है जो मुझे थोड़ी देर के लिए परेशान कर रहा है। दुर्भाग्य से, मैं वास्तव में नहीं देखता कि जवाब क्या हो रहा है।क्यों कई प्रोग्रामिंग भाषाओं प्रकार * बाद * परिवर्तनीय नाम डालते हैं?

ऐसा लगता है लगभग हर गैर सी जैसी भाषा चर नाम के बाद प्रकार डालता है की तरह तो, जैसे:

var : int 

बस सरासर जिज्ञासा से बाहर, ऐसा क्यों है? क्या एक या दूसरे को चुनने के फायदे हैं?

+0

@Jurily - मुझे लगता है कि विवाद नहीं होगा। मैं सिर्फ उत्सुक था अगर चीजों को एक और तरीके से करने में कोई फायदा हुआ। –

+3

@ जुरीली, पूरी तरह से सटीक होने के लिए, _everyone_ का आखिरी नाम आखिरी नाम है :-)। और निष्पक्ष होने के लिए, मुझे लगता है कि यदि ज्यादातर लोग इसे निष्पक्ष फैशन में देखना चाहते हैं तो वे इस बात से सहमत होंगे कि सामान्य दृष्टिकोण (जैसे चीनी या जैसा कि आप कहते हैं, हंगेरियन) सामान्य समझ में आता है। –

+0

https://stackoverflow.com/questions/1891775/any-reason-for-having-val-capacity-int-instead-of-val-int-capacity-in-scal/1893263 – starblue

उत्तर

12

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

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

पास्कल वाक्य रचना विषय से मुक्त है। तथ्य यह है कि परिवर्तनीय नाम पहले आता है जो कोलन विभाजक और प्रकार के विवरणों के वाक्यविन्यास जैसे विवरणों से कम महत्वपूर्ण है।

सी वाक्यविन्यास संदर्भ-संवेदनशील है।पार्सर को यह निर्धारित करने के लिए कि एक प्रकार का वर्णन कहां समाप्त होता है और कौन सा टोकन परिवर्तनीय नाम है, इसे पहले से आने वाली सभी चीज़ों का अर्थ पहले से ही समझना होगा ताकि यह निर्धारित किया जा सके कि कोई निर्दिष्ट पहचानकर्ता टोकन परिवर्तनीय नाम है या केवल एक अन्य टोकन योगदान दे रहा है या नहीं प्रकार का विवरण।

क्योंकि सी सिंटैक्स संदर्भ-संवेदनशील है, पारंपरिक पार्सर-जनरेटर उपकरण जैसे yacc/bison का उपयोग करके पार्स करना बहुत मुश्किल है (जबकि असंभव नहीं है), जबकि पास्कल सिंटैक्स एक ही टूल का उपयोग करके पार्स करना आसान है। उस ने कहा, अब पार्सर जनरेटर हैं जो सी और यहां तक ​​कि सी ++ वाक्यविन्यास का सामना कर सकते हैं। हालांकि यह ठीक से दस्तावेज या 1 में नहीं है? रिलीज इत्यादि, मेरा निजी पसंदीदा Kelbt है, जो बैकट्रैकिंग एलआर का उपयोग करता है और अर्थात् "पूर्ववत" का समर्थन करता है - मूल रूप से प्रतीक तालिका में जोड़ों को पूर्ववत करता है जब सट्टा पार्स गलत हो जाते हैं।

प्रैक्टिस में, सी और सी ++ पार्सर्स आमतौर पर हाथ से लिखे जाते हैं, रिकर्सिव वंश और प्राथमिकता पार्सिंग मिश्रण करते हैं। मुझे लगता है कि यह जावा और सी # पर लागू होता है।

संयोग से, सी ++ पार्सिंग में संदर्भ संवेदनशीलता के साथ समान मुद्दों ने बहुत सारे नास्टियां बनाई हैं। सी ++ 0x के लिए "Alternative Function Syntax" एक प्रकार के विनिर्देश को अंत में ले जाकर और एक विभाजक के बाद रखकर एक समान समस्या के आसपास काम कर रहा है - फ़ंक्शन रिटर्न प्रकारों के लिए पास्कल कोलन की तरह। यह संदर्भ संवेदनशीलता से छुटकारा नहीं पाता है, लेकिन उस पास्कल जैसे सम्मेलन को अपनाने से यह थोड़ा अधिक प्रबंधनीय बन जाता है।

+0

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

+0

हालांकि यह कॉलन के एक समारोह का अधिक नहीं है ? जैसे कि मैं बता सकता हूं कि 'var: int' कोलन की वजह से एक परिवर्तनीय नाम है। ऐसा लगता है कि यह 'int: var' करने के लिए जितना आसान होगा (यद्यपि शायद थोड़ा और बदसूरत :-))। –

+1

@ जेसन बेकर - देरी के लिए खेद है। एक कंपाइलर "varname int" या "int varname" को संभाल सकता है, मानते हैं कि "int" एक कीवर्ड है। हालांकि, "वर्नाम माईटाइप" या "माईटाइप वर्नामे" एक मुद्दा है - क्योंकि "माईटाइप" बिल्कुल पहचानकर्ता नहीं है, लेकिन क्योंकि आपको यह निर्धारित करने के लिए शब्दकोशक लुकअप की आवश्यकता है कि कौन सी वाक्य रचनात्मक संरचना लागू हो सकती है। पुराना सी सिंटैक्स जहां संरचना नाम वैध टाइपनाम नहीं थे (आप "स्ट्रक्चर स्ट्रक्चरनाम माईवर;" लिखेंगे) सरल था, क्योंकि "स्ट्रक्चर" उपसर्ग सिंटैक्टिक रूप से दिखाता है कि टाइप * is * एक प्रकार है। एक कोलन मदद कर सकता है, लेकिन यह न तो संपूर्ण और न ही एकमात्र समाधान है। – Steve314

1

यह सिर्फ भाषा को डिज़ाइन किया गया था। विजुअल बेसिक हमेशा इस तरह से रहा है।

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

+4

भाषाओं उस प्रकार पिछले भी डाल (: प्रकार आर्ग): return_type –

+0

C++ 0x आप समारोह वापसी प्रकार पिछले डाल करने के लिए अनुमति देता है: पिछले वापसी प्रकार, जैसे नाम डाल 'ऑटो समारोह (पूर्णांक ARG1) -> int' – jmucchiello

10

आपके द्वारा बोलने वाली 'सबसे अन्य' भाषाएं वे अधिक घोषणात्मक हैं। उनका उद्देश्य आपको उन लाइनों के साथ प्रोग्राम करने की इजाजत देना है जो आपको लगता है (माना जाता है कि आपको अनिवार्य सोच में शामिल नहीं किया गया है)।

प्रकार पिछले के रूप में पढ़ता

इस 'एक प्रकार का नाम बनाएं जिसका नाम' कहने के लिए निश्चित रूप से विपरीत है, लेकिन आप इसके बारे में सोचते हैं, क्या मूल्य के लिए है 'एक चर प्रकार प्रकार का नाम बनाएं जिसका नाम' प्रकार से अधिक महत्वपूर्ण है, प्रकार डेटा पर केवल एक प्रोग्रामेटिक बाधा है

+1

+1 खैर ने कहा ... और 15 और अक्षर – wheaties

1

मुझे यकीन नहीं है, लेकिन मुझे लगता है कि इसे "नाम बनाम संज्ञा" अवधारणा के साथ करना है।

अनिवार्य रूप से, यदि आप पहले प्रकार (जैसे "int varname") डालते हैं, तो आप "पूर्णांक नामित 'पूर्ण नाम' घोषित कर रहे हैं; यानी, आप एक प्रकार का नाम दे रहे हैं। हालांकि, अगर आप पहले नाम डालते हैं, और फिर प्रकार (जैसे "वर्नामे: int"), तो आप कह रहे हैं "यह 'वर्नाम' है; यह एक पूर्णांक है"। पहले मामले में, आप किसी नाम का उदाहरण दे रहे हैं; दूसरे में, आप एक संज्ञा को परिभाषित कर रहे हैं और यह बताते हुए कि यह कुछ का उदाहरण है।

यह थोड़ा सा है जैसे आप फर्नीचर के टुकड़े के रूप में एक टेबल को परिभाषित कर रहे थे; कह रही है "यह फर्नीचर है और मैं इसे 'टेबल' कहता हूं" (पहले टाइप करें) "एक टेबल एक प्रकार का फर्नीचर है" (आखिरी प्रकार) कहने से अलग है।

0

पहले प्रकार डालने से पार्सिंग में मदद मिलती है। उदाहरण के लिए, सी में, आप

x int; 

की तरह चर घोषित करता है, तो जब आप सिर्फ x पार्स, तो आप नहीं जानते कि क्या एक्स एक घोषणा या एक अभिव्यक्ति है। इसके विपरीत,

int x; 

साथ जब आप int पार्स, तुम्हें पता है कि आप एक घोषणा में हो (प्रकार हमेशा किसी प्रकार की घोषणा शुरू)।

पार्सिंग भाषाओं में प्रगति को देखते हुए, यह मामूली सहायता आजकल बहुत उपयोगी नहीं है।

+1

तो पार्स करने में आसानी के लिए अपने लक्ष्य है, यदि आप एक कीवर्ड कि इस तरह के वर के रूप में सभी चर घोषणाओं, परिचय होगा: 'वर मैं: int' या' वर पूर्णांक मैं 'घ – jmucchiello

+0

और उपयोगकर्ता-निर्धारित प्रकार (typedefs) के लिए: xyz एबीसी; - किस प्रकार का नाम है और कौन सा नाम है? जब तक नियम नियमों पर सहमत होता है, तब तक कोई समस्या नहीं होती है - और यदि भाषा नियमों पर सहमत नहीं हो सकती है, तो शायद यह दृष्टांत नहीं है। –

-3

गतिशील रूप से (चीयर्स @wcoenen) टाइप की गई भाषाओं के बारे में क्या? आप बस चर का उपयोग करें।

+8

आपका मतलब है "गतिशील रूप से टाइप किया गया"। "कमजोर बनाम मजबूती से टाइप किया गया" एक समान भेद नहीं है "स्थिर रूप से बनाम गतिशील रूप से टाइप किया गया"। उदाहरण के लिए, अजगर गतिशील और दृढ़ता से टाइप किया भाषा है: http://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language कमजोर भाषाओं टाइप किया –

+0

अजीब या (पुराने) पर्ल की तरह; या फोरट्रान इसके स्पष्ट रूप से टाइप किए गए चर के साथ - एन के माध्यम से I के साथ शुरू होने वाले नाम पूर्णांक हैं; बाकी असली हैं। –

7

यदि चर का नाम कॉलम 0 पर शुरू होता है, तो चर का नाम ढूंढना आसान है।

QHash<QString, QPair<int, QString> > hash; 

और

hash : QHash<QString, QPair<int, QString> >; 

तुलना करें अब कल्पना कितना अधिक पठनीय अपने ठेठ सी ++ शीर्ष लेख हो सकता है।

+0

+1 नाम पहले अधिक पठनीय है, यह आपको सीधे बताता है कि कथन सीधे क्या काम कर रहा है ... निश्चित रूप से आप अर्थपूर्ण परिवर्तनीय नामों का उपयोग कर रहे हैं। – bobince

6

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

x : A y : B 
------------- 
\x.y : A->B 

मैं यह वाकई महत्वपूर्ण नहीं लगता कि है, लेकिन मुझे लगता है कि दो औचित्य देखते हैं: एक है कि "एक्स: एक" "x टाइप ऑफ ए" है, दूसरा यह है कि एक प्रकार एक सेट की तरह है (उदाहरण के लिए int पूर्णांक का सेट है), और नोटेशन "x ε ए" से संबंधित है।

इनमें से कुछ चीजें आधुनिक भाषाओं की पूर्व-तिथियां हैं जिनके बारे में आप सोच रहे हैं।

8

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

प्रकार कभी कभी दिया जाता है और कभी-कभी अनुमानित है, तो यह आसान वैकल्पिक सा बाद में आता है, तो पढ़ने के लिए है।

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

0

फोरट्रान प्रकार डालता पहले:

REAL*4 I,J,K 
INTEGER*4 A,B,C 

और हाँ, वहाँ एक (बहुत कमजोर) फोरट्रान से परिचित लोगों के लिए वहाँ मजाक है।

बहस करने जब प्रकार काफ़ी पेचीदा है कि इस सी है, जो नाम के आसपास प्रकार की जानकारी रखता है की तुलना में आसान है कमरे (कार्यों के लिए संकेत दिए गए उदाहरण के लिए,) नहीं है।

+0

आपने obfuscate FORTRAN का आविष्कार किया है। बहुत बढ़िया। – jmucchiello

1

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

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

4

"जो लोग अतीत को याद नहीं कर सकते हैं उन्हें दोहराने की निंदा की जाती है।"

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

int (*p)[10]; 

या

void (*signal(int x, void (*f)(int)))(int) 

एक साथ एक उपयोगिता (cdecl) जिसका उद्देश्य इस तरह के निरर्थक शब्दों को डिक्रिप्ट करने के लिए है के साथ के रूप में ऐसी सुंदरता है है।

पास्कल में, प्रकार चर के बाद आता है, तो पहले उदाहरण

q: array[10] of pointer to int 

जो, सी में साथ

p: pointer to array[10] of int 

कंट्रास्ट हो जाता है,

int *q[10] 

सी में है , आपको int (* p) [10] से अंतर करने के लिए कोष्ठक की आवश्यकता है। पास्कल में माता-पिता की आवश्यकता नहीं है, जहां केवल आदेश मायने रखता है।

संकेत समारोह

signal: function(x: int, f: function(int) to void) to (function(int) to void) 

फिर भी एक कौर हो सकता है, लेकिन कम से कम मानवीय समझ के दायरे के भीतर।

निष्पक्षता में, समस्या यह है कि सी नाम से पहले प्रकार डाल नहीं है, लेकिन है कि यह विकृत, के बाद से पहले बिट और टुकड़े डाल पर जोर देते हैं, और दूसरों के नाम।

int [10] a // an int, ahem, ten of them, called a 
int [10]* a // an int, no wait, ten, actually a pointer thereto, called a 

तो, जवाब है:: एक समझदारी से तैयार किया गया है प्रोग्रामिंग भाषा प्रकार से पहले चर डालता है क्योंकि परिणाम अधिक है

लेकिन अगर आप नाम से पहले सब कुछ डाल करने के लिए प्रयास करते हैं, आदेश अभी भी unintuitive है मनुष्यों के लिए पठनीय।

संबंधित मुद्दे