👡 🎹 🤽🏿 एसक्यूएल को लागू करना। भाग 1. पार्सिंग की जटिलता। ANTLR फ़ाइल को अंतिम रूप देने के बारे में कहानियां 🤳🏼 👨🏻 ◀️

मैं हेबर पर मूल लेख प्रकाशित करता हूं, जिसका अनुवाद कोडिंगसाइट ब्लॉग पर पोस्ट किया गया है ।

इस लेख में क्या होगा?

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

जैसा कि मैं प्रकाशित करता हूं, मैं निम्नलिखित भागों के लिंक जोड़ूंगा:

भाग 1। पार्सिंग की जटिलता। एएनटीएलआर को फाइल
पार्ट के साथ अंतिम रूप देने के बारे में कहानियां 2. स्ट्रिंग्स के साथ काम करने और फाइलों को खोलने का अनुकूलन
भाग 3. विजुअल स्टूडियो के लिए एक्सटेंशन का जीवन। आईओ के साथ काम करते हैं। एसक्यूएल
पार्ट का असामान्य उपयोग 4. अपवादों के साथ काम करना, विकास प्रक्रिया पर डेटा का प्रभाव। ML.NET का उपयोग करना

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

इस भाग में, मैं पार्सिंग SQL की समस्याओं, इन समस्याओं के खिलाफ लड़ाई और इस लड़ाई में की गई गलतियों पर ध्यान केंद्रित करूँगा।

उन लोगों के लिए जो केवल और केवल आसान नेविगेशन के लिए भाग लेते हैं, लेख की सामग्री:

सामग्री

मैं कौन हूँ?

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

किसी तरह यह पता चला कि खेलों के अलावा, मुझे अपने या अन्य डेवलपर्स के लिए अलग ट्यूनिंग बनाने के लिए भी तैयार किया गया था। कभी-कभी, वह काम करने के करीब था जो मुझे थोड़ी देर बाद करना था। उदाहरण के लिए, Win32 API का अध्ययन करते समय मैंने जो प्रोजेक्ट किया था, उनमें से एक रिच एडिट कंट्रोल में XML कोड को उजागर करने वाला प्रोग्राम था। इसके अलावा, BMP, HTML या BB कोड्स के लिए बैकलिट कोड अपलोड करना संभव था जो कि विभिन्न मंचों पर फैशनेबल थे।

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

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

कठिनाइयाँ क्या हैं?

पाठक को वास्तव में हम क्या कर रहे हैं, इस संदर्भ में विसर्जित करने के लिए इस ब्लॉक की आवश्यकता है।

डेस्कटॉप का विकास

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

पार्सिंग SQL और बोलियाँ

