Pegjs: पैरामीट्रिजेबल नियम लागू करें

क्या आपके पास विशिष्ट उपयोग का मामला है जहां यह आपको महत्वपूर्ण मात्रा में काम बचाएगा या वर्तमान में असंभव कुछ संभव बना देगा?

यह उन नियमों को कॉल करके इंडेंटेशन स्तरों को पार्स करना आसान बनाता है जिनके स्तर को तर्क के रूप में पारित किया गया है।

इसके अलावा, एक शुद्ध डीआरवाई तर्क में, "इस चरित्र द्वारा इस तरह से बचने के अनुक्रम के साथ सीमित सामान" जैसी चीजें करते समय, नियम (और उसके कार्यों!) को तीन बार करने की तुलना में delimited('\'', '\\') जैसे कुछ कॉल करना अच्छा होता है। .

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

कृपया इसे न लें क्योंकि मैं स्वयं इस सुविधा का विरोध कर रहा हूं। मैं आम तौर पर जटिलता और कार्यान्वयन लागत के कारण केवल भाषाओं या डेवलपर्स के एक छोटे से अंश के लिए उपयोगी सुविधाओं को लागू नहीं करना चाहता हूं। और इस मामले में लागत अपेक्षाकृत अधिक है।

जावास्क्रिप्ट के लिए बस एक पार्सर लिखना, मेरे पास string = delimited_by('\'') / delimited_by('\"') और फिर बाद में regexp = delimited_by('/') हो सकता है।

हाल ही में, मैं अपनी भाषा के लिए एक पार्सर लिख रहा हूं। मेरे पास पाइथन के लिए लिखे गए पीईजी ढांचे में ऐसा कुछ है:

LeftAssociative(op, subrule): l:subrule rest:(op subrule)* -> a_recursive_function_that_reverses_rest_and_makes_bintrees(l, op, subrule)

और मैं तब लिख सकता हूं:

...
exp_mult = LeftAssociative(/[\*\/%]/, exp_paren)
exp_add = LeftAssociative(/[\+-]/, exp_mult)

चूंकि मेरे पास सी ++ (इसके सभी ऑपरेटरों और कुछ और) के रूप में प्राथमिकता के कई स्तर हैं, इसलिए मैं आपको कल्पना कर सकता हूं कि में कितना उपयोगी हो सकता है। मैंने अभी तक पार्सिंग अभिव्यक्तियों में नहीं किया है, फिर भी मैं इसे पहले से ही 12 बार उपयोग कर चुका हूं।

यह बहुत अच्छा होगा यदि इसे 'आयात' सुविधा के साथ जोड़ा जाए

require(CommaSeparatedList.pegjs)
require(StringLiteral.pegjs)
require(IntegerLiteral.pegjs)

...

Function
 = name:FuncName "(" args:CommaSeparatedList(Literal)  ")" 

Hash
= "{"   props:CommaSeparatedList(Prop)   "}"

Prop
= Key ":" Literal

Literal =
  StringLiteral / IntegerLiteral

(यह ओपी के अनुरोध से थोड़ा अधिक जटिल है, लेकिन यह अपने स्वयं के धागे को सही ठहराने के बहुत करीब लग रहा था।)

मैं PEG.js की मदद से एक R5RS स्कीम पार्सर बना रहा हूं। quasiquotations को छोड़कर सब कुछ गुलाबी है, जिसके लिए संदर्भ-जागरूक पार्सिंग की आवश्यकता होती है। बड़ी मात्रा में अजीब पोस्ट-प्रोसेसिंग से बचने के लिए टेम्पलेट्स से ऑन-द-फ्लाई नियम पीढ़ी के लिए नियमों को पैरामीटर करने में सक्षम होना उपयोगी होगा। उदाहरण के लिए, एक सरलीकृत quasiquotation व्याकरण इस तरह दिख सकता है:

    quasiquotation = qq[1]
    qq[n] = "`" qq_template[n]
    qq_template[0] = expression
    qq_template[n] = simple_datum / list_qq_template[n] / unquotation[n]
    list_qq_template[n] = "(" qq_template[n]* ")" / qq[n+1]
    unquotation[n] = "," qq_template[n-1]

यदि इस सुविधा को उपकरण में जोड़ने में कोई रुचि है, तो मुझे इस सुविधा के विकास में योगदान देने में दिलचस्पी है।

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

