अस्पष्ट व्याकरण क्यों बुरे हैं?


30

मैं समझता हूं कि यदि 2 या अधिक बाएं या दाएं व्युत्पन्न पेड़ मौजूद हैं, तो व्याकरण अस्पष्ट है, लेकिन मैं यह समझने में असमर्थ हूं कि यह इतना बुरा क्यों है कि हर कोई इससे छुटकारा पाना चाहता है।


1
संबंधित लेकिन समान नहीं: softwareengineering.stackexchange.com/q/343872/206652 (अस्वीकरण: मैंने स्वीकृत उत्तर लिखा है)
marstato


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

3
"हर कोई इससे छुटकारा पाना चाहता है"। खैर, यह सच नहीं है। व्यावसायिक रूप से प्रासंगिक भाषाओं में, भाषाएं विकसित होते ही अस्पष्टता को देखना आम बात है। ईजी सी ++ ने std::vector<std::vector<int>>2011 में जानबूझकर अस्पष्टता को जोड़ा , जिसमें >>पहले के बीच एक स्थान की आवश्यकता होती थी। प्रमुख अंतर्दृष्टि यह है कि इन भाषाओं में विक्रेताओं की तुलना में कई अधिक उपयोगकर्ता हैं, इसलिए उपयोगकर्ताओं के लिए मामूली झुंझलाहट को ठीक करना कार्यान्वयनकर्ताओं द्वारा बहुत सारे काम को सही ठहराता है।
एमएसलटर्स

जवाबों:


52

गणित भाव के लिए निम्नलिखित व्याकरण पर विचार करें:

XX+XXXXXX/Xvarconst
निम्नलिखित अभिव्यक्ति पर विचार करें:
abc
अपने मूल्य क्या है? यहाँ दो संभावित पार्स पेड़ हैं:

(एक्स - एक्स) - एक्स यहां छवि विवरण दर्ज करें

बाईं ओर एक के अनुसार, हमें abc रूप में (ab)c व्याख्या करनी चाहिए , जो कि सामान्य व्याख्या है। सही पर एक के अनुसार, हमें इसकी व्याख्या a(bc)=ab+c रूप में करनी चाहिए , जो कि ऐसा नहीं था।

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


सिंटेक्स ट्री जनरेटर का उपयोग करके उत्पन्न पेड़


12
@HHIKMONDAL यह तथ्य कि वाक्यविन्यास अस्पष्ट है वास्तविक मुद्दा नहीं है। समस्या यह है कि दो अलग-अलग पार्स पेड़ों का व्यवहार अलग-अलग है। यदि आपकी भाषा में अस्पष्ट व्याकरण है, लेकिन अभिव्यक्ति के लिए सभी पार्स पेड़ शब्दार्थ के बराबर हैं, तो यह कोई समस्या नहीं होगी (जैसे कि युवल उदाहरण लें और उस मामले पर विचार करें जहां आपका एकमात्र ऑपरेटर है +)।
21:39 पर बकुरी जू

14
@ बकुरीउ आपने जो कहा वह सच है, लेकिन "शब्दार्थ समतुल्य" एक लंबा क्रम है। उदाहरण के लिए, फ्लोटिंग पॉइंट अंकगणित वास्तव में साहचर्य नहीं है (इसलिए दो "+" पेड़ समतुल्य नहीं होंगे)। इसके अलावा, भले ही जवाब उसी तरह से आया हो, अपरिभाषित मूल्यांकन आदेश उन भाषाओं में बहुत मायने रखता है जहां अभिव्यक्ति के दुष्प्रभाव हो सकते हैं। तो आपने जो कहा वह तकनीकी रूप से सही है, लेकिन व्यवहार में एक व्याकरण की अस्पष्टता के लिए यह बहुत ही असामान्य होगा कि उस व्याकरण के उपयोग के लिए कोई नतीजा न हो।
रिचर्ड रास्ट

आजकल कुछ भाषाएं पूर्णांक में पूर्णांक ओवरफ़्लो की जांच करती हैं, इसलिए पूर्णांक के लिए भी + b + c मूल्यांकन के क्रम पर निर्भर करता है।
gnasher729

