Відповіді:
Насправді є три варіанти, всі три бажаніші в різних ситуаціях.
Скажімо, вас просять створити аналізатор для давнього формату даних ЗАРАЗ. Або вам потрібен ваш парсер, щоб бути швидким. Або вам потрібен ваш парсер, щоб бути легко ремонтом.
У цих випадках вам, мабуть, найкраще використовувати генератор парсера. Вам не доведеться поспішати з деталями, вам не потрібно мати багато складного коду для належної роботи, ви просто виписуєте граматику, до якої буде дотримуватися вхід, написати якийсь код обробки та presto: миттєвий парсер.
Переваги зрозумілі:
Є одна річ, з якою ви повинні бути обережними з генераторами аналізаторів: іноді вони можуть відкидати ваші граматики. Для огляду різних типів парсерів та того, як вони можуть вас вкусити, ви можете почати тут . Тут ви можете знайти огляд багатьох реалізацій та типів граматик, які вони приймають.
Генератори парсерів приємні, але вони не дуже зручні для користувача (кінцевий користувач, не ви). Зазвичай ви не можете давати хороші повідомлення про помилки, а також не можете забезпечити відновлення помилок. Можливо, ваша мова дуже дивна, і парсери відкидають вашу граматику, або вам потрібно більше контролю, ніж дає вам генератор.
У цих випадках використання рукописного рекурсивно-розбірного аналізатора, мабуть, найкраще. Хоча виправити це може бути складним, ви маєте повний контроль над своїм парсером, щоб ви могли робити всілякі приємні речі, які ви не можете зробити з генераторами аналізаторів, як-от повідомлення про помилки та навіть відновлення помилок (спробуйте видалити всі крапки з комою з файлу C # : компілятор C # поскаржиться, але все одно виявить більшість інших помилок незалежно від наявності крапки з комою).
Рукописні парсери також зазвичай краще, ніж створені, якщо якість аналізатора є досить високою. З іншого боку, якщо вам не вдається написати хороший синтаксичний аналіз, як правило, через (поєднання) відсутності досвіду, знань чи дизайну - тоді ефективність, як правило, повільніше. Для лексерів справедливе все навпаки: загальногенеровані лексеми використовують пошукові таблиці, що робить їх швидшими, ніж (більшість) рукописних.
Навчання за освітою, написання власного аналізатора навчить вас більше, ніж використання генератора. Зрештою, ви повинні написати все більш складний код, плюс ви повинні зрозуміти, як саме ви розбираєте мову. З іншого боку, якщо ви хочете навчитися створювати свою власну мову (так, набудьте досвіду мовного дизайну), переважний варіант 1 або 3 - якщо ви розробляєте мову, це, ймовірно, дуже зміниться, а варіанти 1 і 3 полегшують час.
Це шлях, яким я зараз ходжу: ви пишете власний генератор парсера. Хоча це нетривіально, але це, мабуть, навчить вас найбільше.
Щоб дати вам уявлення, що стосується такого проекту, я розповім про власний прогрес.
Генератор лексерів
Я створив власний генератор лексерів першим. Зазвичай я розробляю програмне забезпечення, починаючи з того, як буде використовуватися код, тому я подумав про те, як я хотів би використовувати свій код, і написав цей фрагмент коду (це в C #):
Lexer<CalculatorToken> calculatorLexer = new Lexer<CalculatorToken>(
new List<StringTokenPair>()
{ // This is just like a lex specification:
// regex token
new StringTokenPair("\\+", CalculatorToken.Plus),
new StringTokenPair("\\*", CalculatorToken.Times),
new StringTokenPair("(", CalculatorToken.LeftParenthesis),
new StringTokenPair(")", CalculatorToken.RightParenthesis),
new StringTokenPair("\\d+", CalculatorToken.Number),
});
foreach (CalculatorToken token in
calculatorLexer.GetLexer(new StringReader("15+4*10")))
{ // This will iterate over all tokens in the string.
Console.WriteLine(token.Value);
}
// Prints:
// 15
// +
// 4
// *
// 10
Пари вхідних рядків-лексеми перетворюються у відповідну рекурсивну структуру, що описує регулярні вирази, які вони представляють, використовуючи ідеї арифметичного стека. Потім він перетворюється на NFA (недетермінований кінцевий автомат), який у свою чергу перетворюється на DFA (детермінований кінцевий автомат). Потім можна зіставити рядки проти DFA.
Таким чином ви отримуєте гарне уявлення про те, як саме працюють лексеми. Крім того, якщо ви зробите це правильно, результати від вашого генератора лексерів можуть бути приблизно такими ж швидкими, як і професійні реалізації. Ви також не втрачаєте ніякої виразності порівняно з варіантом 2, і не надто виразною порівняно з варіантом 1.
Я реалізував свій генератор лексерів трохи більше 1600 рядків коду. Цей код робить вищезгадану роботу, але він все одно генерує лексеру під час кожного запуску програми: я збираюся додати код, щоб записати його на диск у якийсь момент.
Якщо ви хочете знати, як написати власний лексер, це хороше місце для початку.
Генератор парсера
Потім ви пишете генератор парсера. Я маю на увазі сюди знову для огляду на різних видах аналізаторів - як правило, тим більше вони можуть розібрати, тим повільніше вони.
Швидкість не була проблемою для мене, я вирішив реалізувати аналізатор Ерлі. Показано, що розширені реалізації парсера Earley виявляються приблизно вдвічі повільнішими, ніж інші типи парсера.
Натомість за цей швидкісний удар ви отримуєте можливість розбору будь -яких граматик, навіть неоднозначних. Це означає, що вам ніколи не потрібно турбуватися про те, чи є у вашого аналізатора будь-яка ліва рекурсія в ньому, або що таке конфлікт зменшення зрушення. Ви також можете визначити граматики легше, використовуючи неоднозначні граматики, якщо не має значення, яке дерево розбору є результатом, наприклад, що це не має значення, розбираєте 1 + 2 + 3 як (1 + 2) +3 або як 1 + (2 + 3).
Ось як може виглядати фрагмент коду за допомогою мого генератора аналізаторів:
Lexer<CalculatorToken> calculatorLexer = new Lexer<CalculatorToken>(
new List<StringTokenPair>()
{
new StringTokenPair("\\+", CalculatorToken.Plus),
new StringTokenPair("\\*", CalculatorToken.Times),
new StringTokenPair("(", CalculatorToken.LeftParenthesis),
new StringTokenPair(")", CalculatorToken.RightParenthesis),
new StringTokenPair("\\d+", CalculatorToken.Number),
});
Grammar<IntWrapper, CalculatorToken> calculator
= new Grammar<IntWrapper, CalculatorToken>(calculatorLexer);
// Declaring the nonterminals.
INonTerminal<IntWrapper> expr = calculator.AddNonTerminal<IntWrapper>();
INonTerminal<IntWrapper> term = calculator.AddNonTerminal<IntWrapper>();
INonTerminal<IntWrapper> factor = calculator.AddNonTerminal<IntWrapper>();
// expr will be our head nonterminal.
calculator.SetAsMainNonTerminal(expr);
// expr: term | expr Plus term;
calculator.AddProduction(expr, term.GetDefault());
calculator.AddProduction(expr,
expr.GetDefault(),
CalculatorToken.Plus.GetDefault(),
term.AddCode(
(x, r) => { x.Result.Value += r.Value; return x; }
));
// term: factor | term Times factor;
calculator.AddProduction(term, factor.GetDefault());
calculator.AddProduction(term,
term.GetDefault(),
CalculatorToken.Times.GetDefault(),
factor.AddCode
(
(x, r) => { x.Result.Value *= r.Value; return x; }
));
// factor: LeftParenthesis expr RightParenthesis
// | Number;
calculator.AddProduction(factor,
CalculatorToken.LeftParenthesis.GetDefault(),
expr.GetDefault(),
CalculatorToken.RightParenthesis.GetDefault());
calculator.AddProduction(factor,
CalculatorToken.Number.AddCode
(
(x, s) => { x.Result = new IntWrapper(int.Parse(s));
return x; }
));
IntWrapper result = calculator.Parse("15+4*10");
// result == 55
(Зауважте, що IntWrapper - це просто Int32, за винятком того, що C # вимагає, щоб це був клас, отже, мені довелося ввести клас обгортки)
Сподіваюсь, ви бачите, що код вище дуже потужний: будь-яка граматика, яку ви можете придумати, може бути проаналізована. Ви можете додати довільні біти коду в граматику, здатні виконувати безліч завдань. Якщо вам вдасться змусити все це працювати, ви можете повторно використовувати отриманий код, щоб зробити дуже багато завдань дуже легко: просто уявіть, як створити інтерпретатор командного рядка за допомогою цього фрагмента коду.
Якщо ви ніколи і ніколи не писали парсера, я б рекомендував вам це зробити. Це весело, і ти дізнаєшся, як все працює, і ти навчишся цінувати зусилля, які парсер і генератори лексерів рятують тебе від наступного разу, коли потрібен парсер.
Я б також запропонував вам спробувати прочитати http://compilers.iecc.com/crenshaw/, оскільки у нього дуже глибоке ставлення до того, як це зробити.
Перевага написання власного рекурсивного аналізатора походження полягає в тому, що ви можете генерувати якісні повідомлення про помилки на синтаксичних помилках. Використовуючи генератори парсера, ви можете робити помилки та додавати власні повідомлення про помилки в певні моменти, але генератори аналізаторів просто не відповідають потужності повного контролю над синтаксичним розбором.
Ще одна перевага написання вашого власного полягає в тому, що простіше розібратися до більш простого представлення, яке не відповідає листуванню вашій граматиці.
Якщо ваша граматика виправлена, а повідомлення про помилки важливі, подумайте про те, як прокрутити своє або хоча б використовувати генератор аналізатора, який дає вам потрібні повідомлення про помилки. Якщо ваша граматика постійно змінюється, вам слід замість цього використовувати генератори парсера.
Bjarne Stroustrup розповідає про те, як він використовував YACC для першої реалізації C ++ (див . Дизайн та еволюція C ++ ). У цьому першому випадку він хотів, щоб він написав власний рекурсивний аналізатор спуску!
Варіант 3: Ні (згорніть власний генератор парсера)
Просто тому , що є причина , щоб не використовувати ANTLR , бізон , Coco / R , Grammatica , JavaCC , лимон , пропарений , SableCC , Quex , і т.д. - це не означає , що ви повинні негайно згорнути свій власний парсер + Лексер.
Визначте, чому всі ці інструменти недостатньо хороші - чому вони не дозволяють вам досягти своєї мети?
Якщо ви не впевнені, що дивацтва граматики, з якою ви маєте справу, унікальні, ви не повинні просто створювати єдиний спеціальний аналізатор + лексеру для нього. Натомість створіть інструмент, який створить те, що ви хочете, але також може бути використаний для задоволення майбутніх потреб, а потім випустіть його як безкоштовне програмне забезпечення, щоб не допустити інших людей до тієї ж проблеми, що і ви.
Прокат власного парсера змушує задуматися безпосередньо про складність вашої мови. Якщо мову важко розібрати, ймовірно, це буде важко зрозуміти.
У ранніх часів у генераторів парсера був великий інтерес, мотивований сильно складним (дехто би сказав "мученим") синтаксисом мови. JOVIAL був особливо поганим прикладом: для нього потрібні два символи пошуку, в той час, коли все інше вимагало не більше одного символу. Це зробило створення аналізатора для компілятора JOVIAL складніше, ніж очікувалося (оскільки General Dynamics / Fort Worth Division дізнався важкий шлях, коли вони закуповували компілятори JOVIAL для програми F-16).
Сьогодні рекурсивний спуск є загальнолюдським способом, оскільки це легше для письменників-укладачів. Компілятори рекурсивного походження сильно винагороджують просту, чисту мовну конструкцію, оскільки набагато простіше написати рекурсивно-розбірний аналізатор для простої, чистої мови, ніж для перекрученої, безладної.
Нарешті: Ви думали про те, щоб вкласти свою мову в LISP та дозволити перекладачеві LISP зробити важкий підйом для вас? AutoCAD зробив це, і виявив, що це полегшило їхнє життя. Існує досить багато легких перекладачів LISP, деякі вбудовані.
Я написав аналізатор комерційного застосування один раз, і я використав yacc . Був конкуруючий прототип, де розробник писав все це вручну в C ++, і він працював приблизно в п’ять разів повільніше.
Щодо лексеру для цього аналізатора, то я написав його цілком від руки. Знадобилося - вибачте, це було майже 10 років тому, так що я не пам'ятаю точно - близько 1000 рядків в C .
Причиною, чому я написав лексеру вручну, була граматика введення парсера. Це було вимогою, моєму виконанню аналізатора довелося відповідати, на відміну від того, що я задумав. (Звичайно, я б спроектував це інакше. І краще!) Граматика сильно залежала від контексту і навіть лексика залежала від семантики в деяких місцях. Наприклад, крапка з комою може бути частиною лексеми в одному місці, а роздільник в іншому місці - на основі семантичної інтерпретації якогось елемента, який був розібраний раніше. Отже, я "закопав" такі семантичні залежності в рукописному лексемі, і це залишило мене досить прямим BNF, який було легко реалізувати в yacc.
ДОБАВЕНО у відповідь на Macneil : yacc надає дуже потужну абстракцію, яка дозволяє програмісту думати над терміналами, нетерміналами, виробництвами тощо. Також при реалізації yylex()функції мені допомогло зосередитись на тому, щоб повернути поточний маркер і не турбуватися про те, що було до або після нього. Програміст на C ++ працював на рівні символів, без вигоди такої абстракції, і в кінцевому підсумку створив складніший і менш ефективний алгоритм. Ми зробили висновок, що повільна швидкість не має нічого спільного з самим C ++ або будь-якими бібліотеками. Ми вимірювали чисту швидкість розбору з файлами, завантаженими в пам'ять; якби у нас була проблема буферизації файлів, yacc не був би нашим інструментом вибору для її вирішення.
ТАКОЖ ХОЧЕ ДОДАТИ : це взагалі не рецепт написання парсерів, а лише приклад того, як це працювало в одній конкретній ситуації.
Це повністю залежить від того, що потрібно розбирати. Чи можете ви скочувати своє швидше, ніж ви могли б вдарити криву навчання лексеру? Чи потрібно проаналізувати матеріал досить статично, щоб згодом ви не пошкодували про рішення? Чи вважаєте Ви існуючі реалізації надмірно складними? Якщо так, то весело прокатуйте свої власні, але лише у тому випадку, якщо ви не втягуєте криву навчання.
Останнім часом мені дуже подобається аналізатор лимона , який, мабуть, найпростіший і найпростіший, що я коли-небудь використовував. Для того, щоб зробити речі легкими в обслуговуванні, я просто використовую це для більшості потреб. SQLite використовує його, як і деякі інші помітні проекти.
Але мене лексери зовсім не цікавлять, поза ними вони не заважають, коли мені потрібно використовувати один (отже, лимонний). Ви можете бути, і якщо так, то чому б не зробити його? У мене є відчуття, що ти знову повернешся до того, хто існує, але почухаєш свербіж, якщо треба :)
Це залежить від того, яка ваша мета.
Ви намагаєтесь дізнатися, як працюють парсери / компілятори? Тоді напишіть своє з нуля. Це єдиний спосіб, коли ти насправді навчишся цінувати всі плюси і мінуси того, що вони роблять. Я писав один за останні кілька місяців, і це було цікавим і цінним досвідом, особливо "ах, так ось чому мова X робить це ..." моменти.
Вам потрібно швидко скласти щось для подання заявки? Тоді можливо скористайтеся інструментом розбору.
Вам потрібно щось, що ви хочете розгорнути протягом наступних 10, 20, може, навіть 30 років? Напишіть своє та знайдіть час. Це буде добре того варте.
Чи ви розглядали підхід до роботи з мовою у стилі Мартіна Фаулерса ? Цитуючи із статті
Найбільш очевидною зміною, яку вносить мовний робочий стіл до рівняння, є простота створення зовнішніх DSL. Вам більше не потрібно писати аналізатор. Вам потрібно визначити абстрактний синтаксис - але це насправді досить простий крок моделювання даних. Крім того, ваш DSL отримує потужний IDE - хоча вам доведеться витратити деякий час на визначення цього редактора. Генератор - це все-таки щось, що вам потрібно зробити, і я відчуваю, що це не набагато простіше, ніж коли-небудь. Але тоді створення генератора для хорошого і простого DSL - це одна з найпростіших частин вправи.
Читаючи це, я б сказав, що дні написання власного аналізатора закінчились, і краще скористатися однією з наявних бібліотек. Після того, як ви освоїли бібліотеку, всі ці DSL, які ви створюєте в майбутньому, виграють від цих знань. Крім того, інші не повинні вивчати ваш підхід до розбору.
Редагувати, щоб висвітлити коментар (і переглянути питання)
Переваги прокатки самостійно
Отже, коротше кажучи, ви повинні закатати свою власну, коли хочете по-справжньому вибити глибоко в недрах серйозно складну проблему, яку ви відчуваєте сильною мотивацією до оволодіння.
Переваги використання чужої бібліотеки
Тому, якщо ви хочете швидкого кінцевого результату, використовуйте чужу бібліотеку.
Загалом, це зводиться до вибору того, наскільки ви хочете володіти проблемою, а отже, і рішенням. Якщо ви хочете все це, тоді згортайте своє.
Великою перевагою в написанні свого є те, що ви знаєте, як написати своє. Великою перевагою використання такого інструменту, як yacc, є те, що ви знаєте, як користуватися інструментом. Я фанат верхівки дерев для початкових розвідок.
Чому б не роздрібнити генератор аналізатора з відкритим кодом та зробити його власним? Якщо ви не використовуєте генератори парсеру, код буде важко підтримувати, якщо ви змінили синтаксис своєї мови.
У своїх аналізаторах я використовував регулярні вирази (я маю на увазі стиль Perl) для токенізації та використання деяких зручних функцій для підвищення читабельності коду. Однак, генерований парсером код може бути швидшим, створюючи таблиці стану та long switch- cases, що може збільшити розмір вихідного коду, якщо ви не .gitignoreїх.
Ось два приклади моїх написаних на замовлення аналізаторів:
https://github.com/SHiNKiROU/DesignScript - БАЗОВИЙ діалект, тому що я був ледачий, щоб писати лукади в нотації масиву, я пожертвував якістю повідомлень про помилки https://github.com/SHiNKiROU/ExprParser - калькулятор формул. Зауважте дивні хитрощі метапрограмування
"Чи варто використовувати це перевірене" колесо "або винаходити його знову?"