http://trevorjim.com/haskell-is-not-context-free/
http://trevorjim.com/how-to-prove-that-a-programming-language-is-context-free/

एक पार्सर में बाहरी स्थिति का उपयोग करना जो बैकट्रैक कर सकता है (जैसे पीईजी कैन) खतरनाक है, और इस तरह के मुद्दों को इस पार्सर में देखा जा सकता है:

{   var countCs = 0;
}

start = ((x/y) ws*)* { return countCs }

x = "ab" c "d"
y = "a" bc "e"

c = "c" { countCs++; }
bc = "bc" { countCs++; }

ws = " " / "\n"

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

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

start = countCs:((x<0>/y<0>) ws*)* { return countCs.reduce(function(a,b){return a+b[0];}, 0); }

x<count> = "ab" theCount:c<count> "d" { return theCount; }
y<count> = "a" theCount:bc<count> "e" { return theCount; }

c<count> = "c" { return count++; }
bc<count> = "bc" { return count++; }

ws = " " / "\n"

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

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

literalStringWithExplicitLength = "string[" n:number ":" characters<n> "]"
number = n:[0-9]* {return parseInt(n.join(''));}
characters<n> = c:. { // base case
  if(n>0) return null; // don't match base case unless n is 0
  else return c;
}
/ c:. cs:characters<n-1> {
  ret c+cs
}

यह स्ट्रिंग [10: abcdefghij] जैसी स्ट्रिंग को पार्स करने में सक्षम होगा। आप इसे अच्छे शुद्ध PEG.js के साथ नहीं कर सकते जैसा कि यह खड़ा है। आपने कुछ भयानक किया है जैसे:

{ var literalStringLengthLeft=undefined;
}
literalStringWithExplicitLength = "string[" n:specialNumber ":" characters "]"
specialNumber = n:number {
  literalStringLengthLeft = n;
  return n;
}
number = n:[0-9]* {return parseInt(n.join(''));}
characters = c:character cs:characters? {
  return c + cs
}
character = c:. {
  if(literalStringLengthLeft > 0) {
    literalStringLengthLeft--;
    return c;
  } else {
    literalStringLengthLeft = undefined;
    return null; // doesn't match
  }
}

कई प्रोटोकॉल में इस प्रकार की पार्सिंग आवश्यकता होती है - उदाहरण के लिए, आईपीवी 4 पैकेट में इसकी कुल लंबाई का वर्णन करने वाला एक क्षेत्र होता है। बाकी पैकेट को ठीक से पार्स करने के लिए आपको उस संदर्भ की आवश्यकता है। IPv6, UDP और शायद किसी अन्य पैकेट-आधारित प्रोटोकॉल के लिए भी यही सच है। टीसीपी का उपयोग करने वाले अधिकांश प्रोटोकॉल को भी कुछ इस तरह की आवश्यकता होगी, क्योंकि किसी को एक ही वैचारिक चरित्र धारा का उपयोग करके कई पूरी तरह से अलग वस्तुओं को प्रसारित करने में सक्षम होना चाहिए।

वैसे भी, मुझे आशा है कि मैंने कुछ अच्छे उदाहरण और कारण दिए हैं कि मुझे क्यों लगता है कि यह न केवल एक अच्छी विशेषता है, न केवल एक शक्तिशाली विशेषता है, बल्कि वास्तव में एक आवश्यक विशेषता है कि कई पार्सर्स गायब हैं (फिलहाल, पीईजी.जेएस सहित) )

पेगासस (एक प्रोजेक्ट जो अपने अधिकांश सिंटैक्स को peg.js के साथ साझा करता है) इसे #STATE{} अभिव्यक्ति के साथ हल करता है जिसे राज्य के शब्दकोश को बदलने की क्षमता दी जाती है। जब नियम पीछे हट जाते हैं तो राज्य का यह शब्दकोश पीछे हट जाता है। यह इसे महत्वपूर्ण व्हाइटस्पेस पार्सिंग का समर्थन करने की अनुमति देता है (विवरण के लिए महत्वपूर्ण व्हाइटस्पेस के बारे में विकी प्रविष्टि देखें)।

साथ ही, राज्य को पार्सिंग कर्सर के साथ पीछे करके, स्टेटफुल नियमों के लिए भी ज्ञापन पूरा किया जा सकता है।

मुझे लगता है कि Peg.js आसानी से ऐसा कर सकता है।

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

