Pegjs: कुछ प्रस्तुतियों को अनदेखा करने की क्षमता

माना। क्या इस समय ऐसा करने का कोई साफ तरीका है?

@benekastah : अभी तक कोई साफ रास्ता नहीं है।

PEG.js के कार्य करने के तरीके को बदले बिना यह करना कठिन होगा। संभावित समाधानों में शामिल हैं:

1. जेनरेट किए गए पार्सर से पहले एक लेक्सर तैयार करने की अनुमति दें।
2. अंतर्निहित नियमों के बारे में जानकारी को व्याकरण में कहीं एम्बेड करें। इसका अर्थ शायद व्याकरण के शाब्दिक और वाक्य-विन्यास के स्तर के बीच अंतर करना भी होगा - ऐसा कुछ जिसे मैं टालना चाहता हूं।

मैं अभी इस पर काम नहीं करूंगा लेकिन यह फीचर में सोचने वाली बात है।

मुझे इस सुविधा की आवश्यकता होगी।

हो सकता है कि आप "स्किप" -टोकन पेश कर सकें। तो यदि कोई नियम उस टोकन को लौटाता है, तो इसे अनदेखा कर दिया जाएगा और एएसटी (सरणी में उर्फ ​​प्रविष्टि) पर कोई नोड नहीं मिलेगा।

मैं भी ऐसा करने का एक तरीका ढूंढ रहा हूं।

मेरे पास एक बड़ी व्याकरण फ़ाइल है (यह एसएनएमपी एमआईबी फाइलों के लिए एएसएन.1 प्रारूप को पार करती है)। मैंने इसे नहीं लिखा, लेकिन मैंने इसे मूल रूप से PEG.js में एक पार्सर बनाने के लिए बदल दिया। (यह अच्छा है। वास्तव में, यह बहुत ही स्लीक है कि मुझे इसे बदलने में 15 मिनट से भी कम समय लगा ताकि PEG.js इसे स्वीकार कर सके।)

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

मैं व्याकरण को समझने के लिए उत्सुक नहीं हूं ताकि मैं सभी नियमों में सभी उचित सफेद जगह डाल सकूं (लगभग 126 प्रस्तुतियां हैं ...) क्या ऐसा करने का कोई और तरीका है?

ध्यान दें: इस घटना में कि मुझे व्याकरण को हाथ से संशोधित करना है, मैंने Google समूह सूची में टिकट में कुछ quesitons के लिए मदद मांगी। http://groups.google.com/group/pegjs/browse_thread/thread/568b629f093983b7

बहुत धन्यवाद!

Google Groups पर मौजूद लोगों को धन्यवाद। मुझे लगता है कि मुझे वह करने की अनुमति देने के लिए पर्याप्त जानकारी मिली है जो मैं चाहता हूं।

लेकिन मैं वास्तव में पीईजी.जेएस में व्हाइटस्पेस/टिप्पणियों को पूरी तरह से अनदेखा करने के लिए चिह्नित करने की क्षमता की प्रतीक्षा कर रहा हूं ताकि मुझे अन्यथा साफ व्याकरण को संशोधित करने के लिए कुछ घंटे नहीं लेना पड़े ... धन्यवाद!

धनी

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

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

elideWS.pegjs:

एस = इनपुट: (व्हाइटस्पेस कैरेक्टर / टेक्स्ट कैरेक्टर) *
{
वर परिणाम = "";

for(var i = 0;i < input.length;i++) result += input[i];
वापसी परिणाम;
}

व्हाइटस्पेस कैरेक्टर = [एनटी] {रिटर्न ""; }
टेक्स्ट कैरेक्टर = सी: [^ एनटी] {रिटर्न सी; }

लेकिन यह समस्या का कारण बनता है जब व्हाइटस्पेस एक डिलीमीटर होता है - जैसे पहचानकर्ताओं के लिए

इस मुद्दे पर अक्सर टकराते रहते हैं।
लेकिन एक अच्छा लेक्सर लिखना आसान नहीं है (आप एक सुसंगत लेक्सर रखने के लिए प्रारंभिक व्याकरण के एक अच्छे हिस्से की नकल कर सकते हैं)।

