Ім'я для цього типу аналізатора, АБО чому його не існує

Звичайні парсери споживають весь свій внесок і виробляють єдине дерево розбору. Я шукаю той, який споживає безперервний потік і створює ліс розбору [ редагувати: див. Обговорення в коментарях щодо того, чому використання цього терміна може бути нетрадиційним ]. Моя кишка говорить, що я не можу бути першою людиною, яка потребує (або вважаю, що мені потрібна) такий синтаксичний аналіз, але я шукав і шукав місяці безрезультатно.

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

Отже, моє запитання умовне: якщо клас парсерів з цими характеристиками існує, як він називається? А якщо ні, то чому б і ні? Яка альтернатива? Можливо, мені не вистачає способу змусити звичайні парсери робити те, що я хочу.

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

Викликається аналізатор, який повертає ліс усіх можливих дерев розбору, тобто повертає дерево розбору для кожного можливого виведення неоднозначної граматики… Я не впевнений, чи мають ці речі ще ім’я. Я знаю, що генератор аналізатора Marpa здатний на це, але будь-який аналізатор на основі Ерлі або GLR повинен бути в змозі зняти це.

Однак ти, схоже, нічого з цього не хочеш. У вас є потік з декількома вбудованими документами, зі сміттям між ними:

 garbagegarbage{key:42}garbagegarbage[1,2,3]{id:0}garbage...

Ви, здається, хочете аналізатор, який пропускає сміття, і (ліниво) дає послідовність ASTs для кожного документа. Це може вважатися поступовим аналізатором у загальному сенсі. Але ви насправді реалізуєте цикл таким чином:

while stream is not empty:
  try:
    yield parse_document(stream at current position)
  except:
    advance position in stream by 1 character or token

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

Ледача токенізація - це, мабуть, найелегантніше рішення завдяки вашому потоку введення. Замість того, щоб фаза лексери створювала фіксований список лексем, аналізатор ліниво запитав наступний маркер із зворотного виклику лексера ^[1] . Тоді лексер споживає стільки, скільки потрібно. Таким чином, аналізатор може вийти з ладу лише тоді, коли досягнуто реального кінця потоку або коли відбулася реальна помилка розбору (тобто ми почали розбирати, поки ще перебуваєте у смітті).

^{[1] лексер, керований зворотним викликом, є хорошою ідеєю також і в інших контекстах, оскільки це може уникнути деяких проблем із узгодженням з найдовшим токеном .}

Якщо ви знаєте, які саме документи ви шукаєте, ви можете оптимізувати пропуск, щоб зупинитися лише на перспективних місцях. Наприклад, документ JSON завжди починається з символу {або [. Тому сміття - це будь-яка рядок, яка не містить цих символів.

Не існує жодного конкретного імені для аналізатора, який би це робив. Але я виділю один алгоритм, який робить це: розбір похідних .

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

Розбір з похідними обробляє без контекстних граматик і створить ліс для розбору неоднозначних граматик.

Це насправді елегантна теорія, але вона лише в зародковому стані і не широко розгорнута. У Matt Might є список посилань на різні реалізації у Scala / Racket / тощо.

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

Далеко від ідеалу, але я бачив це вже не раз: у кожному вхідному рядку спробуйте проаналізувати. якщо не вдалося, збережіть рядок і додайте наступний. У псевдокоді:

buffer = ''
for each line from input:
    buffer = buffer + line
    if can parse buffer:
        emit tree
        buffer = ''

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

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

Коротко

Здається, що швидке рішення вашої проблеми полягає у визначенні REGEX, або FSA (автомат з обмеженим станом), який розпізнає всі можливі початки документів (помилкові позитиви дозволені, що фактично не відповідало б документу). Потім ви можете запустити його дуже швидко на своєму введенні, щоб визначити наступне місце, де документ може починатися з кількох помилок. Це може спричинити кілька помилкових позицій для запуску документа, але вони будуть розпізнані парсером і залишені.

Тож Finite State Automaton може бути назвою парсера, якого ви шукали. :)

Проблема

Завжди важко зрозуміти практичну проблему, особливо коли словниковий запас може мати багато тлумачень. Слово "розбір лісу" було придумано (afaik) для безтекстового розбору неоднозначних речень, які мають кілька дерев розбору. Це може бути дещо узагальнено для розбору решітки речень або до інших типів граматики. Звідси всі відповіді про Ерлі, GLR, Marpa та похідні аналізатори (є багато інших), які не були актуальними в даному випадку.

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

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

Це також рішення, запропоноване @amon у другій частині своєї відповіді .

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

Тож вам справді потрібен алгоритм, який дозволяє швидко знайти початок документа, який починається з маси сміття. І вам пощастило: такі алгоритми існують. І я впевнений, що ви це знаєте: це називається пошук REGEX.

Просте рішення

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

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

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

Я припускаю:
- docstartце регулярний вираз, який відповідає початку всіх документів,
- search(regex, stream)це функція, яка шукає streamпідрядку, яка відповідає regex. Коли він повертається, потік зменшується до підпотоку суфіксу, починаючи з початку першого підрядного збігу, або до порожнього потоку не знайдено відповідності.
- parse(stream)намагається проаналізувати документ з початку потоку (те, що від нього залишилося), і поверне дерево розбору в будь-якому форматі або не вдасться. Коли він повертається, потік зменшується до підпотоку суфіксу, починаючи з позиції, безпосередньо після закінчення проаналізованого документа. Він називає виняток, якщо аналіз не вдається.

forest = empty_forest
search(docstart, stream)
while stream is not empty:
  try:
    forest = forest + parse(stream)
  except
    remove first character from stream
  search(docstart, stream)

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

Звичайно, вкорочення потоку - це зображення. Це може бути просто індекс на потоці.

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

Тож це, можливо, допоможе спростити регулярний вираз, якщо це корисно.

Про можливість швидшого вирішення

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

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

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

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

Те, що ви описуєте, можна охарактеризувати як SAX vs. SOM.

SAX - (Simple API для XML) - API аналізатора послідовного доступу до подій, розроблений списком розсилки XML-DEV для документів XML.

SOM - (Об'єктна модель XML-схеми) випадковий доступ до представлення пам'яті XML-файлу в пам'яті

Є реалізація обох типів у C # та Java та, ймовірно, ще багато інших. Зазвичай XSD або DTD не є обов'язковим.

Радість SAX полягає в тому, що він має низькі накладні витрати, що чудово підходить для великих XML-файлів. Компроміс полягає в тому, що випадковий доступ із використанням SAX або не існує, або повільний, а гірший час розробки зазвичай значно більший, ніж для SOM. Очевидною проблемою для SOM є потенційно великі вимоги ОЗУ.

Ця відповідь застосовується не для всіх платформ та всіх мов.