सैद्धांतिक रूप से, पार्सर अमान्य रूप से निष्पादित कार्रवाइयों से बच सकता है यदि ए। क्रियाओं को क्लोजर में कतारबद्ध किया जाता है और केवल एक बार पार्सर के पूरी तरह से पूरा होने के बाद निष्पादित किया जाता है, और बी। क्योंकि वे पार्सर के पूरा होने के बाद निष्पादित होते हैं, वे एक नियम मैच को रद्द नहीं कर सकते। शायद वह योजना पेगासस में किए गए राज्य की तुलना में अधिक इष्टतम होगी?

इसके अलावा, अमान्य स्थिति की समस्या को ठीक करना वास्तव में बहुत अच्छा है, लेकिन यह अभिव्यक्ति की समस्या को हल नहीं करता है जिसे मैंने स्ट्रिंग अक्षर से संबंधित स्ट्रिंग [10: abcdefghij] से जोड़ा है, लेकिन मुझे निश्चित रूप से दिलचस्पी है कि यह कैसे काम करता है

यह पूरे कार्यक्रम की स्थिति को पीछे नहीं हटाता है। यह राज्य का एक अपरिवर्तनीय शब्दकोश रखता है। यह कर्सर के साथ वर्तमान स्टेट डिक्शनरी को सेव करता है और जब भी कर्सर बैकट्रैक किया जाता है, स्टेट डिक्शनरी इसके साथ बैकट्रैक हो जाता है। शब्दकोश #STATE{} क्रियाओं के बाहर कहीं भी अपरिवर्तनीय है, और प्रत्येक राज्य परिवर्तन से ठीक पहले कॉपी किया गया है।

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

जावास्क्रिप्ट में (मेरी जानकारी के लिए) किसी वस्तु को अपरिवर्तनीय बनाने की क्षमता नहीं है, लेकिन यह ज्यादातर एक सुरक्षा विशेषता थी। Peg.js को प्रत्येक #STATE{} कोड ब्लॉक को संसाधित करने से पहले बस एक स्टेट डिक्शनरी को कॉपी करना होगा और जब भी कर्सर बैकट्रैक किया जाएगा, तो उसे बैकट्रैक करना होगा।

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

मैंने अभी एक कांटा लिखा है जो एक पर्यावरण की आपूर्ति करता है, जो चर env का उपयोग करके सुलभ है: https://github.com/tebbi/pegjs
यह ऊपर सुझाई गई #STATE{} वस्तु के समान है।
यह एक (पैकेज-) वैश्विक चर का उपयोग करते हुए एक त्वरित हैक है, जिसे जब भी कोई पार्सिंग फ़ंक्शन छोड़ा जाता है तो पुनर्स्थापित किया जाता है। env की प्रतिलिपि Object.create() के साथ पूरी की जाती है।

यहां एक उदाहरण व्याकरण है जो इसका उपयोग व्हाइटस्पेस-परिभाषित ब्लॉकों को ला पायथन को पार्स करने के लिए करता है:

{
  env.indLevel = -1
}

block =
  empty
  ind:ws* &{
    if (ind.length <= env.indLevel) return false;
    env.indLevel = ind.length;
    return true;
  }
  first:statement? rest:indStatement*
  {
    if (first) rest.unshift(first);
    return rest;
  }

indStatement =
  "\n" empty ind:ws* &{ return env.indLevel === ind.length; }
  stm:statement
  {return stm; }

statement =
    id:identifier ws* ":" ws* "\n"
    bl:block { return [id, bl]; }
  / identifier

identifier = s:[a-z]* { return s.join(""); }

empty = (ws* "\n")*

ws = [ \t\r]

परिणामी पार्सर के लिए एक उदाहरण इनपुट यहां दिया गया है:

b:
   c
   d:
       e
   f
g

मुझे लगता है कि PEG.js नियमों पर किसी भी प्रकार के मापदंडों का समर्थन नहीं करता - जो आश्चर्यजनक है। यह फीचर मेरे लिए बहुत महत्वपूर्ण है।

मुझे जो चाहिए वह ओपी के अनुरोध से आसान है - ओपी पैरामीटर के आधार पर व्याकरण को स्वयं संशोधित करना चाहता है, लेकिन कम से कम मुझे नियम में एक पूर्णांक पारित करने की आवश्यकता है। मूल रूप से मैं एक एलएलएलपीजी नियम का अनुवाद करना चाहता हूं जो इस तरह दिखता है (जहां PrefixExpr एक उच्च-प्राथमिकता अभिव्यक्ति है जैसे -x , या एक पहचानकर्ता ...):

