Pegjs: अन्य व्याकरण आयात/शामिल करें

मैं सहमत हूं कि यह एक महत्वपूर्ण विशेषता है, मैं इसे संस्करण 1.0 के बाद करना चाहता हूं।

(बीटीडब्ल्यू मुझे आपके द्वारा प्रस्तावित पायथन-जैसे सिंटैक्स पसंद नहीं है - नोड.जेएस के require समान कुछ बेहतर होगा क्योंकि यह जावास्क्रिप्ट प्रोग्रामर के लिए अधिक परिचित होगा। लेकिन यह एक छोटी सी चीज है जिसे इस्त्री किया जा सकता है बाद में बाहर।)

क्या आप इसे 1.0 से पहले शामिल करने पर विचार करेंगे यदि पैच प्रदान किया जाता है?

मैं पायथन सिंटैक्स के बारे में आपकी टिप्पणी से सहमत हूं।

इस सुविधा के लिए +1

@ceymard हाँ, मैं इस पर विचार करूंगा।

सुविधा के लिए +1 और require शैली समावेशन के लिए +1

@dmajda @ceymard क्या आपके पास पहले से ही कोई विचार है कि इसे कैसे कार्यान्वित किया जाए? मुझे काम पर एक परियोजना के लिए इसकी आवश्यकता है और मैं इसे लागू करने का प्रयास करूंगा। सवाल यह है कि क्या यह व्याकरण को कई फाइलों में विभाजित करने या विरासत की तरह कुछ करने के लिए एक अतिरिक्त होना चाहिए, इसलिए कोई भी उदाहरण के लिए सभी नियमों को प्राप्त कर सकता है और फिर नए व्याकरण में विशिष्ट नियमों को अधिलेखित कर सकता है।

@Dignifiedquire मैं वर्तमान में वाक्य रचना और शब्दार्थ के बारे में सोच रहा हूँ जिसे शायद एक उदाहरण द्वारा सबसे अच्छी तरह समझाया जा सकता है:

स्थिर-भाषाएँ.pegjs

langauges  = "C" / "C++" / "Java" / "C#"

गतिशील-भाषाएं.pegjs

languages = "Ruby" / "Python" / "JavaScript"

सभी भाषाएं.pegjs

static  = require("./static-languages")
dynamic = require("./dynamic-languages")

all = static.languages / dynamic.languages

प्रत्येक .pegjs फ़ाइल परोक्ष रूप से एक मॉड्यूल को परिभाषित करेगी जो इसमें शामिल सभी नियमों को निर्यात करेगा। <name> = require(<module>) निर्माण ऐसे मॉड्यूल को आयात करेगा। इसके नियम तब नामस्थान के अंदर उपलब्ध होंगे।

यह डिज़ाइन जानबूझकर Node.js के समान है। नेमस्पेस का उपयोग करने से टकराव से बचा जा सकेगा। मैं दो डाउनसाइड देख रहा हूं:

1. <name> = require(<module>) निर्माण नियम परिभाषाओं के समान है और इस प्रकार भ्रमित हो सकता है (कोई सोच सकता है कि केवल एक नियम आयात किया गया है)।
2. . वाक्यविन्यास . के वर्तमान अर्थ के साथ संघर्ष करता है, जो कि "कोई भी वर्ण" है। इसे बदसूरत हैक्स द्वारा हल किया जा सकता है (उदाहरण के लिए . व्हाइटस्पेस से घिरा हुआ है जिसका अर्थ है "कोई भी चरित्र", जबकि पहचानकर्ताओं से घिरे . एक नामस्थान नाम को नियम नाम से अलग करता है) या वाक्यविन्यास को बदलकर (उदाहरण के लिए "किसी भी वर्ण" का प्रतिनिधित्व करने के लिए any कीवर्ड का उपयोग करना)।

@dmajda जैसा कि <identifier> = <expression> पैटर्न पहले से ही नियम परिभाषाओं द्वारा लिया गया है, ऐसा कुछ क्यों न करें:

static := require("./static-languages")
dynamic := require("./dynamic-languages")

all = static::languages / dynamic::languages

:: का उपयोग कहीं भी नहीं किया जाता है जिसे मैं PEG.js में जानता हूं और नामस्थान और अन्य चीजों के बीच अंतर करना आसान बनाता है। मुझे := बारे में निश्चित नहीं है, यह बिंदु को पार करता है लेकिन जावास्क्रिप्ट के लिए बहुत विदेशी लगता है ..

