Чому неоднозначні граматики погані?

Я розумію, що якщо існує 2 і більше лівих або правих дериваційних дерев, то граматика неоднозначна, але я не в змозі зрозуміти, чому це так погано, що всі хочуть його позбутися.

Розглянемо наступну граматику для арифметичних виразів:

Згідно з ліворуч, ми повинні тлумачити $a-b-c$ як $(a-b)-c$ , що є звичайним тлумаченням. Відповідно до одного праворуч, ми повинні інтерпретувати його як $a-(b-c) = a-b+c$ , що, ймовірно , не те , що було задумано.

Складаючи програму, ми хочемо, щоб інтерпретація синтаксису була однозначною. Найпростіший спосіб забезпечити це - використання однозначної граматики. Якщо граматика неоднозначна, ми можемо надати правила розриву зв’язків, як пріоритет оператора та асоціативність. Ці правила можна рівномірно виразити, зробивши граматику однозначною особливим чином.

Розбір дерев, створених за допомогою генератора синтаксичного дерева .

На відміну від інших існуючих відповідей [ 1 , 2 ], справді існує поле застосування, де корисні неоднозначні граматики . У галузі обробки природних мов (NLP), коли ви хочете розібрати природну мову (NL) з формальними граматиками, у вас з’явилася проблема, що NL по своїй суті неоднозначно на різних рівнях [адаптовано від Koh18, гол. 6.4]:

• Синтаксична амбігія:

  Петро переслідував чоловіка в червоній спортивній машині

  Пітер чи чоловік у червоній спортивній машині?

• Семантична амбіція:

  Пітер пішов до банку

  Банк, на якому слід сидіти, або банк для зняття грошей?

• Прагматична амбіція:

  Двоє чоловіків несли дві сумки

  Вони носили сумки разом чи кожен чоловік носив по дві сумки?

Різні підходи до НЛП по-різному стосуються обробки в цілому та зокрема цих амбіцій. Наприклад, ваш трубопровід може виглядати наступним чином:

1. Розбирайте NL з неоднозначною граматикою
2. Для кожного результату AST: запустити генерацію моделі, щоб генерувати неоднозначні смислові значення та виключати неможливі синтаксичні неоднозначності з кроку 1
3. Для кожної отриманої моделі: збережіть її у своєму кеші.

Ви робите цей конвеєр для кожного речення. Чим більше тексту, скажімо, з тієї ж книги, яку ви обробляєте, тим більше ви можете виключити неможливі зайві моделі, що збереглися до кроку 3, з попередніх речень.

На відміну від мови програмування, ми можемо відмовитись від вимоги, що кожне речення NL має точну семантику. Натомість ми можемо просто зарезервувати кілька можливих смислових моделей під час розбору великих текстів. Час від часу пізніші розуміння допомагають нам виключати попередні неясності.

Якщо ви хочете забруднити руки, коли парсери зможуть виводити декілька виводів для неоднозначної граматики, погляньте на Граматичну рамку . Також [Koh18, гол. 5] містить вступ до нього, де відображається щось подібне до мого конвеєра вище. Зауважте, що оскільки [Koh18] є конспектами лекцій, замітки можуть бути не такими легко зрозуміти самостійно без лекцій.

Список літератури

[Koh18]: Майкл Кольхазе. "Логічна обробка природних мов. Зимовий семестр 2018/19. Конспекти лекцій." URL: https://kwarc.info/teaching/LBS/notes.pdf . URL-адреса опису курсу: https://kwarc.info/courses/lbs/ (німецькою мовою)

[Кох18, гол. 5]: Див. Розділ 5, "Реалізація фрагментів: граматичні та логічні рамки", в [Koh18]

[Кох18, гол. 6.4] Див. Главу 6.4, "Обчислювальна роль неоднозначностей", в [Koh18]

Навіть якщо є чітко визначений спосіб поводження з неоднозначністю (неоднозначні вирази, наприклад, синтаксичні помилки), ці граматики все ще створюють проблеми. Щойно ви вводите неоднозначність у граматику, аналізатор вже не може бути впевнений, що перша відповідність, яку він отримує, є остаточною. Необхідно продовжувати намагатися всі інші способи розбору твердження, щоб виключити неоднозначність. Ви також не маєте справу з чимось простим, як, наприклад, LL (1) мова, тому не можете використовувати простий, маленький, швидкий парсер. У вашій граматиці є символи, які можна прочитати різними способами, тому вам потрібно бути готовим до того, щоб багато чого відхилити.