मैं जो सोच रहा था वह स्किप नियमों को परिभाषित करने में सक्षम होना है जो कि जब भी कोई मेल नहीं होता है तो विकल्प के रूप में उपयोग किया जा सकता है। यह हालांकि एक गैर-ब्रेकिंग वर्ग की आवश्यकता का परिचय देता है। उदाहरण arithmetics.pegjs फ्लोट्स का उपयोग करके

  = Term (("+" / "-") Term)*

Term
  = Factor (("*" / "/") Factor)*

Factor
  = "(" Expression ")"
  / Float

Float "float"
  = "-"? # [0-9]+ # ("." # [0-9]+) // # means that skip rules cannot match

// skip rule marked by "!="
// skip rules cannot match the empty string
_ "whitespace"
  != [ \t\n\r]+

अभी भी इसे पचा रहे हैं। कोई प्रतिपादन? बहुत बेवकूफी भरा विचार हो सकता है।

तो अंतर यह है कि आप अंतर करना चाहते हैं जब समग्र इंजन है
लेक्सर मोड में काम करना (व्हाट्सएप महत्वपूर्ण है) और जब नहीं (व्हाट्सएप is
अवहेलना करना)।

क्या कोई ऐसा मामला है जब आप लेक्सर मोड में व्हॉट्सएप को नजरअंदाज नहीं करना चाहते हैं?
एक विकल्प के रूप में? या इसके विपरीत, जब रेगेक्स के अंदर नहीं है? मेरे ख़्याल से नहीं।

क्या निम्नलिखित समकक्ष होंगे?

पानी पर तैरना
"-?[0-9]+("।" [0-9]+)"

या अन्यथा सामान्य रेगेक्स को सीधे और बाहर संसाधित करने के लिए पेग का विस्तार करें
एक उद्धृत स्ट्रिंग (जिसमें रेगेक्स शामिल हैं) व्हाइटस्पेस को अनदेखा किया जाता है।

19 अप्रैल 2014 को अपराह्न 3:22 बजे, आंद्रेई नेकुलाऊ नोटिफिकेशन @github.com ने लिखा:

इस मुद्दे पर अक्सर टकराते रहते हैं।
लेकिन एक अच्छा लेक्सर लिखना आसान नहीं है (आप एक सुसंगत लेक्सर रखने के लिए प्रारंभिक व्याकरण के एक अच्छे हिस्से की नकल कर सकते हैं)।

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

अभिव्यक्ति
= टर्म (("+" / "-") टर्म)*

अवधि
= कारक (("_" / "/") कारक)_

फ़ैक्टर
= "(" अभिव्यक्ति ")"
/ पानी पर तैरना

फ्लोट "फ्लोट"
= "-"? # [0-9]+ # ("।" # [0-9]+) // # का मतलब है कि स्किप नियम मेल नहीं खा सकते

// "! =" द्वारा चिह्नित नियम छोड़ें
// छोड़ें नियम खाली स्ट्रिंग से मेल नहीं खा सकते हैं
_ "व्हाइटस्पेस"
!= [ टीएनआर]+
अभी भी इसे पचा रहे हैं। कोई प्रतिपादन? बहुत बेवकूफी भरा विचार हो सकता है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

@waTeim वास्तव में नहीं।

परंपरागत रूप से पार्सिंग प्रक्रिया को लेक्सिंग और पार्सिंग में विभाजित किया जाता है। लेक्सिंग के दौरान हर किरदार का महत्व होता है, जिसमें व्हाइटस्पेस भी शामिल है। लेकिन फिर इन्हें "त्याग" टोकन में बदल दिया जाता है। पार्सर, अगले टोकन पर आगे बढ़ने पर, किसी भी त्यागने वाले टोकन को त्याग देगा। महत्वपूर्ण हिस्सा यह है कि आप कुछ भी त्याग सकते हैं, न कि केवल रिक्त स्थान। यह व्यवहार ठीक वैसा ही है जैसा @andreineculau वर्णन कर रहा है।

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