इसके अलावा यदि आप नामस्थान का उपयोग करना चाहते हैं, तो क्या आपको लगता है कि प्रति फ़ाइल केवल एक नामस्थान होना चाहिए या इस तरह की एक फ़ाइल में एकाधिक नामस्थान बनाने का कोई तरीका होना चाहिए:

static := {
  languages  = "C" / "C++" / "Java" / "C#"
}

dynamic := {
  languages = "Ruby" / "Python" / "JavaScript"
}

मैं :: और := प्रशंसक नहीं हूं, वे जावास्क्रिप्ट/कॉफीस्क्रिप्ट दुनिया में विदेशी दिखते हैं।

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

कैसे बस के बारे में:

<strong i="6">@require</strong> foo = "./foo"

bar = foo:languages

कोलन एक समझौता है, लेकिन उनका उपयोग कई जगहों पर नामस्थानों को अलग करने के लिए किया जाता है: सी ++, सी #, एक्सएमएल, आदि।

कई कार्यात्मक प्रोग्रामर के लिए : हमेशा cons साथ जुड़ा रहेगा। मेरा सुझाव है कि उस ऑपरेटर से दूर रहें। :: मुझे ठीक लग रहा है। क्या इसका उपयोग सी ++ नेमस्पेस के लिए नहीं किया जाता है? मैं अभी तक आश्वस्त नहीं हूं कि . एक बुरा विकल्प है, या तो।

. उपयोग बिना किसी बदलाव के नहीं किया जा सकता है। यह भाषा में अस्पष्ट होगा।

:: नामस्थानों के लिए C++ में और नामस्थान उपसर्गों के लिए C# में ( global::System , उदाहरण के लिए) उपयोग किया जाता है।

मैं इस विषय पर एक त्वरित समाधान के बारे में सोच रहा था - केवल साधारण विरासत को हल करने के लिए - गोंद pegjs फ़ाइलों को एक साथ, जबकि सब कुछ नाम दिया गया था।

यह व्याकरण को बहुत अधिक क्रियात्मक बना सकता है, और इसमें एक निर्माण चरण शामिल है - लेकिन उज्ज्वल पक्ष को देखते हुए, यह आपको दानेदार DRY&OTW व्याकरण के लिए मजबूर करेगा

और मार्कअप के संबंध में, यह नहीं कहा जा रहा है कि यह इस धागे के लिए उपयुक्त है, लेकिन विचार करने के लिए सिर्फ एक विकल्प है, मैं एक साधारण के लिए जा रहा था__

languages = static__languages / dynamic__languages
<static-languages.pegjs>
<dynamic-languages.pegjs>
/* alternative */
languages = STATIC__languages / DYNAMIC__languages

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

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

@odonnell +1 कुछ भी जारी करने के लिए - कोई फर्क नहीं पड़ता कि आपके पास इसे साफ करने का समय है

और स्पष्टीकरण के लिए +1। इसे एक त्वरित समाधान के रूप में माना जाना चाहिए, न कि दीर्घकालिक उचित समाधान के रूप में।

@odonnell इस पर मेरा लेना https://github.com/andreineculau/core-pegjs पर ऑनलाइन है - अगर आपके पास कुछ बेहतर है तो कृपया मुझे पोक करें।

इस सुविधा के लिए +1

:+1:

:+1:

:+1:

मैंने जाकर PEG.js के लिए एक प्लगइन/एक्सटेंशन लिखा जो आयात करता है: https://github.com/casetext/pegjs-import।

इसके लिए भी +1।

मैं इसे # 308 में सामान्य तरीके से लागू करता हूं: व्याकरण को शामिल करना अपघटन नियमों को लागू करने का केवल एक ही तरीका है।

महान विशेषता: +1:

इसे रिलीज होते देखने का इंतजार है।

:+1:

विस्मयकारी! :+1:

@dmajda मैं इस पार्टी में देर से आ रहा हूं, लेकिन मुझे आश्चर्य है कि हमें कितनी बार किसी अन्य पुस्तकालय से कई नियम आयात करने की आवश्यकता है। मैं अपने रचित व्याकरणों में Url और Email जैसी चीजों को आयात करने में सक्षम होना पसंद करूंगा लेकिन मुझे परवाह नहीं है कि Url HierarchicalPart जैसी चीजें भी हो सकती हैं। AsciiLetter । क्या आपको लगता है कि नेमस्पेसिंग के लाभों को ध्यान में रखते हुए, लेकिन सीधे नामित आयात की अनुमति देते हुए, नोड के नामित निर्यात जैसा कुछ आगे एक व्यवहार्य तरीका होगा?

