Pegjs: अनुक्रम से एकल वापसी मूल्य को इंगित करने के लिए एक संक्षिप्त तरीका प्रदान करें

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

मैं इस मुद्दे को खुला रखूंगा और 1.0.0 के बाद इसे विचार के लिए चिह्नित करूंगा।

माना। मैं वास्तव में इसे 1.0 में देखना चाहता हूं। हालांकि मैं @ वाक्यविन्यास के बारे में इतना उत्साहित नहीं हूं। आईएमएचओ ऐसा करने का एक बेहतर विचार होगा: यदि केवल एक "शीर्ष स्तर" लेबल है तो उस लेबल को स्पष्ट रूप से वापस कर दें। तो इसके बजाय:

rule = space* a:(text space+ otherText)+ newLine* { return a; }

आपको मिला:

rule = space* a:(text space+ otherText)+ newLine*

और जब लेबल विशेष रूप से सार्थक कुछ भी नहीं है, तो इसकी अनुमति दें:

rule = space* :(text space+ otherText)+ newLine*

इसलिए लेबल नाम को बिल्कुल छोड़ दें।

@mulderr मुझे लगता है कि @ ऑपरेटर बेहतर है, क्योंकि कुछ करने का मतलब यह है कि अगर मैं किसी और के कोड को पढ़ता हूं जो उस सुविधा का उपयोग करता है, तो मुझे यह समझने से पहले कि उसने वहां क्या किया है, मुझे काफी गुगल से गुजरना होगा। इसके विपरीत, एक स्पष्ट ऑपरेटर का उपयोग करने से मुझे दस्तावेज़ों को जल्दी से खोजने की अनुमति मिल जाएगी।

+1 के लिए @ - यह मेरे पूरे कोड में बहुत कुछ रिकर्स करता है।

ऐसा करने के कुछ संक्षिप्त तरीके के लिए +1।

ऐसा लगता है कि यह दर्द JS में वर्बोज़ function सिंटैक्स के समान है, जिसे ES6 एरो फ़ंक्शंस का उपयोग करके संबोधित

rule = (space* a:(text space+ otherText) newLine*) => a

मुझे लगता है कि यह बहुत लचीला है, अभी भी स्पष्ट है (एक ला @wildeyes की चिंता), और जटिलता जोड़ने की तरह कम लगता है क्योंकि सिंटैक्स और कार्यान्वयन दोनों में यह अंतर्निहित जेएस को रोकता है ...

मैं कुछ इस तरह चित्रित कर रहा हूं:

additive = left:multiplicative "+" right:additive {= left + right; }

जहां = (चरित्र की पसंद पर बहस करने के लिए स्वतंत्र महसूस करें) एक ब्लॉक के पहले गैर-व्हाट्सएप चरित्र के रूप में return में बदल दिया जाता है।

यह पूर्ण अभिव्यक्तियों के लिए भी काम करेगा और परिवर्तन पास के साथ संभव होना चाहिए।

कोई खबर? additive = left:multiplicative "+" right:additive { => left + right } क्यों नहीं?

यह निश्चित रूप से सहज महसूस करेगा कि तीर कैसे काम करता है ( (left, right) => left + right )।

आपकी parser.pegjs फ़ाइल में वास्तव में स्थानों के कुछ उदाहरण हैं जिन्हें इस सुविधा द्वारा बेहतर बनाया जाएगा।

उदाहरण के लिए:

  = head:ActionExpression tail:(__ "/" __ ActionExpression)* {
      return tail.length > 0
        ? {
            type: "choice",
            alternatives: buildList(head, tail, 3),
            location: location()
          }
        : head;
    }