У деяких обмежених областях ви можете уникнути, довівши, що всі можливі способи розбору виразу еквівалентні (наприклад, тому що вони представляють асоціативну операцію). (a + b) + c = a + (b + c).

Це 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 висить ще проблема .

Візьмемо, наприклад, найбільш роздратований аналіз на C ++:

bar foo(foobar());

Це функція декларації fooтипу bar(foobar())(параметр - це покажчик функції, що повертається a foobar), або декларація змінної fooтипу intта ініціалізована ініціалізацією за замовчуванням foobar?

Це диференціюється у компіляторах, припускаючи перше, якщо вираз у списку параметрів не може бути інтерпретований як тип.

коли ви отримуєте такий неоднозначний вираз, у компілятора є 2 варіанти

1. припустимо, що вираз є певним виведенням, і додайте граматиці деякий розбірник, щоб дозволити виразити іншу деривацію.

2. помилка і вимагає розрізнення в будь-якому випадку

Перший може випасти природним шляхом, другий вимагає, щоб програміст-компілятор знав про неоднозначність.

Якщо ця неоднозначність залишається невизначеною, можливо, два різних компілятори за замовчуванням для різних виводів для цього неоднозначного виразу. Веде до того, що код є непереносним з незрозумілих причин. Це спонукає людей вважати, що це помилка в одному з компіляторів, хоча насправді це помилка в мовній специфікації.

Я думаю, що питання містить припущення, яке в кращому випадку є правильним лише на кордоні.

У реальному житті досить часто просто жити з неоднозначними граматиками, якщо вони не є (так би мовити) надто неоднозначними.

Наприклад, якщо ви подивитеся на граматики, складені з yacc (або подібними, такими як зубр або byacc), ви побачите, що при їх компілюванні досить багато створюють попередження про "N конфліктів зміщення / зменшення". Коли yacc стикається зі зміною / зменшенням конфлікту, це сигналізує про неоднозначність у граматиці.

Однак конфлікт із зміною / зменшенням, як правило, є досить незначною проблемою. Генератор аналізатора вирішить конфлікт на користь "зрушення", а не зменшення. Граматика цілком чудова, якщо це те, що ти хочеш (і, здається, на практиці це виходить ідеально).

Конфлікт "зсув / зменшення" зазвичай виникає у випадку в цьому загальному порядку (використовуючи обмеження для нетерміналів та малі регістри для терміналів):

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

Коли ми стикаємося з a c, виникає неоднозначність: чи слід розбирати cбезпосередньо як an A, чи слід розбирати його як a B, що, в свою чергу, є A? У такому випадку, yacc і подібні будуть вибирати простіший / коротший маршрут і аналізувати напрям cбезпосередньо як A, а не йти маршрутом c-> B-> A. Це може бути неправильним, але якщо так, це, ймовірно, означає, що у вашій граматиці є дійсно проста помилка, і ви не повинні взагалі допускати cваріант як можливість A.

Тепер, навпаки, у нас може бути щось подібне:

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

Тепер, коли ми стикаємося, у cнас виникає конфлікт між тим, чи слід ставитися до цього cяк до Bабо як C. Набагато менше шансів, що стратегія автоматичного вирішення конфлікту вибере те, що ми насправді хочемо. Жодне з них не є "зрушенням" - і те, і інше - "скорочення", тому це "зменшення / зменшення конфлікту" (яке ті, хто звик до yacc, і таких, як правило, визнають набагато більшою проблемою, ніж конфлікт зміни / зменшення).

Тож, хоча я не впевнений, я б зайшов досить далеко, щоб сказати, що хтось дійсно вітає двозначність у своїй граматиці, принаймні в деяких випадках вона є досить незначною, що нікого насправді багато не цікавить. У рефераті їм може сподобатися ідея усунути всю неоднозначність, але недостатньо, щоб завжди насправді це робити. Наприклад, невелика, проста граматика, яка містить незначну неоднозначність, може бути кращою перед більшою, більш складною граматикою, яка виключає неоднозначність (особливо, коли ви потрапляєте в практичну сферу фактичного генерування парсера з граматики, і виявляєте, що це однозначно граматика виробляє аналізатор, який не працюватиме на вашій цільовій машині).