3
इससे भी बदतर, कुछ मामलों में व्याकरण वैकल्पिक अर्थ को प्राप्त करने का कोई तरीका प्रदान नहीं करता है। मैंने इसे क्वेरी भाषाओं में देखा है, जहां भागने के व्याकरण (जैसे कि इसे बचने के लिए विशेष चरित्र को दोगुना करना) का विकल्प कुछ प्रश्नों को व्यक्त करना असंभव बनाता है।
मोनिका

12

अन्य मौजूदा उत्तरों [ 1 , 2 ] के विपरीत , वास्तव में आवेदन का एक क्षेत्र है, जहां अस्पष्ट व्याकरण उपयोगी होते हैं । प्राकृतिक भाषा प्रसंस्करण (एनएलपी) के क्षेत्र में, जब आप औपचारिक व्याकरण के साथ प्राकृतिक भाषा (एनएल) को पार्स करना चाहते हैं, तो आपको यह समस्या है कि एनएल विभिन्न स्तरों पर स्वाभाविक रूप से अस्पष्ट है [कोह 18 से अनुकूलित, ch। 6.4]:

  • सिंथेटिक अम्बिगिटी:

    पीटर ने लाल स्पोर्ट्स कार में आदमी का पीछा किया

    पीटर या लाल स्पोर्ट्स कार में आदमी था?

  • शब्दार्थ:

    पीटर बैंक गए

    एक बैंक पर बैठने के लिए या एक बैंक से पैसे निकालने के लिए?

  • व्यावहारिक महत्व:

    दो आदमी दो बैग ले गए

    क्या वे एक साथ बैग ले गए थे या प्रत्येक आदमी ने दो बैग उठाए थे?

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

  1. पार्सल एनएल को अस्पष्ट व्याकरण के साथ
  2. प्रत्येक परिणामी एएसटी के लिए: अस्पष्ट अर्थ अर्थ उत्पन्न करने के लिए और कदम से असंभव वाक्यविन्यास अस्पष्टताओं को बाहर करने के लिए मॉडल पीढ़ी चलाएं 1
  3. प्रत्येक परिणामी मॉडल के लिए: इसे अपने कैश में सहेजें।

आप हर वाक्य के लिए यह पाइपलाइन करें। अधिक पाठ, कहते हैं, एक ही किताब से आप प्रक्रिया करते हैं, जितना अधिक आप असंभव सतही मॉडल को नियंत्रित कर सकते हैं, जो पिछले वाक्यों से चरण 3 तक बच गया है।

प्रोग्रामिंग भाषा के विपरीत, हम इस आवश्यकता को जाने दे सकते हैं कि प्रत्येक NL वाक्य में सटीक शब्दार्थ है। इसके बजाय, हम बड़े ग्रंथों के पार्सिंग के दौरान सिर्फ कई संभावित शब्दार्थ मॉडल बुक कर सकते हैं। बाद के समय से, बाद में अंतर्दृष्टि हमें पिछली अस्पष्टताओं को बाहर निकालने में मदद करती है।

यदि आप अपने हाथों को पार्सर्स के साथ गंदा करना चाहते हैं, तो अस्पष्ट व्याकरण के लिए कई व्युत्पत्तियों का उत्पादन करने में सक्षम होने पर, व्याकरणिक ढांचे पर एक नज़र डालें । इसके अलावा, [कोह 18, ch 5] इसका एक परिचय है जो ऊपर मेरी पाइपलाइन के समान है। ध्यान दें कि चूंकि [कोह 18] व्याख्यान नोट्स हैं, इसलिए हो सकता है कि व्याख्यान के बिना नोट्स अपने आप ही समझना आसान न हों।


संदर्भ

[कोह १ Michael]: माइकल कोहलेश। "तर्क-आधारित प्राकृतिक भाषा प्रसंस्करण। शीतकालीन सत्र 2018/19। व्याख्यान नोट्स।" यूआरएल: https://kwarc.info/teaching/LBS/notes.pdf । पाठ्यक्रम विवरण का URL: https://kwarc.info/courses/lbs/ (जर्मन में)

[कोह १ ch, चौ। 5]: अध्याय 5 देखें, "कार्यान्वयन: व्याकरणिक और तार्किक रूपरेखा", [कोहिन 18] में