मैंने इस काम से पहले अलग-अलग भाषाओं के लिए छोटे पार्सर्स भी लिखे हैं। कुछ समय के लिए मैंने .NET पाठ्यक्रम पढ़ाया। कुछ समूहों के लिए, "स्ट्रिंग" विषय के हिस्से के रूप में एक अतिरिक्त कार्य के रूप में, उन्होंने अपने स्वयं के सरल JSON पार्सर लिखने का सुझाव दिया। केवल SQL और उसके वेरिएंट XML या JSON से बहुत दूर हैं, जो पार्सर्स और लोगों के लिए समान रूप से समझने योग्य हैं। इसके अलावा, SQL सी / सी ++ की तुलना में अधिक जटिल है, इसके कई कार्य लंबे इतिहास में संचित हैं। एसक्यूएल को अलग तरीके से संरचित किया जाता है, उन्होंने इसे एक प्राकृतिक भाषा की तरह बनाने की कोशिश की, काफी सफलतापूर्वक, वैसे। भाषा में कई हजार (बोली के आधार पर) कीवर्ड हैं। अक्सर, एक अभिव्यक्ति को दूसरे से अलग करने के लिए, आपको दो या अधिक शब्दों (टोकन) को आगे की ओर खींचने की आवश्यकता होती है। इस दृष्टिकोण को लुकहेड कहा जाता है। के अनुसार पार्सर का वर्गीकरण हैवे कितनी दूर तक आगे बढ़ सकते हैं: एलए (1), एलए (2), या एलए (*), जिसका अर्थ है कि पार्सर सही शाखा को निर्धारित करने के लिए आगे ले जा सकता है। कभी-कभी एक एसक्यूएल स्टेटमेंट के अंदर एक क्लॉज का वैकल्पिक अंत दूसरे की शुरुआत के साथ मेल खाता है, जो वैकल्पिक भी है: ऐसी स्थितियों से पार्सर बहुत अधिक जटिल हो जाते हैं। T-SQL आग में पानी डालता है, जिसमें अर्धविराम वैकल्पिक है, और संभव है, लेकिन कुछ SQL कथनों का अनिवार्य समापन दूसरों की शुरुआत के साथ संघर्ष नहीं कर सकता है।ऐसी स्थितियां पार्सर्स को बहुत परेशान करती हैं। T-SQL आग में पानी डालता है, जिसमें अर्धविराम वैकल्पिक है, और संभव है, लेकिन कुछ SQL कथनों का अनिवार्य समापन दूसरों की शुरुआत के साथ संघर्ष नहीं कर सकता है।ऐसी स्थितियां पार्सर्स को बहुत परेशान करती हैं। T-SQL आग में पानी डालता है, जिसमें अर्धविराम वैकल्पिक है, और संभव है, लेकिन कुछ SQL कथनों का अनिवार्य समापन दूसरों की शुरुआत के साथ संघर्ष नहीं कर सकता है।

फिर भी विश्वास नहीं हो रहा है? व्याकरण के माध्यम से औपचारिक भाषाओं का वर्णन करने के लिए एक तंत्र है । व्याकरण एक भाषा में एक कोड है जो दूसरे का वर्णन करता है। एक व्याकरण से, आप अक्सर एक टूल का उपयोग करके पार्सर उत्पन्न कर सकते हैं। सबसे प्रसिद्ध व्याकरण विवरण उपकरण और भाषाएं YACC और ANTLR हैं । YACC उत्पन्न पार्सर सीधे MySQL , MariaDB , PostgreSQL इंजन में उपयोग किए जाते हैं। आप उन्हें खुले स्रोत से सीधे लेने और कोड के पूरा होने और उनके आधार पर SQL विश्लेषण के आधार पर अन्य कार्यों को विकसित करने का प्रयास कर सकते हैं। इसके अलावा, इस तरह के कार्यान्वयन से विकास के संदर्भ में मुफ्त अपडेट प्राप्त होगा, और पार्सर डेटाबेस इंजन के समान होने की गारंटी देगा। तो हम ANTLR का उपयोग क्यों करते हैं? यह गुणात्मक रूप से C # /। NET का समर्थन करता है, इसके साथ काम करने के लिए अच्छे उपकरण हैं, इसका सिंटैक्स पढ़ना और लिखना बहुत आसान है। ANTLR सिंटैक्स इतना सुविधाजनक निकला कि हाल ही में microsoft ने आधिकारिक C # प्रलेखन में इसका उपयोग किया है ।

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

नीचे विभिन्न भाषाओं के व्याकरण के आकार दिए गए हैं:

JS - 475 लाइनें parser + 273 lexer = 748 लाइनें
Java - 615 लाइनें parser + 211 lexer = 826 लाइनें
C # - 1159 लाइनें parser + 433 pxer = 1592 लाइनें
C ++ - 1933 लाइनें

MySQL- 2515 लाइनें parser + 1189 lexer = 3704 पंक्तियाँ
T-SQL - 4035 पंक्तियाँ parser + 896 lexer = 4931 पंक्तियाँ
PL SQL - 6719 पंक्तियाँ parser + 2366 lexer = 9085 पंक्तियाँ

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

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

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

युद्धों को समर्पित करें