बिल्डलिस्ट कॉल में मैजिक नंबर 3 के कारण नाजुक है जो अनुक्रम में आपके एक्शनएक्सप्रेस की स्थिति से गैर-सहज रूप से जुड़ा हुआ है। दो अलग-अलग ऑपरेशनों को मिलाकर बिल्डलिस्ट फ़ंक्शन स्वयं जटिल है। @ एक्सप्रेशन और es6 स्प्रेड सिंटैक्स का उपयोग करके, यह क्लीनर बन जाता है:

  = head:ActionExpression tail:(__ "/" __ @ActionExpression)* {
      return tail.length > 0
        ? {
            type: "choice",
            alternatives: [head, ...tail],
            location: location()
          }
        : head;
    }

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

  = ExtractSequenceExpression
  / expression:SequenceExpression code:(__ CodeBlock)? {
      return code !== null
        ? {
            type: "action",
            expression: expression,
            code: code[1],
            location: location()
          }
        : expression;
    }

ExtractExpression
  = "@" __ expression:PrefixedExpression {
      return {
        type: "labeled",
        label: "value",
        expression: expression,
        location: location()
      };
    }

ExtractSequenceExpression
  = head:(__ PrefixedExpression)* _ extract:ExtractExpression tail:(__ PrefixedExpression)* {
      return {
        type: "action",
        expression: {
          type: "sequence",
          elements: extractList(head, 1).concat(extract, extractList(tail, 1)),
          location: location()
        },
        code: "return value;",
        location: location()
      }
    }

मैंने एक सार में जाँच की जो दिखाता है कि कैसे @ नोटेशन का उपयोग करके parser.pegjs को सरल बनाया जाएगा।

ExtractOptional, ExtractList और buildList फ़ंक्शंस पूरी तरह से हटा दिए गए हैं, क्योंकि @ नोटेशन अनुक्रम से वांछित मान निकालने के लिए इसे छोटा बनाता है।

https://gist.github.com/krisnye/a6c2aac94ffc0e222754c52d69e44b83

@krisnye यहां बताया गया है कि अगर और भी सिंटैक्स चीनी होती तो यह कैसा दिखता:

https://github.com/polkovnikov-ph/newpeg/blob/master/parse.np

मैं इस सिंटैक्स सुविधा के लिए :: और # के संयोजन का उपयोग करने के बारे में सोच रहा हूं ( #545 में मेरा स्पष्टीकरण/कारण देखें):

• :: बाइंडिंग ऑपरेटर
• # विस्तार ऑपरेटर

// this is imported into grammar
class List extends Array {
  constructor() { this.isList = true; }
}

// grammar
number = _ ::value+ _
value = ::int #(_ "," _ ::int)* { return new List(); }
int = $[0-9]+
_ = [ \t]*

• नियम के मूल अनुक्रम पर, :: नियम परिणाम के रूप में अभिव्यक्ति का परिणाम लौटाएगा
• नेस्टेड अनुक्रम में, :: नेस्टेड एक्सप्रेशन का परिणाम अनुक्रम परिणाम के रूप में लौटाएगा
• यदि अधिक है तो एक :: का उपयोग किया जाता है, चिह्नित अभिव्यक्तियों का परिणाम एक सरणी के रूप में वापस किया जाएगा
• यदि # का उपयोग नेस्टेड अनुक्रम पर किया जाता है जिसमें :: , तो परिणाम माता-पिता की सरणी में धकेल दिए जाएंगे
• यदि नियम में :: / # के साथ एक कोड ब्लॉक है, तो पहले इसे निष्पादित करें, फिर परिणाम push विधि का उपयोग करें

इन नियमों का पालन करते हुए, उपरोक्त उदाहरण के जेनरेट किए गए पार्सर को 09 , 55, 7 करने से प्राप्त होगा:

result = [
    isList: true
    0: "09"
    1: "55"
    2: "7"
]

result instanceof Array # true in ES2015+ enviroments
result instanceof List # true

नियम के मूल अनुक्रम पर :: नियम परिणाम के रूप में अभिव्यक्ति का परिणाम लौटाएगा
नेस्टेड अनुक्रम में, :: अनुक्रम परिणाम के रूप में नेस्टेड अभिव्यक्ति का परिणाम लौटाएगा