23 अप्रैल 2014 को दोपहर 2:54 बजे सीन फैरेल नोटिफिकेशन @github.com ने लिखा:

@waTeim वास्तव में नहीं।

तो हम सहमत हैं। पारंपरिक दृष्टिकोण पर्याप्त है। होने की कोई आवश्यकता नहीं है
कड़ाई से पार्सर भाग त्याग किए गए टोकन के अस्तित्व को पहचानता है और वहां है
लेक्सर भाग को सशर्त व्यवहार करने का कोई कारण नहीं है (संदर्भ संवेदनशील तरीके से)
wrt टोकन पहचान रहा है।

इसलिए भाषा में गोंद तत्व (जैसे '#') रखने की कोई आवश्यकता नहीं है
क्योंकि यह पर्याप्त है

1) टोकन पूरी तरह से रेगेक्स से बनाए जा सकते हैं और संदर्भ संवेदनशील नहीं हैं।
2) टोकन को बिना किसी अपवाद के त्यागने के लिए चिह्नित किया जा सकता है।

परंपरागत रूप से पार्सिंग प्रक्रिया को लेक्सिंग और पार्सिंग में विभाजित किया जाता है। लेक्सिंग के दौरान हर किरदार का महत्व होता है, जिसमें व्हाइटस्पेस भी शामिल है। लेकिन फिर इन्हें "त्याग" टोकन में बदल दिया जाता है। पार्सर, अगले टोकन पर आगे बढ़ने पर, किसी भी त्यागने वाले टोकन को त्याग देगा। महत्वपूर्ण हिस्सा यह है कि आप कुछ भी त्याग सकते हैं, न कि केवल रिक्त स्थान। यह व्यवहार ठीक वैसा ही है जैसा @andreineculau वर्णन कर रहा है।

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

ठीक है तो मैंने आपको गलत समझा। लेक्सर राज्यों के मामले हो सकते हैं, लेकिन यह एक पूरी तरह से अलग आवश्यकता है और IMHO peg.js के दायरे से बाहर है।

@waTeim @rioki मेरे सुझाव के बारे में थोड़ा भूल जाओ।

हाथ, इस नियम को ले लो। यदि आप *WS को हटाकर नियम के व्याकरण को सरल बनाना चाहते हैं, तो आप PEGjs को field_name और : बीच field_name *WS अनुमति नहीं देने का निर्देश कैसे देंगे?

@andreineculau क्योंकि आपका व्याकरण व्हाइटस्पेस संवेदनशील है, यह लागू नहीं है। त्यागने वाले टोकन व्याकरण का हिस्सा होंगे, सटीक होने के लिए लेक्सिंग भाग। मुझे नहीं पता कि यहां क्या बड़ा मुद्दा है, यह पहले से ही 70 के दशक में पर्याप्त रूप से हल किया गया था। प्रत्येक भाषा के अपने स्किप करने योग्य टोकन होते हैं और जहां वे लागू होते हैं। रिक्त स्थान और टिप्पणियां भाषा परिभाषा का उतना ही हिस्सा हैं और इस प्रकार व्याकरण का हिस्सा हैं। यह सिर्फ यह पता चला है कि अधिकांश भाषाओं के साथ स्किप करने योग्य टोकन प्रत्येक दूसरे टोकन के बीच हो सकते हैं और एक त्याग नियम का उपयोग करना प्रत्येक नियम के लिए expr = WS lit WS op WS expr WS ";" लिखने से आसान बनाता है। व्हाइटस्पेस हैंडलिंग के साथ सी के लिए एक व्याकरण की कल्पना करें?

मैं समझता हूं कि नियमों को pegjs में फिर से जोड़ना आसान नहीं है, लेकिन इसका मतलब यह नहीं है कि यह एक प्रशंसनीय लक्ष्य नहीं है।

अरे यार, फ्री रिस्पांस सेक्शन! मेरे पास कहने के लिए बहुत कुछ है, इसलिए लंबाई के लिए खेद है।

