पार्स पेड़ में लाना नोड्स जो वहाँ

Question

मैं एक भाषा के लिए एक पार्सर लिख रहा हूँ, और स्कैनर

1. लिए बनाया गया है या तो भी अनावश्यक टर्मिनलों वापसी (जैसे whitespacing) या
2. नहीं नहीं होना चाहिए ऐसा करने के लिए

एक बूलियन ध्वज के आधार पर।

अब, पार्सर में, मैं उन सभी टर्मिनलों के साथ व्याकरण को अव्यवस्थित नहीं करना चाहता हूं, उन्हें किसी भी तरह से पार्स पेड़ द्वारा "स्वचालित रूप से" निगल जाना चाहिए जिसे मैं बना रहा हूं।

यह "जादू" करने के लिए, मैंने सोचा कि मैं टर्मिनल (बस सर्कुलर सूची से जुड़ा हुआ) श्रृंखला दूंगा ताकि मैं उन्हें फिर से सक्रिय कर सकूं और "रिक्त स्थान भरें" क्योंकि कमी होती है (मैं एलएएलआर (1 का उपयोग कर रहा हूं)) पार्सर जेनरेटर)।

यह एक गंभीर विचार की तरह लगता है, हालांकि एक समस्या है। याद रखें मैंने कहा "या तो लौटने के लिए ... या नहीं"? परिदृश्य में (2), मैं टर्मिनल को मुक्त कर दूंगा, क्योंकि कौन जानता है कि अगला क्या आता है? और मुझे कोई स्मृति रिसाव नहीं चाहिए।

लेकिन परिदृश्य में (1), मैं टर्मिनल को मुक्त नहीं कर सकता, क्योंकि उनके आधार पर मैं आगे की कमी में निर्णय लेगा जहां "रिक्त स्थान भरें" प्रक्रिया को रोकना चाहिए।

मैं इसे सशर्त रूप से मुक्त नहीं कर सकता, क्योंकि इसी कारण से: मुझे नहीं पता कि अगला क्या आता है। क्या होगा यदि कोई "भरने में रिक्त स्थान" नहीं होगा -प्रोसेस ट्रिगर किया गया है? क्या होगा यदि कोई और कमी नहीं होगी?

क्या आपको समान समस्याएं हैं? आपने इसे कैसे हल किया है?

नोट: यह सब मेरे दिमाग में है और मैंने इसे स्पष्ट रूप से पर्याप्त समझाया नहीं है, कृपया पूछें और मैं अपना प्रश्न संपादित करूंगा। परिदृश्य वास्तव में थोड़ा अधिक जटिल है, मैं इसे स्क्रैच से नहीं लिख रहा हूं, जहां मैं अपनी कल्पना का उपयोग कर सकता हूं, मैं इसे किसी अन्य चीज़ में एकीकृत कर रहा हूं, इसलिए यह हो सकता है कि मैं जवाब दूंगा "मैं ऐसा नहीं कर सकता पर्यावरण की बाधाओं के कारण "।

---

परिशिष्ट

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

Answer 1

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

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

यदि आप एक कंपाइलर या दुभाषिया बना रहे हैं, तो व्हाइटस्पेस को अनदेखा करना सबसे आसान है।

आप एक फिर से इंजीनियरिंग पार्सर का निर्माण कर रहे हैं (देखें हमारे DMS Software Reengineering Toolkit, तो टिप्पणियां (कम से कम) एएसटी में, महत्वपूर्ण है क्योंकि अंततः एक consturcted ASTs से पाठ को पुनर्जीवित करना चाहते हैं, और अगर पुनर्जीवित यह उपयोगी है पर कब्जा पाठ में भी टिप्पणियां हैं। [आप यह अन्य तरीकों से कर सकते हैं लेकिन वे उतना आसान नहीं हैं]

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

अब, लोग अक्सर "सार" वाक्यविन्यास पेड़ चाहते हैं; वे "(" और ")" जैसी चीज़ों को छोड़ना चाहते हैं। जिस योजना का मैंने उपरोक्त टिप्पणियों के ऊपर इन ठोस कंक्रीट तक टिप्पणी की है। अब एक जटिलता है: यदि आप पेड़ से (..) टोकन छोड़ देते हैं, तो संलग्न टिप्पणियां गायब हो जाती हैं। उफ़। तो डीएमएस पार्सर्स एक जटिल चीज करते हैं: पेड़ में तार्किक स्थान वाले टोकन से जुड़ी टिप्पणियां, लेकिन वास्तव में वहां नहीं हैं ("समाप्त टर्मिनल") माता-पिता के पेड़ नोड को एनोटेशन के साथ उठाए जाते हैं और कहा जाता है कि वे लापता बच्चे टोकन पर हैं । हां, इसे लागू करना वास्तव में एक पिटा है। अच्छी खबर यह है कि हमें केवल डीएमएस की सामान्य पार्सिंग मशीनरी में इसे एक बार करना था, और यह कई, कई भाषाओं के लिए काम करता है। लेकिन इसका मतलब है कि आपको असामान्य ("पुनर्वितरण") पार्सर बनाने के लिए तैयार रहना होगा, और हमारे पास ऐसा करने के लिए व्यावसायिक प्रेरणा थी।

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

EDIT2: यदि ओपी व्हाइटस्पेस को कैप्चर करने पर जोर देती है, तो वह scannerless GLR parsing की खोज करने पर विचार कर सकता है। यह व्हाइटस्पेस समेत इनपुट स्ट्रीम में प्रत्येक वर्ण रखता है।