ये अलग क्यों हैं? क्यों न केवल " :: एक अनुक्रम पर अनुक्रम के तर्क परिणाम का परिणाम बनाता है"?

यदि अधिक है तो एक :: का उपयोग किया जाता है, चिह्नित अभिव्यक्तियों का परिणाम एक सरणी के रूप में वापस कर दिया जाएगा।

यह एक बुरा विचार है। बल्कि इस मामले में जमानत हो जाएगी। कई प्रकार के मानों को एक सरणी में संयोजित करने का कोई अर्थ नहीं है। (यह एक टुपल होगा, लेकिन वे जेएस में काफी बेकार हैं।)

यदि अनुक्रम पर # का उपयोग किया जाता है, तो परिणाम Array#concat'ed को माता-पिता के सरणी में जोड़ दिया जाएगा

अब यह एक भयानक विचार है। यह स्पष्ट रूप से बाहरी { return xs.push(x), xs } छुटकारा पाने के लिए एक कीचड़ है। ऐसा विशेष मामला बनाने का कोई मतलब नहीं है, क्योंकि इसे सामान्य तरीके से पैरामीटरयुक्त नियमों के साथ हल किया जा सकता है। ऑपरेटरों के लिए उपयोग करने के लिए बहुत सारे सिंगल-चार अनुक्रम नहीं हैं, और हमें उन्हें बर्बाद नहीं करना चाहिए।

यदि नियम में ::/# के साथ एक कोड ब्लॉक है, तो इसे पहले निष्पादित करें, फिर परिणाम पुश विधि का उपयोग करें

तो परिणाम के रूप में f = ::"a" { return "b" } में ["a", "b"] होना चाहिए?

09 गुजर रहा है। 55: 7 उपरोक्त उदाहरण के लिए उत्पन्न पार्सर प्राप्त करेगा:

ऐसा नहीं होगा, कोई . या : उल्लेखित नहीं है। मैं नहीं देखता कि वर्णित व्यवहार कैसे परिणाम उत्पन्न करेगा।

संख्या = _ :: मान+ _

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

start = _ value
value = ::int #("," _ ::int)* { return new List(); }
number = ::$[0-9]+ _
_ = [ \t]*

जावास्क्रिप्ट उदाहरण में कार्यान्वित कक्षाओं का एक उदाहरण (वास्तविक कार्यान्वयन के लिए नहीं):

ClassMethod
  = head:FunctionHead __ params:FunctionParameters __ body:FunctionBody {
      return {
        type: "method",
        name: head[ 1 ],
        modifiers: head[ 0 ],
        params: params,
        body: body
      };
    }

// `::` inside the zero_or_more "( ... )*" builds an array as we want,
// so this rule returns `[FunctionModifier[], Identifier]` as expected
MethodHead = (::MethodModifier __)* ("function" __)? ::Identifier

// https://github.com/tc39/proposal-class-fields#private-fields
MethodModifier
  = "#"
  / "static"
  / "async"

FunctionParameters
  = "(" __ head:FunctionParam tail:(__ "," __ ::FunctionParam)* __ ")" {
      // due to `::`, tail is `FunctionParam[]` instead of `[__, "", __, FunctionParam][]`
      return [ head ].concat( tail );
    }
    / "(" __ ")" { return []; }

FunctionParam
  = name:Identifier value:(__ "=" __ ::Expression)? {
      return { name, value };
    }

FunctionBody = "{" __ ::SourceElements? __ "}"

ये अलग क्यों हैं? अनुक्रम पर केवल :: क्यों नहीं अनुक्रम के तर्क परिणाम का परिणाम बनाता है"?

