क्यों कुछ कंपाइलर्स पार्सर जनरेटर पर हाथ से तैयार पार्सर पसंद करते हैं?

Question

वाला प्रलेखन के अनुसार: "0.3.1 से पहले, वाला का पार्सर क्लासिक फ्लेक्स स्कैनर और बाइसन एलएएलआर पार्सर संयोजन था। लेकिन commit eba85a के रूप में, पार्सर एक हाथ से तैयार किए गए रिकर्सिव वंश पार्सर है।" मेरा सवाल है: क्यों?

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

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

Answer 1

एलआर (1) और LALR (1) पारसर्स सच में, सच दो कारणों के लिए कष्टप्रद हैं:

1. पार्सर जेनरेटर उपयोगी त्रुटि संदेश के उत्पादन पर बहुत अच्छा नहीं है।
2. कुछ प्रकार की अस्पष्टता, जैसे कि सी-स्टाइल अगर-अन्य ब्लॉक, व्याकरण को बहुत दर्दनाक लिखते हैं।

दूसरी तरफ, एलएल (1) व्याकरण इन दोनों चीजों में बहुत बेहतर है। एलएल (1) व्याकरण की संरचना उन्हें रिकर्सिव वंश पार्सर्स के रूप में एन्कोड करने में बहुत आसान बनाती है, और इसलिए एक पार्सर जेनरेटर से निपटना वास्तव में एक जीत नहीं है।

इसके अलावा, वाल्सा के मामले में, पार्सर और संकलक स्वयं लाइब्रेरी के रूप में प्रस्तुत किए गए हैं, इसलिए आप वाला कंपाइलर लाइब्रेरी का उपयोग करके वाला कंपाइलर के लिए कस्टम बैकएंड बना सकते हैं और सभी पार्सिंग और टाइपिंग जांच और ऐसे प्राप्त कर सकते हैं मुक्त करने के लिए।

Answer 2

वाला प्रलेखन के अनुसार: "। 0.3.1 से पहले, वाला के पार्सर क्लासिक फ्लेक्स स्कैनर और बाइसन LALR पार्सर संयोजन था लेकिन के रूप में eba85a कमिट, पार्सर एक हाथ से तैयार किए पुनरावर्ती वंश पार्सर है।" मेरा सवाल है: क्यों?

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

शायद प्रोग्रामर अनुकूलन कि पार्सर जेनरेटर स्थान नहीं था के लिए कुछ रास्ते देखा, और अनुकूलन के लिए इन रास्ते एक बिल्कुल अलग पार्स कलन विधि की आवश्यकता है। वैकल्पिक रूप से, शायद पार्सर जनरेटर ने सी 8 9 में कोड उत्पन्न किया, और प्रोग्रामर ने सी 99 या सी 11 के लिए रिफैक्टरिंग का निर्णय लिया, जो कि सुगमता में सुधार करेगा।

एक पक्ष के रूप में टिप्पणी: मैं वाला में रुचि रखते विशेष रूप से, क्योंकि मैं तरह कर रहा हूँ आधुनिक सुविधाओं और साफ वाक्यविन्यास लेकिन "मूल" और "अप्रबंधित" उच्च स्तरीय भाषा में compilable भाषा के साथ करने के विचार (सी वाल् के मामले में)।

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

मुझे अब तक वैला मिला है।मैं वाला (या इसी तरह की भाषा) को C++ (Qt libs द्वारा समर्थित) के लिए संकलित करके मजा करने की सोच रहा हूं। लेकिन के बाद से मैं पूरी तरह से नई भाषा का आविष्कार नहीं करना चाहता हूं, मैं कुछ मौजूदा व्याकरण लेने के बारे में सोच रहा हूं। जाहिर है हाथ से तैयार किए गए पार्सर्स में लिखित औपचारिक व्याकरण नहीं है जिसका मैं पुन: उपयोग कर सकता हूं। इस विचार पर आपकी टिप्पणियां स्वागत है (पूरा विचार मूर्खतापूर्ण है?)।

थोड़ा प्रयास के साथ सी ++ कोड का उत्पादन करने के लिए हाथ से तैयार किए गए पार्सर का उपयोग करना संभव हो सकता है, इसलिए मैं इस विकल्प को इतनी जल्दी नहीं फेंक दूंगा; पुराना फ्लेक्स/बाइसन पार्सर जेनरेटर अधिक उपयोगी हो सकता है या नहीं। हालांकि, यह आपका एकमात्र विकल्प नहीं है। किसी भी मामले में, मैं the specification बड़े पैमाने पर अध्ययन करने का लुत्फ उठाऊंगा।

Answer 3

यह उत्सुक है कि ये लेखक बाइसन से आरडी तक गए थे। ज्यादातर लोग विपरीत दिशा में जाएंगे।

वैला लेखकों ने जो किया वह करने के लिए एकमात्र वास्तविक कारण बेहतर त्रुटि पुनर्प्राप्ति होगी, या शायद उनका व्याकरण बहुत साफ नहीं है।

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