[कोह १ ch, चौ। 6.4] अध्याय 6.4 देखें, "[कोहिन 18 में" अंबुजियों की कम्प्यूटेशनल भूमिका "


एक टन धन्यवाद .. मुझे वही संदेह था और यू ने इसे मंजूरी दे दी .. :)
HIRAK MONDAL

1
भैंस भैंस के साथ समस्याओं का उल्लेख नहीं करने के लिए भैंस भैंस भैंस ... भैंस की एक उपयुक्त संख्या के लिए
Hagen Von Eitzen

आप लिखते हैं, "इसके विपरीत", लेकिन मैं इसे सिक्के के दूसरे पक्ष से कहता हूं जो मैंने उत्तर दिया था। अपने अस्पष्ट व्याकरण के साथ प्राकृतिक भाषाओं को पार्स करना इतना कठिन है कि पारंपरिक पार्सर ऐसा नहीं कर सकते हैं!
डेविस्लर

1
@ कॉम मुझे यहां अधिक सटीक होना चाहिए। GF का संक्षिप्त रूप (लिंक के लिए धन्यवाद!) से पता चलता है कि यह तीन एक्सटेंशन (जैसे रिडुप्लीकेशन की अनुमति देता है) के साथ संदर्भ-मुक्त व्याकरण पढ़ता है और सभी संभावित व्युत्पत्तियों की सूची देता है। ऐसा करने के लिए एल्गोरिदम '50 के दशक के बाद से आसपास रहा है। हालांकि, पूरी तरह से सामान्य सीएफजी को संभालने में सक्षम होने का मतलब है कि आपका सबसे खराब मामला रनटाइम चल रहा है, और व्यवहार में, यहां तक ​​कि जीएलएल जैसे सामान्य पार्सर का उपयोग करते समय, सॉफ्टवेयर इंजीनियर सीएफजी के सबसेट का उपयोग करने की कोशिश करते हैं, जैसे एलएल ग्रेंजर, जो कर सकते हैं। अधिक कुशलता से पार्स किया जाए।
डेविस्लोर

1
@ComFreek इसलिए ऐसा नहीं है कि कंप्यूटर CFG को संभाल नहीं सकते हैं (हालांकि प्राकृतिक भाषा वास्तव में संदर्भ-मुक्त नहीं है और वास्तव में उपयोगी मशीन अनुवाद पूरी तरह से अलग तकनीकों का उपयोग करता है)। यह है कि, यदि आपको अस्पष्टता को संभालने के लिए अपने पार्सर की आवश्यकता होती है, तो यह कुछ शॉर्टकट्स को नियंत्रित करता है जो इसे और अधिक कुशल बनाता है।
डेविस्लर

10

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

कुछ प्रतिबंधित डोमेन में, आप यह साबित करने में सक्षम हो सकते हैं कि अभिव्यक्ति को पार्स करने के सभी संभावित तरीके समकक्ष हैं (उदाहरण के लिए, क्योंकि वे एक सहयोगी ऑपरेशन का प्रतिनिधित्व करते हैं)। (a + b) + c = a + (b + c)।


9

का IF a THEN IF b THEN x ELSE yमतलब है

IF a THEN
    IF b THEN
        x
    ELSE
        y

या

IF a THEN
    IF b THEN x
ELSE
    y

? AKA झूलने की समस्या


1
यह एक अच्छा उदाहरण है कि एक गैर-अस्पष्ट व्याकरण (जैसा कि जावा, सी, सी ++, ...) में दिखाया गया है, मानवीय दृष्टिकोण से अस्पष्टता (!) है। भले ही हम औपचारिक रूप से और कम्प्यूटेशनल रूप से ठीक हैं, लेकिन अब हमें एक UX / बग-मुक्त विकास समस्या मिल गई है।
कॉमफ्रीक

5

उदाहरण के लिए C ++ में सबसे अधिक आकर्षक पार्स लें:

bar foo(foobar());

क्या यह फ़ंक्शन fooप्रकार की घोषणा है bar(foobar())(पैरामीटर एक फ़ंक्शन पॉइंटर लौटा रहा है foobar), या fooप्रकार की एक चर घोषणा intऔर एक डिफ़ॉल्ट आरंभीकृत के साथ प्रारंभ foobar?