क्या यह वही बात नहीं है? मैंने इसे और अधिक स्पष्ट किया है ताकि MethodHead , FunctionParam और FunctionBody जैसे विभिन्न उपयोग मामलों के परिणाम को आसानी से समझा जा सके।

कई प्रकार के मानों को एक सरणी में संयोजित करने का कोई अर्थ नहीं है। (यह एक टुपल होगा, लेकिन वे जेएस में काफी बेकार हैं।)

एएसटी (जेनरेट किए गए पार्सर का सबसे आम परिणाम) बनाते समय, मेरी राय में, यह लिखने के बजाय MethodHead जैसे उपयोग के मामलों को सरल बना देगा:

MethodHead
  = modifiers:(::MethodModifier __)* ("function" __)? name:Identifier {
      return [ modifiers, name ];
    }

हालांकि इसे और अधिक सोचने के बाद, हालांकि यह उपयोग के मामले को सरल बनाता है, यह डेवलपर की गलती करने की संभावना को भी खोलता है (या तो जिस तरह से वे अपने व्याकरण को लागू करते हैं, या परिणामों को क्रियाओं द्वारा कैसे नियंत्रित किया जाता है), इसलिए मुझे लगता है इसे डालना multipleSingleReturns जैसे विकल्प के पीछे केस का उपयोग करें (डिफ़ॉल्ट: false ) यहां कार्रवाई का सबसे अच्छा तरीका होगा (यदि यह सुविधा लागू हो जाती है तो)।

यदि अनुक्रम पर # का उपयोग किया जाता है, तो परिणाम Array#concat'ed को माता-पिता के सरणी में जोड़ दिया जाएगा

अब यह एक भयानक विचार है। यह स्पष्ट रूप से बाहरी से छुटकारा पाने के लिए एक कीचड़ है {वापसी xs.push (x), xs}

यह अधिक सामान्य उपयोग के मामलों में भी मदद करता है जैसे FunctionParameters जहां यह लिखना अच्छा होगा:

// should always return `FunctionParam[]`
FunctionParameters
  = "(" __ ::FunctionParam #(__ "," __ ::FunctionParam)* __ ")"
  / "(" __ ")" { return []; }

इसे सामान्य तरीके से पैरामीटरयुक्त नियमों के साथ हल किया जा सकता है

मैं सोच रहा हूं कि मुझे पैरामीटरयुक्त नियमों से पहले सिंगल रिटर्न वैल्यू लागू करना चाहिए क्योंकि मुझे अभी भी यकीन नहीं है कि बाद में कैसे आगे बढ़ना है (मुझे टेम्पलेट्स का उपयोग करना पसंद है, लेकिन rule < .., .. > = .. का उपयोग करना बहुत शोर जोड़ता है पीईजी.जेएस व्याकरण, इसलिए मैं इसे बेहतर तरीके से फिट करने के लिए थोड़ा सा वाक्यविन्यास परिवर्तन के बारे में सोचने की कोशिश कर रहा हूं), लेकिन यह एक अलग मुद्दा है।

ऑपरेटरों के लिए उपयोग करने के लिए बहुत सारे सिंगल-चार अनुक्रम नहीं हैं, और हमें उन्हें बर्बाद नहीं करना चाहिए।

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

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

तो परिणाम के रूप में f = ::"a" { return "b" } में ["a", "b"] होना चाहिए?

नहीं, क्योंकि पार्सर द्वारा कोड ब्लॉक की अपेक्षा की जाती है कि वह एक सरणी-जैसी वस्तु लौटाए जिसमें push विधि हो (इसलिए यह f = ::"a" { return [ "b" ] } परिणाम के रूप में [ "b", "a" ] लौटाएगा), इसलिए न केवल सरणियों में धकेलने की अनुमति देता है, बल्कि कस्टम नोड्स जिनके पास समान तरीके से काम करने के लिए समान विधि लागू होती है। यह देखने के बाद कि यह पढ़ने के बाद आपके विचार की पहली ट्रेन कैसी थी, क्या यह समझना बेहतर होगा कि क्या यह pushSingleReturns जैसे विकल्प के पीछे था? यदि यह विकल्प false (डिफ़ॉल्ट) है, तो एक अनुक्रम के बाद एक कोड ब्लॉक होने से जिसमें एकल रिटर्न मान होते हैं, एक त्रुटि होगी।

