Pegjs: القدرة على تجاهل بعض المنتجات

متفق. هل هناك طريقة نظيفة للقيام بذلك في الوقت الحالي؟

benekastah : لا توجد طريقة نظيفة حتى الآن.

سيكون من الصعب القيام بذلك دون تغيير طريقة عمل PEG.js. تشمل الحلول الممكنة ما يلي:

1. السماح بربط lexer قبل المحلل اللغوي الذي تم إنشاؤه.
2. قم بتضمين معلومات حول القواعد المتأصلة في مكان ما في القواعد. قد يعني هذا أيضًا التمييز بين المستوى المعجمي والنحوي للقواعد - وهو أمر أود تجنبه.

لن أعمل على هذا الآن ولكن هذا شيء يجب التفكير فيه في الميزة.

سأحتاج هذه الميزة ل.

قد يكون يمكنك تقديم "تخطي" -Token. لذلك إذا أعادت القاعدة هذا الرمز المميز ، فسيتم تجاهله ولن تحصل على عقدة في AST (يُعرف أيضًا باسم الإدخال في المصفوفة).

أنا أبحث عن طريقة للقيام بذلك أيضًا.

لدي ملف قواعد نحوي كبير (يوزع تنسيق ASN.1 لملفات SNMP MIB). لم أكتبها ، لكنني قمت بتحويلها بشكل تافه من النموذج الأصلي لإنشاء محلل في PEG.js. (هذا جيد. في الواقع ، إنه أمر رائع للغاية أن يستغرق الأمر أقل من 15 دقيقة لتعديله حتى يقبله PEG.js.)

لسوء الحظ ، تمت كتابة القواعد مع القدرة ببساطة على تجاهل المسافات البيضاء والتعليقات عندما تصادفها. وبالتالي ، لا يمكن معالجة أي ملفات MIB حقيقية ، لأن المحلل اللغوي يتوقف عند التواجد الأول للمسافة البيضاء.

لست حريصًا على الاضطرار إلى معرفة القواعد النحوية حتى أتمكن من إدخال جميع المسافات البيضاء المناسبة في جميع القواعد (هناك حوالي 126 إنتاجًا ...) هل هناك طريقة أخرى للقيام بذلك؟

ملحوظة: في حال اضطررت إلى تعديل القواعد يدويًا ، طلبت المساعدة في بعض المهام في بطاقة في قائمة مجموعات Google. http://groups.google.com/group/pegjs/browse_thread/thread/568b629f093983b7

تشكرات!

شكرا للناس في مجموعات Google. أعتقد أنني حصلت على معلومات كافية للسماح لي بفعل ما أريد.

لكنني أتطلع حقًا إلى القدرة في PEG.js على تمييز المسافة البيضاء / التعليقات كشيء يجب تجاهله تمامًا حتى لا أضطر إلى قضاء بضع ساعات لتعديل قواعد نحوية نظيفة ... شكرًا!

ثري

أتفق مع التأكيد على أن pegjs تحتاج إلى القدرة على تخطي الرموز المميزة. قد أنظر في الأمر ، لأنه إذا كنت تريد كتابة قواعد نحوية جادة ، فسوف تصاب بالجنون عند وضع ws بين كل رمز.

نظرًا لأن المحلل اللغوي الذي تم إنشاؤه معياري. كحل بديل ، قم بإنشاء معجم مبسط واستخدم مخرجاته كمدخلات إلى المعجم الحقيقي ، على سبيل المثال:

elideWS.pegjs:

s = input: (whitespaceCharacter / textCharacter) *
{
نتيجة var = "" ؛

لـ (var i = 0 ؛ i <input.length ؛ i ++) نتيجة + = إدخال [i] ؛
نتيجة العودة
}

whitespaceCharacter = [nt] {return ""؛ }
textCharacter = c: [^ nt] {return c؛ }

ولكن هذا يسبب مشاكل عندما تكون المسافة البيضاء هي المحدد - مثل المعرفات