@[LL(1)]
rule Expr(context::Precedence)::LNode @{
    {prec::Precedence;}
    e:PrefixExpr(context)
    greedy
    (   // Infix operator
        &{context.CanParse(prec=InfixPrecedenceOf(LT($LI)))}
        t:(NormalOp|BQString|Dot|Assignment)
        rhs:Expr(prec)
        { ... }
    |   // Method_calls(with arguments), indexers[with indexes], generic!arguments
        &{context.CanParse(P.Primary)}
        e=FinishPrimaryExpr(e)
    |   // Suffix operator
        ...
    )*
    {return e;}
};
// Helper rule that parses one of the syntactically special primary expressions
@[private] rule FinishPrimaryExpr(e::LNode)::LNode @{
(   // call(function)
    "(" list:ExprList(ref endMarker) ")"
    { ... }
    |   // ! operator (generic #of)
        "!" ...
    |   // Indexer / square brackets
        {var args = (new VList!LNode { e });}
        "[" args=ExprList(args) "]"
        { ... }
    )
    {return e;}
};

मेरी भाषा में 25 प्राथमिकता स्तर हैं, और इन नियमों के साथ मैंने उनमें से लगभग सभी को एक ही नियम द्वारा संसाधित करने के लिए ध्वस्त कर दिया है (आप Precedence को एक पूर्णांक के एक जोड़े के चारों ओर एक आवरण के रूप में सोच सकते हैं जो एक की पूर्वता का वर्णन करता है ऑपरेटर)। इसके अलावा, मेरी भाषा में ऑपरेटरों की एक अनंत संख्या है (मूल रूप से विराम चिह्न का कोई भी क्रम) और एक ऑपरेटर की प्राथमिकता को पार्स करने के बाद तय किया जाता है। जबकि भाषा को सामान्य तरीके से पार्स करना _तकनीकी रूप से संभव होगा, 25 प्रकार के ऑपरेटर में से प्रत्येक के लिए एक अलग नियम के साथ, यह करने का एक भयानक तरीका होगा।

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

तो ... क्या पीईजी.जेएस नियम में पैरामीटर पास करने का कोई तरीका है?

+1! मेरे मामले में, मैं बस एक सिंटैक्स के लिए एक पार्सर उत्पन्न करना चाहता हूं, जहां कुछ सीमांकक विश्व स्तर पर विन्यास योग्य हैं। इस मामले में, मैं एक विधेय के साथ संयुक्त किसी भी भाव से मिलान करके सीमांकक शाब्दिक को बदलकर इसे प्राप्त कर सकता हूं, लेकिन यह बहुत अधिक सुरुचिपूर्ण (और अधिक कुशल) होगा यदि मैच-सब कुछ बस एक चर द्वारा प्रतिस्थापित किया जा सकता है।

+1, इसे निकट भविष्य में लागू होते देखने का कोई मौका?

एक और उपयोग-मामला। यह आपके javascript.pegjs उदाहरण से है:

(...)

RelationalExpression
  = head:ShiftExpression
    tail:(__ RelationalOperator __ ShiftExpression)*
    { return buildBinaryExpression(head, tail); }

RelationalOperator
  = "<="
  / ">="
  / $("<" !"<")
  / $(">" !">")
  / $InstanceofToken
  / $InToken

RelationalExpressionNoIn
  = head:ShiftExpression
    tail:(__ RelationalOperatorNoIn __ ShiftExpression)*
    { return buildBinaryExpression(head, tail); }

RelationalOperatorNoIn
  = "<="
  / ">="
  / $("<" !"<")
  / $(">" !">")
  / $InstanceofToken

(...)

  (...)
  / ForToken __
    "(" __
    init:(ExpressionNoIn __)? ";" __
    test:(Expression __)? ";" __
    update:(Expression __)?
    ")" __
    body:Statement
  (...)

(...)

ये सभी ...NoIn नियम (और उनमें से बहुत सारे हैं) केवल for in कथन के कारण आवश्यक हैं। इसके लिए एक बेहतर तरीका कुछ ऐसा नहीं होगा:

(...)

RelationalExpression<allowIn>
  = head:ShiftExpression
    tail:(__ RelationalOperator<allowIn> __ ShiftExpression)*
    { return buildBinaryExpression(head, tail); }

