четверг, 16 июля 2015 г.

ToDo. Переделать парсинг текстового EVD на парсинг скриптов со специальной аксиоматикой

Вдогонку к - ToDo. Сделать парсинг "старых шаблонов" через построение дерева разбора.

ToDo. Переделать парсинг текстового EVD на парсинг скриптов со специальной аксиоматикой.

Там вообще говоря всё укладывается в общую схему.

Ну поскольку исторически скрипты вырастали из EVD.

Так что теперь - "круг замкнётся".

По результатам - обязательно отпишусь.

Там вся аксиоматика укладывается в текущую EVD-схему ПЛЮС обработку "спецсимволов" типа = { } и %XXX.

Сделать их IMMEDIATE-словами, которые работают со стеком и зовут интерфейс генератора EVD.

Ну и (+) надо сделать "ловушку" UnknownWordHook и там ловить "неизвестные" токены.

В этой ловушке определять, что за токен передан (на основе существующей и уже опубликованной EVD-схемы)  и каково состояние стека и звать соответствующие методы интерфейса генератора.

Ну и не забыть про CheckBrackets в парсере.

Ну а потом может и но HTML с RTF дойдём.

Но там скорее всего придётся делать нежадную квантификацию, а может быть рекурсивный парсинг в уже выделенном токене.

А возможно там можно просто правильно настроить списки WordChars, DelimChars и SpaceChars.

Ну и возможно подменять их в зависимости от состояния стековой машины.

Тут надо подумать.

А вот XML и так укладывается в существующую схему за счёт наличия формальной грамматики. Но он нам пока и не сильно то нужен.

А потом можно будет переделать и парсинг бинарного EVD подложив специальный парсер, который выделяет "токены" с фиксированной структурой.

Ну а потом можно будет подумать и о других бинарных форматах типа DOC etc.

Там на самом деле везде примерно стековые структуры, ну или обработка токена с обязательными параметрами справа.

Т.е. на самом деле бинарных форматов не так и много:

1. Либо XML-подобный:
<a>
 <b>
 ...
 </b>
</a>

2. Либо asm-подобный:

[prefix1 .. prefixK] instruction I1 [param1 .. paramM]
...
[prefix1 .. prefixK] instruction IN [param1 .. paramM]

3. Либо их комбинация.

Самый "плохой" формат в этом плане то HTML.

Причём обычно "обратного разбора" (Backtracking Поиск с возвратом, бэктрекинг) уже распарсенных данных там НЕ ТРЕБУЕТСЯ.

Люди обычно НЕ ЛОМАЮТ себе мозги своими форматами данных. И с Backtracking'ом обычно не связываются.

А если всё-так возможен Backtrecking, то значит есть точка "фиксации стека" и точка "возврата к фиксированнному значению". Ну или "сброс фиксированного значения".

То есть просто нужен "второй стек". Ну или "стек стеков".

Но это - вряд ли.

То есть:

Парсер входного потока на токены -> Стековая машина (+) Аксиоматика -> Фильтр1 .. ФильтрN -> Генератор

Ну расширяем схему - Обработка текстов. Генераторы, фильтры, трансформаторы и "SAX на коленке".

1. Парсер разбивает входной поток на минимальные токены.
2. Стековая машина преобразует набор токенов в дерево разбора.
3. Фильтры трансформируют дерево разбора.
4. Генератор преобразует дерево разбора в целевой язык.

Почти в соответствии с:

"Болье Л. Методы построения компиляторов. В кн.: Языки программирования /Под ред.Ф.Женюи, м., Мир, 1972, с.87-276.

Научная библиотека диссертаций и авторефератов disserCat http://www.dissercat.com/content/razrabotka-adaptivnogo-metoda-postroeniya-i-organizatsii-kross-kompilyatorov-protsedurno-ori#ixzz3g5rXwthj"

И через пару лет будет у меня "универсальный парсинг". Если к тому времени это будет ещё кому-то нужно.

А вообще уже давно пора переводить реализацию "моих скриптов" на какой-нибудь "вменяемый" и "вечный" язык типа C++.

Ну и stl с boost - опять же. И кроссплатформенность.

Если кому-то интересен данный проект - присоединяйтесь.

Комментариев нет:

Отправить комментарий