الاصطدام بهذه القضية في كثير من الأحيان.
لكن ليس من السهل كتابة معجم جيد (يمكن أن ينتهي بك الأمر إلى تكرار جزء جيد من القواعد الأولية للحصول على معجم متماسك).

ما كنت أفكر فيه هو أن أكون قادرًا على تحديد قواعد التخطي التي يمكن استخدامها كبدائل عندما لا يكون هناك تطابق. هذا يقدم الحاجة إلى فصل دراسي غير منكسر. مثال مع arithmetics.pegjs باستخدام Floats

  = 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]+

لا يزال يستوعب هذا. أي ردود فعل؟ قد تكون فكرة غبية جدا.

لذا فإن الاختلاف هو أنك تريد التمييز عندما يكون المحرك الكلي
تعمل في وضع lexer (المسافة البيضاء مهمة) وعندما لا تكون (المسافة البيضاء هي
تم تجاهله).

هل هناك حالة تريد فيها عدم تجاهل المسافات البيضاء عندما تكون في وضع lexer
كخيار؟ أو بالعكس ، عندما لا تكون داخل regex؟ أعتقد لا.

هل سيكون ما يلي معادلا؟

تطفو
"-؟ [0-9] + (". "[0-9] +)"

أو تمديد الربط لمعالجة regex النموذجية بشكل مباشر وخارجي
يتم تجاهل سلسلة مقتبسة (تتضمن regexes) مسافة بيضاء.

في 19 أبريل 2014 ، في الساعة 3:22 مساءً ، كتب Andrei Neculau [email protected] :

الاصطدام بهذه القضية في كثير من الأحيان.
لكن ليس من السهل كتابة معجم جيد (يمكن أن ينتهي بك الأمر إلى تكرار جزء جيد من القواعد الأولية للحصول على معجم متماسك).

ما كنت أفكر فيه هو أن أكون قادرًا على تحديد قواعد التخطي التي يمكن استخدامها كبدائل عندما لا يكون هناك تطابق. هذا يقدم الحاجة إلى فصل دراسي غير منكسر. مثال مع arithmetics.pegjs باستخدام Floats

تعبير
= المصطلح (("+" / "-") المصطلح) *

شرط
= عامل (("_" / "/") عامل) _

عامل
= "(" التعبير ")"
/ تطفو

تعويم "عائم"
= "-"؟ # [0-9] + # ("." # [0-9] +) // # يعني أن تخطي القواعد لا يمكن أن تتطابق

// تخطي القاعدة المميزة بعلامة "! ="
// لا يمكن لقواعد التخطي أن تتطابق مع السلسلة الفارغة
_ "مسافة بيضاء"
! = [tnr] +
لا يزال يستوعب هذا. أي ردود فعل؟ قد تكون فكرة غبية جدا.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

waTeim في الواقع لا.

تقليديا ، يتم تقسيم عملية الاعراب إلى تحليل lexing و تحليل. أثناء التوحيد ، يكون لكل حرف أهمية ، بما في ذلك المسافات البيضاء. ولكن يتم بعد ذلك تحويلها إلى رمز "تجاهل". المحلل اللغوي ، عند التقدم إلى الرمز المميز التالي ، سوف يتجاهل بعد ذلك أي رموز تم تجاهلها. الجزء المهم هو أنه يمكنك التخلص من أي شيء ، وليس فقط المسافات. هذا السلوك هو بالضبط ما يصفهandreineculau .

الفكرة الأساسية حول كيفية تنفيذ ذلك هي الحاجة إلى التحقق الإضافي من جميع قواعد الإهمال عند الانتقال من حالة إلى أخرى.

في 23 أبريل 2014 ، الساعة 2:54 مساءً ، كتب Sean Farrell [email protected] :

waTeim في الواقع لا.

لذلك نحن نتفق. النهج التقليدي كاف. ليست هناك حاجة لامتلاك
يتعرف الجزء المحلل بدقة على وجود الرموز المميزة المهملة وهناك
لا يوجد سبب لجعل جزء lexer يتصرف بشكل مشروط (بطريقة حساسة للسياق)
wrt التعرف على الرموز.