कोड को पार्स करते समय, कभी-कभी ऐसे हालात होते हैं जब अगला शब्द यह स्पष्ट नहीं करता है कि दोनों विकल्पों में से किसे चुनना है। कभी-कभी अग्रिम में कड़ाई से परिभाषित संख्या में झांकना पर्याप्त होता है और आप निश्चित रूप से एक विकल्प चुन सकते हैं। इस तरह की अशुद्धि को हल करने के तंत्र को ANTLR लुकहेड कहा जाता है। इस मामले में पारसर विधि का निर्माण ifs की एक अंतर्निहित श्रृंखला के रूप में किया गया है, जिनमें से प्रत्येक आगे एक शब्द दिखता है। नीचे इस तरह की अनिश्चितता पैदा करने वाले व्याकरण का एक उदाहरण है।

rule1:
    'a' rule2 | rule3
    ;

rule2:
    'b' 'c' 'd'
    ;

rule3:
    'b' 'c' 'e'
    ;

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

अधिक जटिल अनिश्चितताओं को हल करने के लिए अधिक जटिल तंत्र मौजूद हैं। उनमें से एक ANTLR3 में वाक्यविन्यास विधेय तंत्र (synpred) है।

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

एक सरल उदाहरण पर विचार करें। अनिश्चितता के 3 बिंदु हैं (ए, बी, सी)।

पार्सर ए में प्रवेश करता है, पाठ में स्थिति को याद करता है, 1 स्तर का एक आभासी मार्ग शुरू करता है।
B, , 2- .
C, , 3- .
3- , 2 .
2 , 1 B .
, A, B .

इस प्रकार, C के अंदर सभी चेक 4 बार, B - 3 बार, A - 2 बार किए जाएंगे। लेकिन क्या होगा अगर सूची में उपयुक्त विकल्प दूसरा या तीसरा हो? फिर किसी एक विधेय के किसी चरण में यह विफल हो जाएगा, पाठ में स्थिति वापस आ जाएगी और एक अन्य विधेय निष्पादित करना शुरू कर देगा।

बार-बार एप्लिकेशन फ्रीजिंग के कारण का विश्लेषण करते हुए, हम ऐसे मामलों में सामने आए जब सिंक किए गए "पूंछ" को कई हजार बार निष्पादित किया गया था। पुनरावर्ती नियमों में Synpreds विशेष रूप से समस्याग्रस्त हैं। दुर्भाग्य से, इसकी प्रकृति से, एसक्यूएल पुनरावर्ती है, जो लगभग हर जगह एक उप-वर्ग का उपयोग करने की क्षमता है। कभी-कभी विभिन्न चाल और चाल की मदद से यह नियम को बाहर करने के लिए निकलता है ताकि विधेय चला जाए।

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

दुर्लभ मामलों में, हमने C # में अपनी खुद की भविष्यवाणी लिखी है कि जो ANTLR जेनरेट करता है उसके आसपास हो। सौभाग्य से, ऐसा तंत्र भी मौजूद है।

शांत बाइक समाधान

व्याकरण का अनुगमन

हम DBMS में से प्रत्येक में किसी भी परिवर्तन की घोषणा के बाद, उनका समर्थन करने के लिए हमारा काम शुरू होता है। लगभग हमेशा, इसके लिए प्रारंभिक बिंदु व्याकरण में वाक्य रचना का समर्थन करना है। प्रत्येक SQL बोली के लिए, हम अपने स्वयं के व्याकरण लिखते हैं, इससे कोड की कुछ पुनरावृत्ति उत्पन्न होती है, लेकिन अंततः उनके बीच एक आम की तलाश करना आसान होता है। कुछ साल पहले, MySQL और MariaDB बहुत समान थे, अलग-अलग व्याकरण लिखना अव्यावहारिक था। क्योंकि जो कुछ निर्माण मारियाडीबी में थे, लेकिन MySQL में नहीं थे, हमने MySQL व्याकरण में समर्थन किया। यह एक अप्रिय क्षण था: MySQL उपयोगकर्ता के लिए, हम ऐसे निर्माणों का सुझाव दे सकते हैं जो मान्य नहीं होंगे। हाल के वर्षों में, सिंटैक्स और अधिक के मामले में मारियाडीबी और मायक्यूसी बहुत ही अलग हो गए हैं। यह स्पष्ट हो गयाएक ही व्याकरण के भीतर दो अलग-अलग भाषाओं का समर्थन करना गलत है।