जब तक पैरामीटर सूची के अंदर की अभिव्यक्ति को एक प्रकार के रूप में व्याख्या नहीं किया जा सकता है, तब तक इसे पहले मानकर संकलक में विभेदित किया जाता है।

जब आपको ऐसी अस्पष्ट अभिव्यक्ति मिलती है तो कंपाइलर के पास 2 विकल्प होते हैं

  1. मान लें कि अभिव्यक्ति एक विशेष व्युत्पत्ति है और व्याकरण में कुछ विघटनकर्ता को जोड़ने के लिए अन्य व्युत्पत्ति को व्यक्त करने की अनुमति दें।

  2. त्रुटि बाहर और दोनों तरह से छूट की आवश्यकता है

पहला स्वाभाविक रूप से बाहर गिर सकता है, दूसरे के लिए आवश्यक है कि कंपाइलर प्रोग्रामर को अस्पष्टता के बारे में पता हो।

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


5

मुझे लगता है कि प्रश्न में एक धारणा है कि केवल सीमा रेखा ही सही है।

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

उदाहरण के लिए, यदि आप याक के साथ संकलित व्याकरणों (या इसी तरह, जैसे बाइसन या बायकाक) को देखते हैं, तो आप पाएंगे कि जब आप उन्हें संकलित करते हैं तो "एन शिफ्ट / रिडक्ट टकराव" के बारे में काफी कुछ चेतावनी देते हैं। जब याक एक बदलाव / संघर्ष को कम करता है, तो यह व्याकरण में एक अस्पष्टता का संकेत देता है।

एक बदलाव / संघर्ष को कम करना, हालांकि, आमतौर पर एक काफी छोटी समस्या है। पार्सर जनरेटर कम करने के बजाय "शिफ्ट" के पक्ष में संघर्ष को हल करेगा। यदि आप चाहते हैं कि व्याकरण पूरी तरह से ठीक है (और यह अभ्यास में पूरी तरह से अच्छी तरह से काम करने लगता है)।

इस सामान्य आदेश पर एक मामले में एक बदलाव / कम संघर्ष उत्पन्न होता है (गैर-टर्मिनलों के लिए कैप का उपयोग करना और टर्मिनलों के लिए कम-मामला):

A -> B | c
B -> a | c

जब हम एक मुठभेड़ करते हैं c, तो एक अस्पष्टता है: क्या हमें cसीधे Aए के रूप में पार्स करना चाहिए, या क्या हमें इसे ए के रूप में पार्स करना चाहिए B, जो बदले में ए है A? इस तरह के एक मामले में, याक और इस तरह के सरल / छोटे मार्ग का चयन किया जाएगा, और -> -> मार्ग जाने के बजाय cसीधे ए के रूप में पार्स करें । यह गलत हो सकता है, लेकिन यदि ऐसा है, तो इसका मतलब है कि शायद आपके व्याकरण में वास्तव में सरल त्रुटि है, और आपको विकल्प की अनुमति बिल्कुल भी नहीं देनी चाहिए ।AcBAcA

अब, इसके विपरीत, हम इस तरह से कुछ और कर सकते हैं:

A -> B | C
B -> a | c
C -> b | c

अब जब हम मुठभेड़ एक cहम के इलाज के लिए है कि क्या के बीच संघर्ष है cएक के रूप में Bया एक C। इस बात की बहुत कम संभावना है कि एक स्वचालित संघर्ष समाधान रणनीति वह चुनने जा रही है जो हम वास्तव में चाहते हैं। इनमें से कोई भी "शिफ्ट" नहीं है - दोनों "रिडक्शन" हैं, इसलिए यह एक "कम / कम करने वाला संघर्ष" है (जो कि याक के आदी थे और ऐसे आम तौर पर शिफ्ट / संघर्ष को कम करने की तुलना में बहुत बड़ी समस्या के रूप में पहचाने जाते हैं)।

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


यार, काश, मैं 5 महीने पहले शिफ्ट-कम संघर्ष का यह उत्कृष्ट विवरण होता! ^^; +1
HotelCalifornia
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.