لذلك ليست هناك حاجة إلى وجود عناصر لصق (على سبيل المثال "#") في اللغة
لأنه يكفي ذلك

1) يمكن إنشاء الرموز المميزة فقط من regex وليست حساسة للسياق.
2) يمكن وضع علامة على الرموز المميزة ليتم تجاهلها دون استثناء.

تقليديا ، يتم تقسيم عملية الاعراب إلى تحليل lexing و تحليل. أثناء التوحيد ، يكون لكل حرف أهمية ، بما في ذلك المسافات البيضاء. ولكن يتم بعد ذلك تحويلها إلى رمز "تجاهل". المحلل اللغوي ، عند التقدم إلى الرمز المميز التالي ، سوف يتجاهل بعد ذلك أي رموز تم تجاهلها. الجزء المهم هو أنه يمكنك التخلص من أي شيء ، وليس فقط المسافات. هذا السلوك هو بالضبط ما يصفهandreineculau .

الفكرة الأساسية حول كيفية تنفيذ ذلك هي الحاجة إلى التحقق الإضافي من جميع قواعد الإهمال عند الانتقال من حالة إلى أخرى.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

حسنًا ، لقد أسأت فهمك. قد تكون هناك حالات لحالات lexer ، ولكن هذا مطلب مختلف تمامًا و IMHO خارج نطاق peg.js.

waTeimrioki ننسى قليلا عن اقتراحي.

تجريب ، خذ هذه القاعدة . إذا كنت ترغب في تبسيط القواعد النحوية للقاعدة عن طريق إزالة *WS ، فكيف يمكنك توجيه PEGjs لعدم السماح لـ *WS بين field_name و : ؟

andreineculau لأن القواعد النحوية حساسة expr = WS lit WS op WS expr WS ";" لكل قاعدة. فقط تخيل قواعد مثل تلك الخاصة بـ C مع التعامل مع المسافات البيضاء؟

أفهم أن إعادة صياغة قواعد الإهمال إلى pegjs ليس بالأمر السهل ، لكن هذا لا يعني أنه ليس هدفًا جديرًا بالثناء.

يا رجل ، قسم الرد المجاني! لدي الكثير لأقوله ، لذلك آسف للطول.

1) بالنسبة إلى TL ؛ DR ، إذا كان بإمكاني إضافة أي عناصر ربط ، أردت ، كنت سأكتبها على هذا النحو

header_field
= اسم الحقل ":" قيمة الحقل

مسافة بيضاء (تجاهل)
= [ر] +

الإضافة التي سأقوم بها هي قسم خيارات قد يتم تضمينه في أي إنتاج

لن يتم تقييد لغة http-bis بإعادة الكتابة هذه (انظر الملحق أ).

2) مشكلتي مع # المقترح

يبدو أنك تقوم بالتبادل وتطلب من المستخدم ملء تعريف المحلل اللغوي بمجموعة
تجاهل غير المحطات (عادة مسافة بيضاء / المحددات) مع مطالبة المستخدم بالملء
تعريف المحلل اللغوي مع مجموعة من الأحرف الوصفية "هنا لا يتم تجاهل الأحرف"
بلا داعى. من المسلم به أنه سيكون هناك عدد أقل من حدوث ذلك. إنها حالة نادرة عندما
يستهلك الأشخاص بالفعل المحددات ويفعلون شيئًا ما معهم ، وكما أعلق في

الملحق أ ، ليس HTTP-bis أحد تلك الأحداث ، ولكنه موثق بشكل سيئ.

3) حالات المحلل اللغوي المعرفة من قبل المستخدم

لكن يمكنني أن أرى كيف سيكون من الأسهل على المحلل اللغوي قص ولصق ملف
اللغة من التعريف ، لذلك إذا كان يجب أن يكون لديك شيء مثل هذا ، إذن
يمكن أن يتم ذلك باستخدام الحالات المعجمية كما أشار إليها شون سابقًا. أعتقد أنني سأفعل ذلك
بالطريقة الآتية.