एक संभावित समाधान व्याकरण की एक पूरी प्रति हो सकती है, जिसके बाद प्रत्येक को अलग से समर्थन दिया जाता है। एक लंबी चर्चा के परिणामस्वरूप, हमने एक साहसिक निर्णय लिया। मुझे बहुत खुशी है कि हमने कोड की नकल नहीं की, मेरे हर सेल ने इस फैसले का विरोध किया। अपने स्वयं के व्याकरण पूर्वप्रक्रमक ANTLR को लिखने का निर्णय लिया गया, जो व्याकरण विरासत के तंत्र को लागू करता है। कुछ समय पहले, मैं ANTLR4 व्याकरण के आधिकारिक भंडार में एक ANTLR3 व्याकरण भर में आया था। मुझे लगता है कि पागलपन की गहराई का एहसास करने के लिए इस वाक्य को कई बार पढ़ा जाना चाहिए।

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

ANTLR ट्यूनिंग द्वारा विकास के लिए एक सुखद उपकरण बनाता है - VS के लिए एक विस्तार है, ANTLRWorks हैं। विरासत तंत्र का परिचय देते हुए, मैं इस अवसर को खोना नहीं चाहूंगा। लेकिन फिर मूल व्याकरण को कैसे इंगित किया जाए? आप फ़ाइलों के नामकरण के लिए किसी प्रकार के सम्मेलन के साथ आ सकते हैं, लेकिन यह बिल्कुल स्पष्ट नहीं है। एक अन्य विकल्प एक अलग फ़ाइल में ऐसी अतिरिक्त जानकारी को इंगित करने के लिए हो सकता है, लेकिन अब भी, इन पंक्तियों को टाइप करते हुए, मुझे इस समाधान की बदबू महसूस हुई। आउटपुट ANTLR टिप्पणी के प्रारूप में उत्तराधिकारी के व्याकरण में मूल व्याकरण का एक संकेत था। सभी उपकरण बस इस पाठ को अनदेखा कर देंगे, और हम आसानी से उस कोड को निकाल सकते हैं जो हमें रुचता है।

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

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

एक और पोस्ट-प्रोसेसिंग ANTLR

कई प्रोग्रामिंग भाषाओं में, यदि शब्द कुंजी है, तो इसे अब ऑब्जेक्ट के नाम के रूप में उपयोग नहीं किया जा सकता है। SQL में, बोली के आधार पर, 800 से 3000 कीवर्ड तक। उनमें से अधिकांश विषय क्षेत्र से निकटता से संबंधित हैं, इसके अलावा, सभी को तुरंत पेश नहीं किया गया था, इसलिए उन सभी को ऑब्जेक्ट नाम के रूप में उपयोग करने पर प्रतिबंध से आक्रोश की एक भड़क के साथ मुलाकात होगी। SQL आरक्षित और गैर-आरक्षित कीवर्ड की अवधारणा का परिचय देता है। आप किसी वस्तु को आरक्षित खोजशब्द (SELECT, FROM etc) के रूप में उसी रूप में नाम नहीं दे सकते, जिसे उद्धृत किए बिना वह निरर्थक नहीं है (CONVERSATION, AVAILABILITY etc) - आप कर सकते हैं। यह व्यवहार पार्सर के विकास को जटिल बनाता है। लेक्सिकल विश्लेषण के समय, संदर्भ अज्ञात है, लेकिन पार्सर को पहचानकर्ता और कीवर्ड के लिए अलग-अलग संख्याओं की आवश्यकता होती है। इस समस्या को हल करने के लिए, हमने ANTLR पार्सर में एक और पोस्टप्रोसेसिंग जोड़ा।पोस्टप्रोसेसिंग एक विशेष विधि के लिए एक कॉल के साथ, एक पहचानकर्ता के साथ सभी स्पष्ट जांच की जगह लेती है। यह विधि एक पेचीदा जाँच को लागू करती है। यदि एक पहचानकर्ता इनपुट है और एक पहचानकर्ता से आगे की उम्मीद की जाती है, तो सब कुछ ठीक है, लेकिन अगर एक अनियंत्रित कीवर्ड को इनपुट के लिए आपूर्ति की जाती है, तो इसे अतिरिक्त रूप से जांचना होगा। एक अतिरिक्त जांच यह है कि शाखाओं की खोज में वर्तमान संदर्भ में इस पद्धति की जांच की जाती है, जहां इस अनारक्षित कीवर्ड का उपयोग कीवर्ड के रूप में सटीक रूप से किया जा सकता है, और यदि ऐसी कोई शाखाएं नहीं हैं, तो इसका उपयोग पहचानकर्ता के रूप में किया जा सकता है।लेकिन अगर कोई अनारक्षित कीवर्ड इनपुट है, तो इसे अतिरिक्त रूप से जांचना होगा। एक अतिरिक्त जांच यह है कि शाखाओं की खोज में वर्तमान संदर्भ में इस पद्धति की जांच की जाती है, जहां इस अनारक्षित कीवर्ड का उपयोग कीवर्ड के रूप में सटीक रूप से किया जा सकता है, और यदि ऐसी कोई शाखाएं नहीं हैं, तो इसका उपयोग पहचानकर्ता के रूप में किया जा सकता है।लेकिन अगर कोई अनारक्षित कीवर्ड इनपुट है, तो इसे अतिरिक्त रूप से जांचना होगा। एक अतिरिक्त जांच यह है कि शाखाओं की खोज में वर्तमान संदर्भ में इस पद्धति की जांच की जाती है, जहां इस अनारक्षित कीवर्ड का उपयोग कीवर्ड के रूप में सटीक रूप से किया जा सकता है, और यदि ऐसी कोई शाखाएं नहीं हैं, तो इसका उपयोग पहचानकर्ता के रूप में किया जा सकता है।

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