RelationalOperator<allowIn>
  = "<="
  / ">="
  / $("<" !"<")
  / $(">" !">")
  / $InstanceofToken
  / &{ return allowIn; } InToken
    {return "in";}

(...)

  (...)
  / ForToken __
    "(" __
    init:(Expression<false> __)? ";" __
    test:(Expression<true> __)? ";" __
    update:(Expression<true> __)?
    ")" __
    body:Statement
  (...)

(...)

यह बहुत कुछ वैसा ही लगता है जैसे, उदाहरण के लिए, जावास्क्रिप्ट व्याकरण निर्दिष्ट किया गया है: https://tc39.github.io/ecma262/#prod -IterationStatement ( ~In पर ध्यान दें)

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

क्या नियमों की नकल किए बिना इसे हासिल करने का कोई वैकल्पिक तरीका है?

+1, इसे निकट भविष्य में लागू होते देखने का कोई मौका?

इस मुद्दे को एक मील का पत्थर सौंपा गया है (पोस्ट-1.0.0)। PEG.js का वर्तमान संस्करण 0.10.0 है। जाहिर है, 1.0.0 के बाद के मुद्दों को 1.0.0 जारी करने के बाद निपटाया जाएगा, जो कि रोडमैप के अनुसार 0.11.0 जारी करने के बाद किसी बिंदु पर होगा।

यह आपके प्रश्न का उत्तर देना चाहिए। पूरी प्रक्रिया में तेजी लाने का सबसे अच्छा तरीका 0.11.0 और 1.0.0 के लिए लक्षित मुद्दों में मदद करना है।

क्या नियमों की नकल किए बिना इसे हासिल करने का कोई वैकल्पिक तरीका है?

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

दो प्रकार के तर्क हैं जिन्हें पार्सर्स को पारित किया जा सकता है:

1. मान। पायथन, निम और हास्केल (और एक अलग तरीके से भी योजना) जैसी भाषाओं के व्याकरण पेड़ के अंदर अभिव्यक्ति की "गहराई" पर निर्भर करते हैं। सही व्याकरण लिखने के लिए किसी तरह इस संदर्भ को पारित करना होगा।
2. पार्सर्स। leftAssociative(element, separator) , escapedString(quote) और withPosition(parser) इसके अच्छे उदाहरण हैं।

किसी भी तरह यह चिह्नित करने का तरीका होना चाहिए कि तर्क एक पार्सर या मूल्य है या नहीं। जब मैंने सही दृष्टिकोण का पता लगाने की कोशिश की, तो मैंने संदर्भ के लिए वैश्विक चर का उपयोग करना समाप्त कर दिया, और यह स्पष्ट रूप से एक मृत अंत है। क्या किसी के पास उस पर कोई विचार है?

मैक्रोज़ के बारे में कैसे?

दिया गया:

Add <Expression, Add>
  = left:Expression _ '+' _ right:Add
    { return { type: 'add', left, right } }
  / Expression

कब:

  = Add <MyExpression, MyAdd>

MyExpression
  = [0-9]+

फिर:

  = left:MyExpression _ '+' _ right:MyAdd
    { return { type: 'add', left, right } }
  / MyExpression

MyExpression
  = [0-9]+

यह हमें नीचे से ऊपर तक नियम बनाने की अनुमति देता है :smirk:

मैं सहमत हूं, मैं अनुशंसा करता हूं कि डेवलपर्स इस सुविधा को जोड़ें :)

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

@samvv मैं इसे एक बहुत ही अलग मार्ग से आया हूं, और अभी तक पूरा धागा नहीं पढ़ा है।
हालाँकि, #572 में, जिसका मैंने यहाँ उल्लेख किया है, मैं एक ऐसी तकनीक दिखा रहा हूँ जिसके साथ आप पैरामीटरयुक्त नियमों का अनुकरण कर सकते हैं।

अर्थात्, संक्षेप में: मध्यवर्ती पार्स परिणामों के रूप में वापसी कार्य ।

वह "चाल" किसी भी तरह से मेरा आविष्कार नहीं है, और शायद आपके उद्देश्य के लिए शायद मुझे लगता है। लेकिन यह आपके लिए वर्कअराउंड हो सकता है। मेरा मतलब है "पोस्ट v1.0" तक ... :)