إنتاج 1 (حالة == 1)
= الاشياء

الإنتاج 2 (الحالة == 2)
= الاشياء

إنتاج 3
= أشياء {حالة = 1}

الإنتاج 4
= أشياء {حالة = 2}

بمعنى آخر ، تمامًا مثل lex / yacc يجعل من الممكن أن تكون المنتجات متاحة فقط

إذا كان النظام في حالة معينة ، والسماح للمستخدم بتعيين قيمة هذه الحالة.

4) المزيد من الخيارات

أو يمكنك تسهيل الأمر على المستخدم وجعله أكثر وضوحًا للقارئ مع الآخر
اختيار

إنتاج (DONTIGNORE)
= الاشياء

مما سيسمح للمحلل اللغوي بتجاوز الإجراء الافتراضي المتمثل في تجاهل الرموز المميزة المميزة
كمنبوذ ولكن فقط لهذا الإنتاج الواحد. هذا هو في الحقيقة نفس الرقم 3 ، فقط أسهل
اقرأ. هذا أقل مرونة من الاقتراح # لأنه يتم تجاهل كل الإنتاج

أو عدم التجاهل ، لكنني لا أعتقد أن هناك حاجة إلى مزيد من المرونة.

5) تسمح إضافة معامل إلى getNextToken () بحساسية السياق

أعتقد أن كل هذا يعود إلى (أقوم ببعض الافتراضات هنا) حاليًا ، و
يستدعي جزء المحلل getNextToken (إدخال) ، وما يجب أن يحدث بدلاً من ذلك هو إضافة

المعلمة لها getNextToken (الإدخال ، الخيارات).

الملحق أ) مواصفات HTTP-bis

حسنًا ، لقد قرأت بعضًا ولكن لم أقرأ كل هذا

بروتوكول نقل النص التشعبي (HTTP / 1.1): بناء جملة الرسائل وتوجيهها
مشروع ietf-httpbis-p1-messaging-26

لا أحب الطريقة التي حددوا بها قواعدهم النحوية. لا أقترح تغيير الإدخال
يقبل ، لكنني لم أكن لأعرفه كما فعلوا. على وجه الخصوص ، أنا لا أحب لماذا لديهم
حددت OWS و RWS و BWS والتي تساوي جميعها نفس سلسلة الأحرف بالضبط
ولكن في سياقات مختلفة. لقد حددوا

OWS :: == (SP | HTAB) *
RWS :: == (SP | HTAB) +
BWS :: == OWS

وهو مجرد تكرار لعلامات التبويب والمسافات

لا لسبب وجيه. لقد جعلوا اللغة أكثر صعوبة في التحليل - تتطلب محللًا معجميًا
لتتبع سياقها - ولم يكونوا بحاجة إلى فعل ذلك.

لقد قاموا بتعريف OWS على أنها "مساحة بيضاء اختيارية" BWS على أنها "مسافة بيضاء سيئة" أو اختيارية بخلاف ذلك
مسافة بيضاء ولكن في السياق "السيئ" - حيث لا يكون ذلك ضروريًا - وكانت RWS تتطلب مسافة بيضاء حيث تكون
ضروري لتحديد الرموز. لا يتم استخدام هذه المسافة البيضاء في أي مكان باستثناء ربما يكون هناك محلل
تحذير إذا كان يطابق BWS ("تم اكتشاف مسافة بيضاء لاحقة غير ضرورية" أو بعض هذه المسافة) وهو كل
المحددات تفعل على أي حال.

في المواصفات الخاصة بهم ، المكان الوحيد الذي يتم فيه استخدام RWS هنا

عبر = 1 # (تم استلام بروتوكول RWS بواسطة [تعليق RWS])

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

لكن "إصدار البروتوكول" عبارة عن أرقام وربما أحرف ، بينما "تم الاستلام بواسطة" عبارة عن أرقام وحروف. بعبارة أخرى،
لن يتعرف المحلل المعجمي على هذين الجزأين بشكل صحيح ما لم يتم فصلهما بمسافة بيضاء
وسيكون خطأ في بناء الجملة مع أو بدون تحديد RWS صراحة إذا لم يكن هناك 1 على الأقل
حرف المسافة البيضاء. لذلك فقط قم بإزالة RWS من المنتجات تمامًا وتعامل مع المسافات البيضاء
في كل مكان كمحدد ولا يغير اللغة ، فقط طريقة توثيقه.