गलतियां

ट्रेलेस पार्सिंग

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

संपादक में पार्स पाठ। वाक्यविन्यास वृक्ष प्राप्त करें।
गाड़ी के नीचे गाँठ का पता लगाएं। इसे व्याकरण से मिलाएं। पता लगाएं कि कीवर्ड और प्रकार की वस्तुएं किस बिंदु पर उपलब्ध होंगी।

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

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

लेकिन सब कुछ उतना स्पष्ट नहीं है जितना यह लग सकता है। तथ्य यह है कि ANTLR4 ANTLR4 की तुलना में बहुत तेज है। हमारे माप के अनुसार, अंतर लगभग 6 गुना हैं। इसके अलावा, बड़ी लिपियों के लिए सिंटैक्स ट्री में बहुत अधिक रैम स्पेस हो सकता है, और जब तक हमें विजुअल और स्क्लस्वर मैनेजमेंट स्टूडियो के 32-बिट एड्रेस स्पेस में जीवित रहना है, यह महत्वपूर्ण हो सकता है।

निष्कर्ष

उप-योग निम्नानुसार हो सकते हैं:

ANTLR पार्सर के निर्माण के लिए एक शक्तिशाली उपकरण है
दूसरों पर इसका लाभ उपकरण, सुविधाजनक वाक्यविन्यास, बड़ी संख्या में समर्थित भाषाएं हैं
ANTLR4 को स्क्रैच से फिर से लिखा गया है और इसका मतलब तीसरे संस्करण से अलग पार्सर के साथ काम करना है
हमेशा थर्डपार्टी पुस्तकालयों से थोड़ा अधिक पाने का एक तरीका है जितना वे देते हैं
SQL विशिष्ट भाषा, इसके लिए पार्सर का निर्माण एक आसान काम नहीं है
आईडीई के निर्माण से संबंधित कार्यों के लिए पार्सिंग कोड की अपनी विशिष्टताएँ हैं: आपको अनएन्क्रिप्टेड या अमान्य स्क्रिप्ट पर काम करने पर विचार करने की आवश्यकता है

मिलते हैं अगले भाग में!

एसक्यूएल को लागू करना। भाग 1. पार्सिंग की जटिलता। ANTLR फ़ाइल को अंतिम रूप देने के बारे में कहानियां