गूगल की नई भाषा "गो" on its website का कहना है:गो में कोई प्रतीक तालिका नहीं है?
भाषा का विश्लेषण करने के लिए आसान करने के लिए डिज़ाइन किया गया है और एक प्रतीक तालिका
मैं निश्चित रूप से इन मामलों पर कोई विशेषज्ञ हूँ बिना पार्स किया जा सकता , लेकिन मैंने सोचा कि एक प्रतीक तालिका उन सभी भाषाओं के लिए सभी कंपाइलरों के लिए एक सामान्य संरचना थी जो चर का उपयोग करती हैं, और जाओ स्पष्ट रूप से चर का उपयोग करती है। मुझे क्या समझ में नहीं आ रहा है?
पार्सिंग का अर्थ केवल प्रोग्राम संरचना को समझना है: मॉड्यूल को बयान/घोषणाओं में विभाजित करना, उप-अभिव्यक्तियों को अभिव्यक्तियों को तोड़ना आदि। आप एक पेड़ संरचना के साथ समाप्त होते हैं, जिसे "पार्स पेड़" या "सार" के नाम से जाना जाता है। वाक्यविन्यास पेड़ "(एएसटी)।
स्पष्ट रूप से, सी ++ को पार्सिंग करने के लिए एक प्रतीक तालिका की आवश्यकता होती है।
यह पृष्ठ why C++ requires a symbol table for parsing के कुछ कारणों पर चर्चा करता है।
बेशक, पार्सिंग केवल संकलन का एक हिस्सा है, और आपको पूर्ण संकलन करने के लिए एक प्रतीक तालिका की आवश्यकता होगी।
हालांकि, खुद को पार्सिंग विश्लेषण उपकरण लिखने में उपयोगी हो सकता है (उदाहरण के लिए कौन सा मॉड्यूल आयात करता है जो मॉड्यूल)। इसलिए, पार्सिंग प्रक्रिया को सरल बनाना मतलब है कि कोड विश्लेषण टूल लिखना आसान है।
व्याख्या और संकलन बिल्कुल प्रतीक तालिकाओं या इसी तरह की आवश्यकता है। यह लगभग सभी भाषाओं के लिए सच है।
सी और सी ++ में, पार्सिंग भाषा को एक प्रतीक तालिका की आवश्यकता होती है।
यही मैंने सोचा था। फिर उनका दावा कैसे सच हो सकता है? मुझे लगता है कि यह होना चाहिए लेकिन मुझे समझ में नहीं आता कि कैसे। – Dinah
@ दीनाह: धीरे-धीरे कथन पढ़ें, फिर इस उत्तर को फिर से पढ़ें। वे विरोधाभासी नहीं हैं। –
@ दीनाः पार्सिंग की तुलना में संकलन के लिए और भी कुछ है। पार्सिंग कार्यक्रम की संरचना का वृक्ष प्रतिनिधित्व बनाता है।अर्द्धिक विश्लेषण और कोड पीढ़ी तब संकलित आउटपुट का उत्पादन करने के लिए उस पेड़ पर काम करती है। – quark
@ जस्टिस सही है। उस पर थोड़ा विस्तार करने के लिए, सी में केवल वास्तविक मुश्किल हिस्सा चर से अलग प्रकार बता रहा है। विशेष रूप से आप यह देख जब:
T t;
आप जानना चाहते हैं कि T एक प्रकार है कि एक कानूनी पार्स होने के लिए है की जरूरत है। ऐसा कुछ है जो आपको प्रतीक तालिका में देखना है। जब तक पार्स जारी रहता है तब तक प्रतीक तालिका में टाइप जोड़े जाने के लिए यह अपेक्षाकृत सरल है। आपको कंपाइलर में बहुत अधिक काम करने की आवश्यकता नहीं है: या तो T तालिका में मौजूद है या यह नहीं है।
सी ++ चीजों में बहुत अधिक हैं, अधिक अधिक जटिल। संदिग्ध या संभावित संदिग्ध संरचनाओं की भारी संख्याएं हैं। सबसे स्पष्ट यह एक है:
B::C (c);
तथ्य यह है कि यह स्पष्ट नहीं है अगर B एक class, एक typedef, या एक namespace है के अलावा, यह भी स्पष्ट नहीं है अगर C एक प्रकार और c कि की एक वस्तु है टाइप करें, या C एक फ़ंक्शन (या कन्स्ट्रक्टर) c को तर्क के रूप में ले रहा है (या यहां तक कि यदि सी operator() ओवरलोडेड वाला ऑब्जेक्ट है)। पार्सिंग को चलाने के लिए आपको प्रतीक तालिका की आवश्यकता है, हालांकि प्रतीक के प्रकार प्रतीक तालिका में है, क्योंकि यह अभी भी पर्याप्त रूप से जारी रखना संभव है।
चीजें मिश्रण में आने पर उससे ज्यादा, बहुत खराब होती हैं। यदि C (c) टेम्पलेट में है, तो हो सकता है कि आप टेम्पलेट की वास्तविक परिभाषा में नहीं जानते हैं, यदि सी एक प्रकार या फ़ंक्शन/ऑब्जेक्ट है।ऐसा इसलिए है क्योंकि टेम्पलेट Cया तो एक प्रकार या एक चर घोषित कर सकता है। इसका अर्थ यह है कि आपको प्रतीक तालिका की आवश्यकता है, लेकिन आप एक नहीं हैं - और नहीं हो सकता है जब तक कि टेम्पलेट वास्तव में घोषित नहीं किया जाता है। इससे भी बदतर, यह केवल प्रतीक के प्रकार के लिए पर्याप्त नहीं है: आप उन परिस्थितियों के साथ आ सकते हैं जिनके प्रतीक के आकार, संरेखण, और अन्य मशीन-विशिष्ट जानकारी सहित प्रतीक की पूर्ण जानकारी की आवश्यकता होती है।
इन सभी के कई व्यावहारिक प्रभाव हैं। मैं सबसे महत्वपूर्ण कहूंगा कि:
अधिकांश भाषाओं को पार्स करने के लिए आपको कुछ संरचनाओं को अलग करने के लिए चर, प्रकार या फ़ंक्शंस होने पर जानने की आवश्यकता है। जाओ ऐसी कोई संदिग्ध संरचना नहीं है।
उदाहरण के लिए:
int x = foo (bar);
फू एक प्रकार या एक कार्य हो सकता है और वे विभिन्न एएसटी प्रकारों द्वारा प्रतिनिधित्व किए जाते हैं। असल में पार्सर को कभी भी एएसटी बनाने के तरीके के बारे में जानने के लिए प्रतीकों पर लुकअप करना पड़ता है। व्याकरण और एएसटी अधिकांश भाषाओं की तुलना में बस सरल है। वास्तव में बहुत अच्छा है।
प्रतीक तालिका धीमी होती है और आम तौर पर इसकी आवश्यकता नहीं होती है। तो इसके साथ जाने का चयन करें। अन्य कार्यात्मक भाषाओं को भी किसी की आवश्यकता नहीं है। फास्ट लुकअप के लिए हैश की आवश्यकता होती है, लेकिन नेस्टेड स्कॉप्स का समर्थन करने के लिए आपको स्टैक पर पुश/पॉप नामों की आवश्यकता होती है। सरल symtabs रैखिक खोजी स्टैक के रूप में कार्यान्वित किए जाते हैं, बेहतर symtabs हैश के रूप में एक स्टैक प्रति प्रतीक के साथ। लेकिन फिर भी, रन-टाइम पर खोज करना है।
व्याख्यात्मक रूप से स्कॉम्ड भाषाओं के लिए व्याख्या और संकलन बिल्कुल कोई प्रतीक सारणी या समान की आवश्यकता नहीं है। केवल गतिशील रूप से स्कॉप्ड प्रतीकों को प्रतीकात्मक तालिकाओं की आवश्यकता होती है, और कड़ाई से टाइप की गई भाषाओं वाले कुछ कंपाइलरों को प्रकार की टिप्पणियां रखने के लिए किसी प्रकार की आंतरिक प्रतीक तालिका की आवश्यकता होती है।
सी और सी ++ में, भाषा को पार्स करने के लिए भी एक प्रतीक तालिका की आवश्यकता होती है, क्योंकि आपको ग्लोबल्स और कार्यों के प्रकारों और घोषणाओं को स्टोर करने की आवश्यकता होती है।
लेक्सिकली स्कॉप्ड प्रतीकों को symtab में संग्रहीत नहीं किया जाता है, लेकिन कार्यात्मक भाषाओं में ब्लॉक फ्रेम में नामों की अनुक्रमित सूची के रूप में। उन सूचकांक संकलित समय पर गणना की जाती है। तो रन-टाइम एक्सेस तत्काल है। दायरे को छोड़कर उन वर्रों को स्वचालित रूप से अप्राप्य बनाता है, इसलिए आपको नेमस्पेस/symtabs से पुश/पॉप नामों की आवश्यकता नहीं है।
प्रथम श्रेणी के कार्यों के बिना इतनी कार्यात्मक भाषाओं को अक्सर अपने फ़ंक्शन नामों को प्रतीक तालिकाओं में संग्रहीत करने की आवश्यकता नहीं होती है। भाषा डिजाइनर के रूप में आप symtabs में गतिशील नाम लुकअप से छुटकारा पाने में सक्षम होने के बजाय, लेक्सिकल के कार्यों को बाध्य करने का प्रयास करते हैं।
यह एक उत्कृष्ट संदर्भ है। –
ईमानदारी से, यह Google – hasen
से पहला (या दूसरा) परिणाम था, उस पोस्ट के उत्तरों को भी ध्यान दें - उनमें भी बहुत अच्छे कारण हैं कि यह असंभव क्यों है। – MSalters