09 गुजर रहा है। 55: 7 उपरोक्त उदाहरण के लिए उत्पन्न पार्सर प्राप्त करेगा:

ऐसा नहीं होगा, कोई . या : उल्लेखित नहीं है।

क्षमा करें, यह एक गलती थी जो मैंने दिए गए उदाहरण को फिर से लिखने पर छोड़ दी थी।

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

मुझे लगता है कि यह वास्तव में वरीयता का मामला है: मुस्कान:, हालांकि मुझे लगता है कि इस उदाहरण को समझना आसान होगा:

number = _ ::value+ EOS
...
EOS = !.

मैं नहीं देखता कि वर्णित व्यवहार कैसे परिणाम उत्पन्न करेगा।

क्या यह अद्यतन टिप्पणी यह ​​समझने में मदद करती है कि मैं क्या कहना चाह रहा हूं, और यदि नहीं, तो आप क्या नहीं समझते हैं।

मैं @ polkovnikov-ph से सहमत हूं कि स्थानों द्वारा प्रस्तावित परिवर्तन बेहद स्पष्ट हैं और केवल अतिरिक्त त्रुटियों का स्रोत होंगे।

यदि अनुक्रम पर # का उपयोग किया जाता है, तो परिणाम Array#concat'ed को माता-पिता के सरणी में जोड़ दिया जाएगा

व्याकरण में क्या लौटाया जाना चाहिए start = #('a') ? जहाँ तक मैं समझता हूँ, उसने सोचा कि कैसे समतल सरणियों के लिए सिंटेक्स चीनी? मुझे नहीं लगता कि यह ऑपरेटर आवश्यक है। इसके सबसे स्पष्ट उपयोग के लिए - विभाजकों के साथ सदस्य सूचियों की अभिव्यक्ति - विशेष वाक्यविन्यास बनाना बेहतर है (देखें #30 और मेरा कांटा, https://github.com/Mingun/pegjs/commit/db4b2b102982a53dbed1f579477c85c06f8b92e6)।

यदि नियम में ::/# के साथ एक कोड ब्लॉक है, तो इसे पहले निष्पादित करें, फिर परिणाम पुश विधि का उपयोग करें

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

शेष 3 बिंदु जिनका आप वर्णन करने में कामयाब रहे, ताकि उनकी स्पष्ट समझ छूटने लगे। कैसे सही ढंग से नोट किया @ polkovnikov-ph पहले और दूसरे मामले को अलग करने के लिए विवरण में क्यों था? केवल दो सरल नियमों को क्रियान्वित किया जाएगा:

1. :: (स्पष्ट रूप से, मुझे इस चरित्र की पसंद पसंद नहीं है, बहुत शोर है) इससे पहले कि अभिव्यक्ति इस तथ्य की ओर ले जाती है कि sequence नोड तत्वों से इस चरित्र वापसी के साथ चिह्नित किया गया है
2. यदि अनुक्रम में केवल एक ही ऐसा तत्व है, तो इसका परिणाम वापस आ जाता है, अन्यथा परिणामों की सरणी वापस आ जाती है

उदाहरण:

start =   'a' 'b'   'c'; // => ['a', 'b', 'c']
start = ::'a' 'b'   'c'; // => 'a'
start = ::'a' 'b' ::'c'; // => ['a', 'c']