1) टीएल; डीआर लोगों के लिए, अगर मैं कोई खूंटी तत्व जोड़ सकता हूं, तो मैं चाहता था, मैं इसे इस तरह लिखूंगा

हेडर_फ़ील्ड
= फ़ील्ड_नाम ":" फ़ील्ड_वैल्यू

खाली जगह (इग्नोर)
= [टी]+

मैं जो जोड़ूंगा वह एक विकल्प अनुभाग है जिसे किसी भी उत्पादन में शामिल किया जा सकता है

http-bis भाषा इस पुनर्लेखन द्वारा सीमित नहीं होगी (देखें परिशिष्ट a)।

2) प्रस्तावित # के साथ मेरी समस्या

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

परिशिष्ट ए, HTTP-बीआईएस उन घटनाओं में से एक नहीं है, बस बुरी तरह से प्रलेखित है।

3) उपयोगकर्ता परिभाषित पार्सर राज्य

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

उत्पादन 1 (राज्य == 1)
= सामान

उत्पादन 2 (राज्य == 2)
= सामान

उत्पादन3
= सामान {राज्य = 1}

उत्पादन4
= सामान {राज्य = 2}

दूसरे शब्दों में, लेक्स/वाईएसीसी की तरह ही यह संभव है कि प्रोडक्शंस केवल उपलब्ध हों

यदि सिस्टम किसी विशेष स्थिति में है, और उपयोगकर्ता को उस राज्य मान को सेट करने की अनुमति देता है।

4) अधिक विकल्प

या आप इसे उपयोगकर्ता के लिए आसान बना सकते हैं और दूसरे के साथ पाठक के लिए अधिक स्पष्ट कर सकते हैं
विकल्प

उत्पादन (डोंटिग्नोर)
= सामान

जो पार्सर को चिह्नित किए गए टोकन को हटाने की डिफ़ॉल्ट कार्रवाई को ओवरराइड करने की अनुमति देगा
त्याग के रूप में लेकिन केवल उस एक उत्पादन के लिए। यह वास्तव में 3 जैसा ही है, बस एक आसान
पढ़ना। यह # प्रस्ताव से कम लचीला है क्योंकि या तो एक उत्पादन सभी को अनदेखा कर दिया जाता है

या कोई उपेक्षा नहीं, लेकिन मुझे नहीं लगता कि अतिरिक्त लचीलेपन की आवश्यकता है।

5) getNextToken में एक पैरामीटर जोड़ना () संदर्भ संवेदनशीलता की अनुमति देता है

मुझे लगता है कि यह सब नीचे आता है (मैं यहाँ कुछ धारणाएँ बना रहा हूँ) वर्तमान में,
पार्सर भाग getNextToken (इनपुट) को कॉल करता है, और इसके बजाय जो होना चाहिए वह है a

इसके लिए पैरामीटर getNextToken (इनपुट, विकल्प)।

परिशिष्ट a) वह HTTP-bis spec

ठीक है मैंने कुछ पढ़ा है लेकिन यह सब नहीं पढ़ा है

हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP / 1.1): संदेश सिंटैक्स और रूटिंग
ड्राफ्ट-आईईटीएफ-httpbis-p1-मैसेजिंग-26

जिस तरह से उन्होंने अपने व्याकरण को परिभाषित किया है, मुझे वह पसंद नहीं है। मैं इनपुट को बदलने का सुझाव नहीं देता it
स्वीकार करता है, लेकिन मैंने इसे परिभाषित नहीं किया होगा जैसा उन्होंने किया था। विशेष रूप से, मुझे पसंद नहीं है कि उनके पास क्यों है
परिभाषित OWS और RWS और BWS जो सभी बिल्कुल समान वर्ण स्ट्रिंग के समान हैं
लेकिन अलग-अलग संदर्भों में। उन्होंने परिभाषित किया है

ओडब्ल्यूएस ::== (एसपी | एचटीएबी)*
आरडब्ल्यूएस ::== (एसपी | एचटीएबी)+
बीडब्ल्यूएस ::== ओडब्ल्यूएस