في 24 أبريل 2014 ، الساعة 1:23 مساءً ، كتب Andrei Neculau [email protected] :

waTeimrioki ننسى قليلا عن اقتراحي.

تجريب ، خذ هذه القاعدة. إذا كنت ترغب في تبسيط القواعد النحوية للقاعدة عن طريق إزالة OWS ، فكيف يمكنك توجيه PEGjs لعدم السماح لـ OWS بين field_name و:؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

waTeim أعتقد أنك تسرف في هذا الأمر. لقد كتبت عددًا قليلاً جدًا من المحللين اللغويين وأعتقد أن المعجم ينص على أنه لم يكن مفيدًا حقًا على هذا النحو. في معظم الحالات ، رأيتهم في المكان الذي استهلك فيه lexer تعليقات الكتلة وكان "أبسط" وضع lexer في "وضع تعليق الحظر" وكتابة أنماط أبسط من نمط über لاستهلاك التعليق (وعدد الأسطر).

لم أر أبدًا أي استخدام مناسب لحالات lexer الناشئة عن المحلل اللغوي. تكمن المشكلة الأساسية هنا في أنه بنظرة واحدة إلى الأمام ، عندما يرى المحلل الرمز المميز لتبديل الحالات ، يكون lexer قد أخطأ بالفعل في الرمز المميز التالي. ما تقترحه يكاد يكون من المستحيل تنفيذه بدون التتبع الخلفي وهذه ليست ميزة جيدة في المحلل اللغوي.

عند كتابة قواعد ما ، فأنت تحدد بشكل أساسي المنتجات التي يتم اعتبارها محللة وما يمكن رشه. في مثالandreineculau ، يوجد خياران ، إما أن تتعامل مع المسافات البيضاء في المحلل اللغوي أو تحدد الجزء اللاحق ":" من الرمز المميز. ( [a-zA-Z0-9!#$%&'+-.^_|~]+ ":" ).

قد أقترح تحويل المشكلة إلى تحديد قائمة بيضاء - ما الأجزاء التي أريد التقاطها وتحويلها - بدلاً من القائمة السوداء. على الرغم من أن المسافة البيضاء هي إحدى مشكلات نظام الالتقاط الحالي ، إلا أن تداخل القواعد يمثل مشكلة أخرى. كما كتبت في العدد رقم 66 ، فإن نظام LPeg لتحديد ما تريد التقاطه مباشرة ، عبر التحويلات أو التقاط السلسلة ، يبدو أكثر فائدة بالنسبة لي من تحديد عدد قليل من المنتجات لتخطيها وما زلت تتعامل مع تداخل كل إنتاج آخر.

راجع تعليقي في الإصدار رقم 66 للحصول على مثال بسيط عن LPeg مقابل PEG.js فيما يتعلق بالتقاط الصور. على الرغم من أن أسماء هي خفي قليلا، راجع يلتقط قسم وثائق LPeg لمختلف الطرق التي يمكنك التقاط أو تحويل إنتاج معين (أو جزء منه).

مرحبًا ، لقد أنشأت مقتطفًا لتجاهل بعض الحالات العامة: null ، undefined وسلاسل تحتوي على رموز مسافات فقط.
يمكن أن تكون مطلوبة في رأس الملف النحوي مثل:

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

طريقتان لتحسينه:

• عامل تصفية قابل للتخصيص للمصطلحات - لتجاهل المصطلحات المحددة التي تتطلب قواعد معينة.
• تخطي المصفوفات الفارغة المتداخلة - يمكن القيام بذلك في المرحلة الثانية بعد strip ، سيؤدي ذلك إلى إزالة "الأهرامات" من المصفوفات الفارغة المتداخلة.
  إذا كان أي شخص مهتم ، فيمكننا ترقيته إلى حزمة.

@ richb-hanover أين وصلت جهود محلل تعريف ASN.1؟

atesgoral - أنا

لذلك فعلت ما سيفعله أي شخص ضعيف - استخدم التعابير النمطية. (ثم ​​واجهت مشكلتين :-)

لكنها فعلت الحيلة ، لذلك تمكنت من الانتقال إلى التحدي التالي. حظا سعيدا في مشروعك!

بعد إلقاء نظرة على chevrotain وخيار التخطي الخاص به ، فإن شيئًا كهذا مرغوب فيه للغاية.

كثيرًا ما نجد أنفسنا نكتب شيئًا كهذا:

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)
  };
}

