Чи має висновок аналізатора бути деревом чи це також може бути загальний графік?
Більше того, чи існує якась існуюча мова чи правдоподібна мова, яка використовує загальне подання графіків замість дерев для свого синтаксису?
Відповіді:
Виведенням аналізатора не повинно бути дерево. Дійсно, коли ви враховуєте такі речі, як посилання з USE змінної на її DEFinition, накладені на абстрактне синтаксичне дерево, у вас одразу з’являється графік.
Річ у тім, що синтаксичний аналіз зазвичай розроблений за один прохід - це було важливо з історичних причин, таких як відсутність місця та швидкості процесора, а також тому, що простіше міркувати. Потім наступні фази прикрашають дерево розбору додатковою інформацією.
Є такі речі, як граматика графів, хоча я не знаю, чи використовуються вони для розбору мов програмування.
Питання ОП дещо відстало. Звичайно, алгоритм розбору може вивести все, що він хоче. Питання полягає в тому, щоб зрозуміти, що таке синтаксичний розбір і чи дає аналізатор результат, який відповідає цій меті. Тоді можна задатися питанням, що є відповідним поданням для цього, наприклад, деревом чи графіком.
Я думаю, що аналізатор - це алгоритм, який надасть вам синтаксичну структуру речення, поданого як вхідне, відповідно до заданого формального визначення синтаксису мови.
Зауважте, що люди можуть не погодитися з приводу того, що становить синтаксис мови. Деякі можуть обмежити це чистою формальною основою мови, тоді як інші можуть ввести трохи більш семантичні міркування, такі як тип, жанр, кількість чи інші складніші (я не розрізняю НЛП чи мови програмування). Більшість мов мають функції, які вимагають представлення графіків, але вирішувати, чи хоче він включити це в синтаксис, вирішувати, чи хоче він включити його у грані.
Отже, залежно від того, яким ви визначаєте синтаксис, можливо, вам доведеться виводити різний вид формальної структури.
У простому випадку чистого розбору без контексту дерево розбору може зробити, за винятком проблеми неоднозначності, розглянутої нижче, або для того, що ви можете трохи змінити його, щоб отримати AST (див. Нижче).
Однак у більш складних випадках вам можуть знадобитися різні структури, часто представлені посиланнями на дереві, тим самим приводячи до структури графіків. Це дуже залежить від вашого визначення синтаксису мови.
Крім того, яке дерево ви повинні вивести не очевидно. Якщо взяти справу із суміжними з деревами граматиками (TAG), вони працюють таким чином, що синтаксичне дерево не є таким, як дерево деривації, хоча перше може бути похідне від другого. Яке ви хочете вивести, може бути відповідним питанням.
Існує ще одне питання щодо неоднозначності. Дане речення, хоча воно належить до вашої мови, може робити це різними способами, може присвоювати синтаксичну структуру різними способами.
Тоді ви можете вивести лише одну з цих структур, вибрану випадковим чином або за певним чітко визначеним критерієм (наприклад, ймовірність). Ви також можете вибрати декілька або всі з них. Якщо ви хочете вивести кілька, зазвичай упакувати зручно в унікальну структуру, яка поділиться тим, що у них є спільним. Це економить на просторі та на обчисленні часу, а складність може бути справжньою проблемою.
Коли ви вирішите вивести їх усі, у вас немає іншого вибору, як поділитися, оскільки може бути нескінченна кількість можливих синтаксисів. І нескінченно можна придушувати безмежно, лише маючи якось цикл у графіку. Таким чином, ви повинні створити структуру графа в цілому. Але властивості цієї структури графа мають бути пов’язані з обраним вами формальним синтаксисом.
Тепер питання стосувалося також абстрактних синтаксичних дерев. Я пропустив "абстрактну" частину, оскільки це призведе до плутанини, imho. Дійсно, питання вже заплутане в різних його переказах.
Що стосується AST в історичній перспективі, вони походять з мовою Lisp та системами програмних маніпуляцій у 1960-1970 роках. Ідея полягала в тому, щоб розглянути програми як великі вирази, як математичні формули, як з метою маніпуляції, так і аналізувати властивості або визначати семантику формально, що математики знають, як робити за формулами. Як формули, вони були природно структурованими деревами, але могли бути прикрашені різною інформацією, яка перетворила ці дерева на графіки. Це було зручно і формально, і прагматично, і далі використовувалося компіляторами та системами програмування.
Отже, AST - це дерево, як випливає з назви, але може нести додаткову інформацію. Решта - у виборах виконавця та в очах глядача. Це графік чи прикрашене дерево? Однак основне дерево AS має значення, тому що це риштування, які ви будуєте як в теорії, так і в програмуванні.
Зауважимо, що AST відрізнявся від дерева розбору (синтаксис базувався на контексті), створеного алгоритмом розбору, як вивчали в формальній теорії мови. Причина полягала в тому, що дизайн синтаксису був обмежений технологією розбору часу, який був обмежений низькою доступною обчислювальною потужністю. Результатом цього стало те, що синтаксичні дерева були лише катуючими варіантами того, що, природно, було б розглянуто структурою програми, і подальша обробка, яка не є частиною основного процесу формального розбору, повинна була бути виконана, щоб отримати більш чисту і просту версію під назвою AST.
Однак подання дерев на комп'ютері, чи то абстрактне чи ні, дещо обмежене, коли потрібно зобразити всі структури неоднозначного речення. Зокрема, це приховує проблеми складності. Збереження неоднозначностей у структурі графіків при перекладі з дерев розбору на AS Дерева також може бути проблемою. Однак якщо ви переймаєтесь цим, часто можна визначити ваш конкретний синтаксис таким чином, щоб дерево розбору могло слугувати AST. Це дозволено дуже загальними алгоритмами, які керують двозначністю, та потужністю сучасних комп'ютерів.
Якщо ви аналізуєте, використовуючи аналіз GLR (Узагальнений LR), і якщо розбір вводу неоднозначний (існує кілька можливих способів розбору вводу), то результат аналізу можна розглядати як розбір DAG, а не як розбір дерева. Аналіз розбору DAG компактно кодує безліч можливих синтаксичних розробок: кілька можливих дерев розбору.
Однак у нижньому рядку залишається, що якщо у вас є без контексту граматика, і якщо ваша вхідна рядок однозначно піддається синтаксичному аналізу (є лише одне виведення в граматиці, яка виробляє цю вхідну рядок), і якщо завдання розбору полягає у створенні ця деривація ... тоді в цих умовах результатом розбору завжди обов'язково буде дерево розбору, оскільки будь-яке виробництво без контексту граматики по суті має структуру дерева.
Я одного разу написав інтерпретатора для C, в якому "AST" для оператора + = (наприклад) не було деревом. Поміркуйте, a[i++] += dде a[i++]є intі dє double. Неявні операції конверсії та вилучення були явними в дереві, тому проблема полягає в тому, де розмістити виборку a[i++]та перетворення подвоїти. Нашим рішенням було відмовитися від дерев. Отриманий "ASG" виглядав приблизно так
+=
/ | \
/ | \
/ | \
/ convert \
| | \
| fetch fetch
| / |
index d
/ \
a postinc
|
i
Мене це спантеличило, поки я щойно не зрозумів, що це не абстрактне дерево, не про якесь абстрактне «синтаксичне дерево», а синтаксис - абстрактний.
Отже, щоб відповісти на ваше запитання, я роблю висновок, що абстрактне синтаксичне дерево, а також конкретне синтаксичне дерево або дерево рішення або будь-яке інше дерево краще має бути деревом.
З іншого боку, ніщо не повинно перешкоджати використанню абстрактного графіка синтаксису, або абстрактної синтаксичної діаграми, або абстрактного синтаксичного куба, або абстрактної специфікації синтаксису.
Я думаю, абстрактне синтаксичне дерево "абстрактного синтаксичного дерева" допомогло б мені уникнути плутанини.