जो सिर्फ टैब और रिक्त स्थान की पुनरावृत्ति है

बिना किसी अच्छे कारण के। उन्होंने भाषा को पार्स करना कठिन बना दिया है - शाब्दिक विश्लेषक की आवश्यकता है
इसके संदर्भ को ट्रैक करने के लिए — और उन्हें ऐसा करने की आवश्यकता नहीं थी।

उन्होंने OWS को "वैकल्पिक सफेद स्थान" के रूप में BWS को "खराब खाली स्थान" या अन्यथा वैकल्पिक के रूप में परिभाषित किया है
व्हाइटस्पेस लेकिन "खराब" संदर्भ में - जहां यह आवश्यक नहीं है - और आरडब्ल्यूएस को व्हाइटस्पेस की आवश्यकता है जहां यह है
टोकन परिसीमन करने के लिए आवश्यक है। इस व्हाइटस्पेस का कहीं भी उपयोग नहीं किया जाता है सिवाय इसके कि शायद एक पार्सर हो सकता है
चेतावनी अगर यह बीडब्ल्यूएस से मेल खाती है ("अनावश्यक अनुगामी व्हाइटस्पेस का पता चला है" या कुछ ऐसे) जो सभी है
सीमांकक वैसे भी करते हैं।

उनकी कल्पना में, केवल RWS का उपयोग किया जाने वाला स्थान यहाँ है

वाया = 1#(प्राप्त प्रोटोकॉल आरडब्ल्यूएस प्राप्त-द्वारा [आरडब्ल्यूएस टिप्पणी])

 received-protocol = [ protocol-name "/" ] protocol-version
                     ; see Section 6.7
 received-by       = ( uri-host [ ":" port ] ) / pseudonym
 pseudonym         = token

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

24 अप्रैल 2014 को दोपहर 1:23 बजे, आंद्रेई नेकुलाऊ नोटिफिकेशन @github.com ने लिखा:

@waTeim @rioki मेरे सुझाव के बारे में थोड़ा भूल जाओ।

हाथ, इस नियम को ले लो। यदि आप OWS को हटाकर नियम के व्याकरण को सरल बनाना चाहते हैं, तो आप PEGjs को फ़ील्ड_नाम और :? के बीच OWS को अनुमति न देने का निर्देश कैसे देंगे?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

@waTeim मुझे लगता है कि आप इसके साथ ओवरबोर्ड जा रहे हैं। मैंने काफी कम पार्सर्स लिखे हैं और मुझे लगता है कि लेक्सर कहता है कि वास्तव में कभी भी इस तरह उपयोगी नहीं होता है। ज्यादातर मामलों में मैंने उन्हें देखा था जहां लेक्सर ने ब्लॉक टिप्पणियों का उपभोग किया था और लेक्सर को "ब्लॉक कमेंट मोड" में रखना "सरल" था और टिप्पणी (और गिनती लाइनों) का उपभोग करने के लिए über पैटर्न की तुलना में सरल पैटर्न लिखना था।

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