बड़ा उदाहरण ठीक वही वर्णन करता है जो मैं :: से देखने की अपेक्षा करता हूं और संदिग्ध उपयोग के मामलों ( # , कई :: ) का वर्णन नहीं करता है।

क्या यह वही बात नहीं है?

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

मेरी राय में, यह मेथडहेड जैसे उपयोग के मामलों को आसान बना देगा

लेकिन इसके बजाय ऑब्जेक्ट क्यों नहीं बनाते? नोटेशन में modifiers: और name: , परिणामी JS ऑब्जेक्ट में उन्हें छोड़ दें, और यह अच्छा होगा।

यह डेवलपर की गलती करने की संभावना को भी खोलता है (या तो जिस तरह से वे अपने व्याकरण को लागू करते हैं, या परिणाम कैसे क्रियाओं द्वारा नियंत्रित किए जाते हैं)

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

यह अधिक सामान्य उपयोग के मामलों में भी मदद करता है जैसे FunctionParameters जहां यह लिखना अच्छा होगा:

लेकिन यह वही बात है। वास्तव में अच्छा सिंटैक्स होगा inter(FunctionParam, "," __) , साथ

inter a b = x:a xs:(b ::a)* { return xs.unshift(x), xs; }

नियम < .., .. > = .. PEG.js व्याकरण में बहुत अधिक शोर जोड़ने लगता है

लोग <...> प्रकार के लिए उपयोग किए जाने की अपेक्षा करते हैं, जबकि इस मामले में तर्क प्रकार नहीं हैं। सबसे अच्छा तरीका हास्केल तरीका है बिना किसी अतिरिक्त वर्ण के (ऊपर inter )। मुझे यकीन नहीं है कि यह ; छोड़े गए PEG.js व्याकरण में कैसे इंटरैक्ट करता है। ऐसा कोई मामला हो सकता है जब f a b = ... पिछली पंक्ति में शामिल हो जाता है (आंशिक रूप से)।

कुछ भाषाओं में एक विस्तार ऑपरेटर के रूप में उपयोग किया जाता है जो प्रीप्रोसेस निर्देशों को लागू करता है

हां, लेकिन मैं इसे स्मार्ट तरीके से इस्तेमाल करूंगा। सरणियों पर प्रस्तावित push कार्रवाई के बजाय, मैं इसे वस्तुओं पर Object.assign कार्रवाई के रूप में उपयोग करूंगा, या यहां तक ​​कि एक ऐसी चीज जो एक खाली स्ट्रिंग ( eps ) से मेल खाती है, लेकिन वापस आती है इसका तर्क। ताकि, उदाहरण के लिए,

f = type:#"ident" name:$([a-z]i [a-z0-9_]i+)

इनपुट के लिए {type: "ident", name: "abc"} लौटाएगा "abc" ।

नहीं, क्योंकि पार्सर द्वारा कोड ब्लॉक की अपेक्षा की जाती है कि वह एक सरणी-जैसी वस्तु लौटाए जिसमें एक पुश विधि हो (इसलिए यह f = ::"a" {वापसी [ "b" ] } रिटर्निंग [ "b", " ए"] परिणाम के रूप में),

ओ_ओ

मुझे लगता है कि यह वास्तव में सिर्फ वरीयता का मामला है

इतना ही नहीं, प्रदर्शन भी। यदि प्रत्येक टोकन में दोनों तरफ _ , तो व्हाइटस्पेस वर्ण अनुक्रम केवल पीछे वाले से मेल खाते हैं, जबकि _ से पहले कुछ भी नहीं के साथ मेल खाते हैं। parse$_ अतिरिक्त कॉल में थोड़ा अतिरिक्त समय लगता है। साथ ही कोड लंबा है क्योंकि इसमें _ s से दोगुना अधिक है।

@Mingun मुझे लगता है कि @futagoza डिज़ाइन स्पेस की पड़ताल करता है। यह एक अच्छी बात है, खासकर अगर यह सार्वजनिक है और हमारे पास असहमत होने का मौका है :)

मुख्य बात "क्यों" पूछना नहीं है, बल्कि यह कहना है कि "नहीं! ऐसा नहीं!"