@meisl कूल, टिप के लिए धन्यवाद! जब मुझे कुछ समय मिलेगा तो इसे आजमाएंगे।

@samvv ओह, आह ... मुझे डर है कि मैंने कुछ महत्वपूर्ण अनदेखी की है:

इससे काफी फर्क पड़ता है कि क्या आप पैरामीटरयुक्त नियम को चाहते हैं

• केवल मान उत्पन्न करने में सक्षम हो, जो पैरामीटर पर निर्भर करता है
• या (भी) इसके पार्सिंग निर्णय पैरामीटर पर निर्भर करते हैं

जो मैं प्रस्तावित कर रहा था वह केवल पूर्व के साथ मदद करता है - जबकि बाद वाला ओपी की वास्तविक समस्या है ...
उसके लिए खेद है।

हालाँकि, बाद वाले के लिए भी एक समाधान है , भले ही वह और भी अधिक क्लिंकर हो।
और, "आश्रित निर्णय" भाग का रिटर्निंग फ़ंक्शंस से कोई लेना-देना नहीं है ...

मैं आपके लिए https://pegjs.org/online में एक उदाहरण जोड़ रहा हूं

मूल विचार है: वर्तमान "टर्मिनेटर" को याद रखने के लिए वैश्विक स्थिति का उपयोग करें। यह काफी हैक है, बेशक, और दोहराव।
लेकिन: एक और सीमांकक जोड़ना, कहें | का अर्थ केवल str में एक और विकल्प जोड़ना होगा:

  / (t:'|' {term = t}) c:conts t:.&{ return isT(t) }  { return c }

जो केवल उसी एक चरित्र में दूसरों से अलग है |

{
  var term;
  function isT(ch) { return ch === term }
  function isE(ch) { return ch === '\\' }
}
start = str*

str
  = (t:'\"' {term = t}) c:conts t:.&{ return isT(t) }  { return c }
  / (t:'\'' {term = t}) c:conts t:.&{ return isT(t) }  { return c }

conts
  = c:(
        '\\' t:.&{ return isT(t) || isE(t) } { return t }
      /      t:.!{ return isT(t)           } { return t }
    )*
    { return c.join('') }

... इनपुट पर

• "abc" -> ["abc"]
• "a\"bc" -> ["a\"bc"]
• "a\\bc" -> ["a\bc"]
• "a\\b\"c"'a\\b\'' -> ["a\b\"c", "a\b'c"]

पीएस: यह वास्तव में ऐसा कुछ नहीं है जिसे कोई हाथ से लिखना चाहेगा, मुझे पता है। लेकिन हे, कल्पना कीजिए कि यह आपके लिए उत्पन्न होगा... मुझे लगता है कि सिद्धांत रूप में ऐसा ही है।

@ceymard - मुझे एहसास है कि यह दस साल बाद है, लेकिन मैं उत्सुक हूं कि यह # 36 . से अलग कैसे है

वाह मुझे याद करने में थोड़ा समय लगा। 10 वर्ष !

इस पीआर में, नियम तर्क लेते हैं और उन्हें पैरामीट्रिज किया जा सकता है। इसका उपयोग व्याकरण द्वारा ही किया जाता है ताकि समान-लेकिन-अलग-अलग नियमों को दोहराने से बचा जा सके।

#36 में, नियम व्याकरण के बाहर ही निर्दिष्ट हैं। इस प्रकार व्याकरण स्वयं पैरामीट्रिज्ड होता है।

मुझे लगता है कि दायरा अलग है, हालांकि कोई यह तर्क दे सकता है कि व्याकरण स्वयं एक नियम है और इस प्रकार यह वही मुद्दा है। मुझे लगता है कि ऐसा नहीं है, क्योंकि #36 का अर्थ शायद कुछ मामूली एपीआई परिवर्तन होगा, जबकि यह पीआर नहीं होगा।

तो, सी ++ ईश शब्दावली का गहराई से गलत तरीके से दुरुपयोग करने के लिए, पूर्व टेम्पलेट स्टेटिक्स हैं, जबकि बाद वाले कन्स्ट्रक्टर कॉल हैं?

मुझे लगता है कि यह सादृश्य कुछ हद तक काम करता है, हाँ।

स्पष्टीकरण में आपके समय के लिए धन्यवाद

मैं शायद दस साल में आपके लिए एक और सवाल करूंगा। 2020 का दशक अच्छा रहे

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