व्याकरण लिखते समय आप मूल रूप से परिभाषित करते हैं कि कौन सी प्रस्तुतियों को पार्स किया गया माना जाता है और क्या छीना जा सकता है। @andreineculau के उदाहरण में दो विकल्प हैं, या तो आप पार्सर में सफेद रिक्त स्थान को संभालते हैं या आप टोकन के अनुगामी ":" भाग को परिभाषित करते हैं। ( [a-zA-Z0-9!#$%&'+-.^_|~]+ ":" )।

मैं एक श्वेतसूची निर्दिष्ट करने में समस्या को बदलने का सुझाव दे सकता हूं- मैं ब्लैकलिस्ट के बजाय किन हिस्सों को कैप्चर और बदलना चाहता हूं। हालांकि व्हॉट्सएप वर्तमान कैप्चर सिस्टम के साथ एक समस्या है, नियमों का नेस्टिंग दूसरा है। जैसा कि मैंने अंक #66 में

कैप्चर के संबंध में LPeg बनाम PEG.js के सरल उदाहरण के लिए अंक #66 में मेरी टिप्पणी देखें। हालांकि नाम थोड़े गूढ़ हैं, एलपीईजी दस्तावेज़ीकरण के कैप्चर अनुभाग को उन विभिन्न तरीकों के लिए देखें जिनसे आप किसी दिए गए उत्पादन (या उसके हिस्से) को कैप्चर या रूपांतरित कर सकते हैं।

नमस्ते, मैंने कुछ सामान्य मामलों को नज़रअंदाज़ करने के लिए एक स्निपेट बनाया null , undefined और केवल अंतरिक्ष प्रतीकों के साथ तार।
व्याकरण फ़ाइल के शीर्ष में इसकी आवश्यकता हो सकती है, जैसे:

{
  var strip = require('./strip-ast');
}

इसे सुधारने के दो तरीके:

• शर्तों के लिए अनुकूलन योग्य फ़िल्टर — विशिष्ट व्याकरण की आवश्यकता वाले विशिष्ट शब्दों को अनदेखा करने के लिए।
• नेस्टेड खाली सरणियों को छोड़ें - यह strip बाद दूसरे चरण में किया जा सकता है, यह नेस्टेड खाली सरणियों के «पिरामिड्स» को हटा देगा।
  अगर किसी को दिलचस्पी है, तो हम इसे पैकेज में अपग्रेड कर सकते हैं।

@ Richb-hanover आपकी ASN.1 परिभाषा पार्सर प्रयास कहां से आए?

@atesgoral - मैं जमानत पर छूट गया। मुझे "असली पार्सर" की आवश्यकता नहीं थी - मुझे केवल लक्ष्य फ़ाइल में कुछ नामित तत्वों को अलग करने की आवश्यकता थी।

तो मैंने वही किया जो कोई भी डरपोक आदमी करेगा - रेगुलर एक्सप्रेशन का इस्तेमाल किया। (और फिर मुझे दो समस्याएं थीं :-)

लेकिन इसने चाल चली, इसलिए मैं अगली चुनौती के लिए आगे बढ़ने में सक्षम था। आपकी परियोजना में शुभकामनाएँ!

शेवरोटेन और इसके स्किप विकल्प पर एक नज़र डालने के बाद, ऐसा कुछ बेहद वांछनीय है।

अक्सर हम खुद को कुछ इस तरह लिखते हुए पाते हैं:

Pattern = head:PatternPart tail:( WS "," WS PatternPart )*
{
  return {
    type: 'pattern',
    elements: buildList( head, tail, 3 )
  };
}

अच्छा होगा अगर हम इसके बजाय इसे लिख सकें:

WS "whitespace" = [ \t\n\r] { return '@<strong i="11">@skipped</strong>' }

IgnoredComma = "," { return '@<strong i="12">@skipped</strong>' }

Pattern = head:PatternPart tail:( WS IgnoredComma WS PatternPart )*
{
  return {
    type: 'pattern',
    elements: [head].concat(tail)
  };
}

@ रिचब-हनोवर, और कोई भी जो समान आवश्यकता की तलाश में यहां आया, मैंने अपने स्वयं के पार्सर भी लिखना समाप्त कर दिया: https://www.npmjs.com/package/asn1exp और https://www.npmjs। कॉम/पैकेज/asn1-पेड़

es6 symbol का उपयोग करके एक स्किप को लागू करना अपेक्षाकृत आसान होगा, या शायद अधिक टिकाऊ रूप से पार्सर को पार्स समय पर एक विधेय पारित करके (मैं बाद वाला विकल्प पसंद करता हूं)

बस इस पर भी ठोकर खाई।
पीईजी.जेएस के अंदरूनी हिस्सों के बारे में कुछ भी नहीं जानते, लेमे ने वहां एक हड्डी फेंक दी ...

जब हम कोई नियम लिखते हैं, तो उसके अंत में हम रिटर्न ब्लॉक जोड़ सकते हैं।
उस ब्लॉक में, हम text() और location() जैसी चीज़ों को कॉल कर सकते हैं। ये आंतरिक कार्य हैं।

कोड में कहीं न कहीं उस ब्लॉक का रिटर्न वैल्यू आउटपुट स्ट्रीम में चला जाता है।

तो PEG.js में क्या बदलने की आवश्यकता होगी यदि मैं किसी नियम द्वारा लौटाए गए मान को छोड़ना चाहता हूं यदि वह मान skip स्थानीय फ़ंक्शन को कॉल करने की वापसी है?

उदाहरण के लिए comment = "//" space ([^\n])* newline { return skip() }

जैसा ऊपर बताया गया है, छोड़ें() एक प्रतीक वापस कर सकता है, जिसे बाद में कहीं कोड द्वारा चेक किया जाता है और हटा दिया जाता है।
कुछ ऐसा जो लज़ाकी ने कहा, लेकिन पुस्तकालय के लिए आंतरिक

मैं आपका प्रश्न नहीं समझता। क्या आप कुछ परिस्थितियों में किसी नियम को विफल करने का तरीका ढूंढ रहे हैं? &{...} या !{...} । अन्यथा बस comment नियम के दिए गए मान का उपयोग न करें:

seq = comment r:another_rule { return r; };
choice = (comment / another_rule) { <you need to decide what to return instead of "comment" result> };

अगर यह किसी की मदद करता है, तो मैं अपने शीर्ष-स्तरीय नियम परिणामों की सरणी को फ़िल्टर करके व्हाइटस्पेस को अनदेखा करता हूं।

उदाहरण:

    = prog:expression+ {return prog.filter(a => a)}

expression
    = float
    / number
    / whitespace

float
    = digits:(number"."number) {return parseFloat(digits.join(""),10)}

number 
    = digits:digit+ {return parseInt(digits.join(""),10)}

digit 
    = [0-9]

whitespace
    = [ \t\r\n] {return undefined}

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

यह केवल शीर्ष-स्तरीय प्रस्तुतियों के लिए काम करता है। आपको प्रत्येक माता-पिता को मैन्युअल रूप से फ़िल्टर करना होगा जिसमें फ़िल्टर करने योग्य बच्चा हो सकता है।

@StoneCypher सच है, इसके लिए कुछ शीर्ष स्तर के काम की आवश्यकता होती है, लेकिन यह मेरे लिए काम करता है, और मुझे लगता है कि जब तक गैमर बहुत जटिल नहीं है, तब तक किसी को शीर्ष स्तर के फ़िल्टर से दूर होने में सक्षम होना चाहिए।

इसके अलावा, मैं सोच सकता हूं कि एक शीर्ष स्तरीय फ़ंक्शन है जो इनपुट से व्हाइटस्पेस को फ़िल्टर करता है और इसके माध्यम से प्रत्येक मैच को पास करता है। निश्चित रूप से धीमा, और बहुत अधिक कॉल की आवश्यकता है, लेकिन आसान है यदि आप (मेरी तरह) सब कुछ एक टोकन जनरेटर में पास करते हैं। आप फ़िल्टर फ़ंक्शन को कॉल कर सकते हैं जहां से आप टोकन जेनरेट करते हैं, और केवल अपने टोकन जेनरेट करने के बारे में चिंता करने की ज़रूरत है और व्हाइटस्पेस कमोबेश स्वचालित रूप से फ़िल्टर हो जाता है

pegjs के वर्तमान HEAD के बारे में मुझे जो चीजें पसंद हैं उनमें से एक है लेबल बनाने और रिटर्न स्टेटमेंट किए बिना फ़ील्ड चुनने के लिए इसका (अनियंत्रित) समर्थन। यह इस तरह दिख रहा है:

foo = <strong i="6">@bar</strong> _ <strong i="7">@baz</strong>
bar = $"bar"i
baz = $"baz"i
_ = " "*

parse('barbaz') // returns [ 'bar', 'baz' ]

मुझे ऐसा लगता है कि यह इस उपयोग के मामले के साथ-साथ दूसरों का एक समूह के लिए अच्छा, साफ, स्पष्ट वाक्यविन्यास देता है।