Answer 4

मैं जानता हूँ कि यह निश्चित होना करने के लिए नहीं जा रहा है, और मैं परेशान नहीं होता अगर आपके प्रश्नों का विशेष रूप से वाला से संबंधित नहीं थे, लेकिन जब से वे कर रहे हैं ...

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

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

बेहतर त्रुटि रिपोर्टिंग भी एक लक्ष्य था, आईआईआरसी।

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

एक पक्ष के रूप में टिप्पणी: मैं वाला में रुचि रखते विशेष रूप से, क्योंकि मैं आधुनिक सुविधाओं और साफ वाक्यविन्यास लेकिन मामले में "देशी" और "अप्रबंधित" उच्च स्तर की भाषा (सी में compilable भाषा के साथ करने का विचार पसंद कर रहा हूँ वाला का)। मुझे अभी तक केवल वैला मिला है। मैं वाला (या इसी तरह की भाषा) को C++ (Qt libs द्वारा समर्थित) के लिए संकलित करके मजा करने की सोच रहा हूं। लेकिन चूंकि मैं पूरी तरह से नई भाषा का आविष्कार नहीं करना चाहता हूं, इसलिए मैं कुछ मौजूदा व्याकरण लेने की सोच रहा हूं। जाहिर है हाथ से तैयार किए गए पार्सर्स ने औपचारिक व्याकरण नहीं लिखा है जिसका मैं पुन: उपयोग कर सकता हूं। इस विचार पर आपकी टिप्पणियां आपका स्वागत है (क्या पूरा विचार मूर्खतापूर्ण है?)।

बहुत सारे वैला वास्तव में गोब्जेक्ट द्वारा किए गए निर्णयों का प्रतिबिंब है, और चीजें सी ++/क्यूटी में समान तरीके से काम कर सकती हैं या नहीं भी हो सकती हैं। यदि आपका लक्ष्य Qt/C++ के साथ वैलैक में गोब्जेक्ट/सी को प्रतिस्थापित करना है, तो संभवतः आप अपेक्षा से अधिक काम के लिए हैं। यदि, हालांकि, आप केवल सीए ++ और क्यूटी पुस्तकालयों को वाला से सुलभ बनाना चाहते हैं, जो निश्चित रूप से संभव होना चाहिए। वास्तव में, लुका ब्रूनो ने एक साल पहले उस पर काम करना शुरू किया (wip/cpp शाखा देखें)। तकनीकी समय पर नहीं, समय की कमी के कारण इसमें कुछ समय तक गतिविधि नहीं देखी गई है।

Answer 5

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

यहां प्रत्येक दृष्टिकोण के लिए कुछ पेशेवर और विपक्ष हैं।

पार्सर जनरेटर

सकारात्मक:

• जल्दी एक काम पार्सर मिल (कम से कम आप कैसे करने के लिए हाथ यह कोड नहीं जानते हैं)।

विपक्ष:

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

हाथ से गढ़ी गई पुनरावर्ती वंश पार्सर

सकारात्मक:

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

विपक्ष:

• यह हाथ कोड पार्सर के लिए कुछ समय लगेगा खासकर यदि आप इस सामग्री के साथ एक अनुभव नहीं है।

• पार्सर कुछ हद तक धीमा हो सकता है। यह सभी रिकर्सिव पार्सर्स पर लागू होता है न केवल हाथ से लिखे गए हैं। एक साधारण संख्यात्मक शाब्दिक पार्सल को पार्स करने के लिए प्रत्येक भाषा के अनुरूप एक फ़ंक्शन होने के कारण पार्सर एक दर्जन या अधिक नेस्टेड कॉल उदा। parseExpression parseAddition, parseMultiplication, आदि parseLiteral के माध्यम से। फंक्शन कॉल सी जैसी भाषा में अपेक्षाकृत सस्ती हैं लेकिन अभी भी एक महत्वपूर्ण समय तक कैम का योग है। एक पुनरावर्ती पार्सर speedup करने

एक समाधान एक बॉटम-अप उप पार्सर जो अक्सर बहुत तेजी से है के आधार पर आपके पुनरावर्ती पार्सर के कुछ हिस्सों को बदलने के लिए है। ऐसे उप-पार्सर के लिए प्राकृतिक उम्मीदवार अभिव्यक्तियां हैं जिनमें कई प्राथमिकता स्तरों के साथ लगभग समान वाक्यविन्यास (यानी बाइनरी और यूनरी अभिव्यक्तियां) हैं। एक अभिव्यक्ति के लिए निचला-अप पार्सर आमतौर पर हाथ कोड के लिए भी आसान होता है, यह आमतौर पर लेजर से इनपुट टोकन प्राप्त करने वाला एक लूप होता है, मूल्यों का ढेर और ऑपरेटर टोकन के लिए ऑपरेटर प्राथमिकता की लुकअप तालिका होती है।