import { SchemalessUrl, Url } from "./Urls.pegjs"

Token
  = PhoneNumber
  / Url
  / SchemalessUrl

नेमस्पेसिंग मेरे लिए एक मुद्दा रहा है क्योंकि मैं कोशिश करता हूं और अन्यथा-रचनात्मक व्याकरण लिखने का प्रयास करता हूं। मैं अभी फाइलों में फाइलों सहित फंस गया हूं और उचित नामस्थान पेश करने से पहले PHP कार्यों को नामित करने के तरीके का नामकरण कर रहा हूं: UrlIpHost , HtmlQuotedString , आदि…

@dmajda @futagoza

इस मुद्दे पर कोई प्रगति? या प्राथमिक चर्चा अभी #473 पर चल रही है ?
मेरी व्याकरण फ़ाइल बहुत तेजी से बढ़ रही है :(
इसे कई हिस्सों में बांटना अच्छा रहेगा

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

मैंने आधार के रूप में जिस JavaScript उदाहरण का उपयोग किया है वह 1,300 से अधिक पंक्तियों का है। यह जानने में थोड़ा समय लगा कि सब कुछ कहाँ है, और इधर-उधर कूदें और विभिन्न अनुभागों को संपादित करें।

@mikeaustin मैं इस सुविधा को किसी प्रकार के Node.JS required रूप में देखता हूं:

कैट बैश.pegjs
{
कॉन्स _ = आवश्यकता ("व्हाइटस्पेस");
कॉन्स्ट एलबी = आवश्यकता ("लाइन_ब्रेक");
कॉन्स्ट कोडब्लॉक = आवश्यकता ("कोड_ब्लॉक");
कॉन्स बूलएक्सप्र = आवश्यकता ("बूलियन_एक्सप्रेशन");
}
...
इफस्टेटमेंट = "अगर" _ "["बूलएक्सप्र"]" _ ";" _ "फिर" एलबी? कोडब्लॉक "फाई"

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

IMO, एक अस्थायी रूप से सुविधाजनक दृष्टिकोण PEG.js (PEG.js से स्वतंत्र) के लिए एक नया ऐडऑन बनाना होगा जो आयात करने के लिए एक कीवर्ड को परिभाषित करता है (उदाहरण के लिए @load(anotherGrammarFileLocation) ) कीवर्ड को javacsript/peg.js व्याकरण का हिस्सा नहीं होना चाहिए,
उस कीवर्ड का पता लगाने के लिए एक reg-exp या एक peg व्याकरण का निर्माण करें और इसे "anotherGrammarFile स्थान" सामग्री के साथ प्रतिस्थापित करें, और प्रतिस्थापित कोड को PEG.js पर भेजें

उदाहरण:

पूर्णांक.pegjs

integers=[0-9]* {return parseInt(text())}

main.pegjs

arrayOfInteger="["(integers ",")* integers"]"
@load("integers.pegjs")

इस पद्धति का उपयोग करते हुए नोट करें, यदि किसी ने प्रारंभ व्याकरण को परिभाषित नहीं किया है, और "arrayOfInteger" peg.js से पहले @load रखा है, तो पहले व्याकरण को प्रारंभ (पूर्णांक व्याकरण) के रूप में मान लिया जाएगा।

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

उपयोगकर्ता किसी भी दोहराव के लिए जिम्मेदार होना चाहिए।

मैं केवल इस बात पर प्रकाश डालना चाहता हूं कि यह मुद्दा मुख्य रूप से एक अनुकूलन अनुरोध है, क्योंकि कंपोजिबिलिटी/मॉड्यूलरिटी एक ऐसी चीज है जिसे आप अपने दम पर हासिल कर सकते हैं, खासकर जब आप व्याकरण के पूर्ण स्पेक्ट्रम को नियंत्रित करते हैं।

यदि आप 1k-लाइन लंबी व्याकरण के साथ सहज नहीं हैं, तो इसे विभाजित करें, और इसे pegjs में पंप करने से पहले जैसा आप फिट देखते हैं, इसे वापस जोड़ दें।