@ richb-hanover ، وأي شخص آخر جاء هنا بحثًا عن حاجة مماثلة ، انتهى بي الأمر بكتابة موزعي خاص بي أيضًا: https://www.npmjs.com/package/asn1exp و https: //www.npmjs. كوم / حزمة / asn1- شجرة

سيكون من السهل نسبيًا تنفيذ التخطي باستخدام es6 symbol ، أو ربما بشكل أكثر استدامة عن طريق تمرير المحلل اللغوي في وقت التحليل (أفضل الخيار الأخير)

فقط عثرت على هذا أيضا.
لا أعرف أي شيء عن الأجزاء الداخلية لـ PEG.js ، lemme يرمي عظمة هناك ...

عندما نكتب قاعدة ، في نهايتها يمكننا إضافة كتلة عودة.
في هذا الجزء ، يمكننا استدعاء أشياء مثل text() و location() . هذه وظائف داخلية.

في مكان ما في الكود ، تذهب القيمة التي تم إرجاعها لتلك الكتلة إلى تدفق الإخراج.

إذن ما الذي يجب تغييره في PEG.js إذا كنت أرغب في تخطي قيمة تُرجع بواسطة قاعدة إذا كانت هذه القيمة هي إرجاع استدعاء دالة محلية skip ؟

على سبيل المثال ، comment = "//" space ([^\n])* newline { return skip() }

كما ذكرنا سابقًا ، يمكن لـ skip () إرجاع رمز ، يتم التحقق منه بعد ذلك بواسطة الرمز في مكان ما وإزالته.
شيء من هذا القبيل ما قاله lzhaki ، ولكن داخلي للمكتبة

أنا لا أفهم سؤالك. هل تبحث عن طريقة لفشل قاعدة في ظل بعض الظروف؟ استخدم &{...} أو !{...} . وإلا فلا تستخدم القيمة المُعادة لقاعدة 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 True ، إنها تتطلب بعض الأعمال عالية المستوى ، لكنها تعمل بالنسبة لي ، وأعتقد أنه طالما أن gammar ليس معقدًا للغاية ، يجب أن يكون المرء قادرًا على التخلص من وجود مرشح عالي المستوى.

بخلاف ذلك ، كل ما يمكنني التفكير فيه هو وجود وظيفة ذات مستوى أعلى تقوم بتصفية المسافات البيضاء من الإدخال وتمرير كل مطابقة من خلالها. أبطأ بالتأكيد ، ويتطلب الكثير من المكالمات ، ولكن من السهل إذا قمت (مثلي) بتمرير كل شيء إلى منشئ الرموز. يمكنك استدعاء وظيفة التصفية من حيث تقوم بإنشاء الرموز ، وما عليك سوى القلق بشأن إنشاء الرموز الخاصة بك ويتم تصفية المسافة البيضاء بشكل أو بآخر تلقائيًا

أحد الأشياء التي أحببتها في HEAD الحالي لـ pegjs هو دعمها (غير الموثق) لاختيار الحقول دون الحاجة إلى إنشاء تسميات وإجراء بيانات الإرجاع. تبدو هكذا:

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

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

أشعر أن هذا يعطي بناء جملة لطيفًا ونظيفًا وصريحًا لحالة الاستخدام هذه بالإضافة إلى مجموعة من الآخرين.