Pegjs: पुन: डिज़ाइन त्रुटि रिपोर्टिंग

मुझे PEG.js में वर्तमान त्रुटि रिपोर्टिंग सिस्टम के साथ तीन समस्याएं दिखाई देती हैं:

1. कार्रवाइयां null . लौटाकर त्रुटियों की रिपोर्ट करती हैं

Reporting using `null` is inflexible (it doesn't allow to carry any information about the kind of error) and makes it impossible to return `null` as a regular value from actions, which would be useful sometimes (for example [in a JSON parser](https://github.com/dmajda/pegjs/blob/791034fad92c9cd7a9d1c71187df03441bbfd521/examples/json.pegjs#L45)).

#17 भी देखें।

1. पूरी तरह से कस्टम संदेशों के साथ त्रुटियां उत्पन्न करने का कोई तरीका नहीं है

For example, imagine a HTTP 1.1 parser that wants to report an error about missing `Host` header in a HTTP request with a message like "A HTTP 1.1 request must contain a Host header". Currently the only way to do this is to throw an exception with desired message manually. This is cumbersome and it does not interact well with the backtracking behavior (throwing an exception halts the parsing completely, even when it is possible to backtrack and try another alternatives).

1. expected की SyntaxError की संपत्ति को यांत्रिक रूप से संसाधित करना कठिन है

The `expected` property of `SyntaxError` is either an array of expectations (each describing one alternative which the parser expected at the position of error) or `null` (meaning that the end of input was expected).

प्रत्येक अपेक्षा को एक स्ट्रिंग द्वारा दर्शाया जाता है। इस स्ट्रिंग का अर्थ एक अपेक्षित शाब्दिक (इसके PEG.js सिंटैक्स - एक उद्धृत स्ट्रिंग का उपयोग करके दर्शाया गया है), वर्ण वर्ग (इसके PEG.js सिंटैक्स का उपयोग करके दर्शाया गया है - [...] ), या कोई भी वर्ण (स्ट्रिंग "any" द्वारा दर्शाया गया है)

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

त्रुटि रिपोर्टिंग वर्तमान में कैसे काम करती है?

जब एक PEG.js पार्सर एक स्ट्रिंग अक्षर, वर्ण वर्ग, या . से मिलान करने का प्रयास करता है, और विफल रहता है, तो यह एक _match विफलता_ उत्पन्न करता है। इसमें एक _position_ और एक _expectation_ शामिल है (विवरण जो पार्सर ने मिलान करने का प्रयास किया)।

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

यदि नामित नियमों का उपयोग किया जाता है तो स्थिति थोड़ी अधिक जटिल होती है, लेकिन यह इस चर्चा के लिए अप्रासंगिक है।

प्रस्तावित परिवर्तन

मैं त्रुटि रिपोर्टिंग प्रणाली में निम्नलिखित परिवर्तनों के बारे में सोच रहा हूँ:

1. SyntaxError.expected में अपेक्षाओं को स्ट्रिंग्स द्वारा नहीं, बल्कि ऑब्जेक्ट्स द्वारा दर्शाया जाएगा। वस्तुओं में एक type संपत्ति होगी ( "literal" , "class" , "any" , "eof" जैसे मूल्यों के साथ) जो अपेक्षा के प्रकार को निर्धारित करेगी। कुछ उम्मीद प्रकारों के लिए, अन्य गुणों में विवरण शामिल होंगे (उदाहरण के लिए "literal" उम्मीद के लिए जहां value अपेक्षित स्ट्रिंग वाली संपत्ति होगी)। यह अपेक्षाओं के यांत्रिक प्रसंस्करण को सरल करेगा।

कक्षाओं का उपयोग करने के लिए type संपत्ति का एक विकल्प है। लेकिन मुझे लगता है कि उपयोगकर्ताओं के लिए type संपत्ति को संभालना आसान होगा।

1. कार्रवाइयों को null वापस करने की अनुमति दी जाएगी। यह एक नियमित मान होगा और यह किसी त्रुटि का संकेत नहीं देगा।
2. कार्रवाइयां एक नए error फ़ंक्शन का उपयोग करके मैच विफलता को ट्रिगर करने में सक्षम होंगी। यह एक त्रुटि संदेश को इसके पैरामीटर के रूप में लेगा। इस फ़ंक्शन द्वारा ट्रिगर की गई विफलताओं (जिसे _कस्टम मिलान विफलताएँ कहा जाता है) में एक _स्थिति_ और एक _त्रुटि संदेश_ शामिल होंगे। उनसे कोई अपेक्षा नहीं होगी।

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

कस्टम मिलान विफलताओं को नियमित मिलान विफलताओं की तरह नियंत्रित किया जाएगा, जिसका अर्थ है कि वे पूरी तरह से पार्सिंग को रोक नहीं पाएंगे और पार्सर को पीछे नहीं जाने देंगे और संभवतः अन्य विकल्पों को आजमा सकते हैं। हालांकि एक अंतर है - जब अंत में SyntaxError अपवाद फेंकते हैं, तो उम्मीद संयोजन नियम जो नियमित मिलान विफलताओं पर लागू होता है, कस्टम वाले पर लागू नहीं होगा। यदि सबसे दूर की स्थिति के साथ मैच विफलताओं के सेट में कम से कम एक कस्टम एक है, तो यह सामान्य लोगों को पूरी तरह से ओवरराइड कर देगा। यदि अधिक कस्टम विफलताएं हैं, तो जो पिछली बार उत्पादित किया गया था वह जीत जाएगा।

एक कस्टम मिलान विफलता के आधार पर एक SyntaxError अपवाद नियमित विफलता के आधार पर अपवादों से भिन्न होगा। यह message संपत्ति विफलता के त्रुटि संदेश के बराबर होगी और इसकी expected संपत्ति null होगी।

उदाहरण

```
प्रारंभ = संकेत: [+ -]? अंक:[0-9]+ {
वर परिणाम = parseInt ((चिह्न || "") + अंक। शामिल हों (""), 10);

 if (result % 2 == 0) {
   error("The number must be an odd integer.");
 }

 return result;

}
```

इनपुट पर 2 , उपरोक्त व्याकरण से उत्पन्न पार्सर SyntaxError के साथ message को "The number must be an odd integer." पर सेट करेगा और expected को null पर सेट करेगा।

1. कार्रवाइयां expected फ़ंक्शन का उपयोग करके नियमित मिलान विफलता को ट्रिगर करने में भी सक्षम होंगी। यह एक पैरामीटर के रूप में अपेक्षित मूल्य विवरण लेगा। यह फ़ंक्शन मुख्य रूप से उन स्थितियों के लिए एक सुविधा के रूप में प्रदान किया जाएगा जहां किसी को पूर्ण त्रुटि संदेश उत्पन्न करने की आवश्यकता नहीं होती है और स्वचालित रूप से "अपेक्षित _X_ लेकिन" 2 "पाया जाता है।" बहुत है।

expected फ़ंक्शन द्वारा उत्पन्न मिलान विफलता पर आधारित एक SyntaxError अपवाद नियमित विफलता पर आधारित अपवादों के समान होगा।

उदाहरण

```
प्रारंभ = संकेत: [+ -]? अंक:[0-9]+ {
वर परिणाम = parseInt ((चिह्न || "") + अंक। शामिल हों (""), 10);

 if (result % 2 == 0) {
   expected("odd integer");
 }

 return result;

}
```

इनपुट पर 2 , उपरोक्त व्याकरण से उत्पन्न पार्सर SyntaxError के साथ message को "Expected odd integer but "2" found." पर सेट करेगा और expected को [ { type: "user", description: "odd integer" } ] पर सेट करेगा।

अगले कदम

मैं प्रस्तावित परिवर्तनों के लिए किसी भी नोट का स्वागत करता हूं - कृपया उन्हें टिप्पणियों के रूप में जोड़ें। मैं जल्द ही प्रस्ताव (या फीडबैक के आधार पर कुछ संशोधित संस्करण) को लागू करना शुरू करने की योजना बना रहा हूं।