f = type:#"ident" name:$([a-z]i [a-z0-9_]i+) इनपुट "abc" लिए {type: "ident", name: "abc"} लौटाएगा।

कृपया नहीं, हाहा। वह वाक्य रचना _wayyy_ बहुत जादुई है।

मुझे लगता है कि मूल रूप से प्रस्तावित @ ऑपरेटर बिल्कुल सही है। इतने सारे, कई बार मैं अनुक्रम समस्या में भाग लेता हूं:

sequence
    = first:element rest:(whitespace next:element {return next;})*
    {
        return [first].concat(rest);
    }
    ;

_ऐसा_ बार-बार टाइप करने के लिए एक दर्द, खासकर जब वे इससे कहीं अधिक जटिल हों।

हालांकि, @ ऑपरेटर के साथ, उपरोक्त सरल हो जाता है:

sequence = first:element rest:(whitespace @element)* { return [first].concat(rest); };

और या तो https://github.com/pegjs/pegjs/issues/235#issuecomment -66915879 या https://github.com/pegjs/pegjs/issues/235#issuecomment -67544080 के साथ जो और कम हो जाता है:

sequence = first:element rest:(whitespace @element)* => [first].concat(rest);
/* or */
sequence = first:element rest:(whitespace @element)* {=[first].concat(rest)};

... जिनमें से पहला मैं बहुत आंशिक हूं।

ऐसा लगता है कि यह एक पिछड़ा संगत परिवर्तन होगा जिसे हासिल करना आसान होगा (ऐसा प्रतीत होता है कि किसी ने इसे पहले ही कर लिया है)।

वास्तव में, अगर मैं गलत नहीं हूँ, तो यह एक मामूली टक्कर हो सकती है। 0.11.0 @futagoza के बारे में सोचने के लिए कुछ हो सकता है।

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

मैंने इसे कुछ समय पहले ही लागू करना शुरू कर दिया था, लेकिन इसे अब तक छोड़ दिया (जब मुझे इसके बजाय #579 करना चाहिए) और मिंगुन के कार्यान्वयन पर बाइटकोड जनरेटर आधारित (https://github.com/Mingun/pegjs/commit/1c1c852bae91868eaa90d9bd9f7e4f722aa6435e )

आप इसे यहां आजमा सकते हैं: https://pegjs.org/Development/try (ऑनलाइन संपादक, लेकिन पीईजी 0.11.0-देव का उपयोग करके)

पवित्र बदलाव का समय, बैटमैन। बहुत बढ़िया काम @futagoza , इसने पूरी तरह से काम किया - बहुत सराहना की। क्या यह पहले से ही npm पर dev टैग के लिए जारी किया गया था? मुझे इसके साथ परीक्षण शुरू करना अच्छा लगेगा।

जो कोई भी इसे बुनियादी व्याकरण के साथ आज़माना चाहता है, उसके लिए इस पिल्ला को वहाँ रखें और इसे "abcd" जैसा इनपुट दें।

foo
    = '"' @$bar '"'
    ;

bar
    = [abcd]*
    ;

क्या यह पहले से ही npm पर देव टैग के लिए जारी किया गया था?

https://www.npmjs.com/package/pegjs/v/0.11.0-dev.325

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

यह टिकट मर्ज किया गया

pattern:Pattern init:(_ "=" _ <strong i="7">@a</strong>:AssignmentExpression)?

ES6 में वही बात, जिसे हर कोई स्वाभाविक रूप से समझेगा, और जो पार्सर के अन्य भागों के समाप्त होने पर मुफ्त में आता है, वह है

pattern:Pattern init:(_ "=" _ a:AssignmentExpression)? => a

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

कृपया इस मुद्दे को फिर से खोलें, @futagoza , जब तक कि इसे जारी किए गए संस्करण में ठीक नहीं किया जाता है