Вдогонку к - ToDo. Сделать парсинг "старых шаблонов" через построение дерева разбора.
ToDo. Переделать парсинг текстового EVD на парсинг скриптов со специальной аксиоматикой.
Там вообще говоря всё укладывается в общую схему.
Ну поскольку исторически скрипты вырастали из EVD.
Так что теперь - "круг замкнётся".
По результатам - обязательно отпишусь.
Там вся аксиоматика укладывается в текущую EVD-схему ПЛЮС обработку "спецсимволов" типа = { } и %XXX.
Сделать их IMMEDIATE-словами, которые работают со стеком и зовут интерфейс генератора EVD.
Ну и (+) надо сделать "ловушку" UnknownWordHook и там ловить "неизвестные" токены.
В этой ловушке определять, что за токен передан (на основе существующей и уже опубликованной EVD-схемы) и каково состояние стека и звать соответствующие методы интерфейса генератора.
Ну и не забыть про CheckBrackets в парсере.
Ну а потом может и но HTML с RTF дойдём.
Но там скорее всего придётся делать нежадную квантификацию, а может быть рекурсивный парсинг в уже выделенном токене.
А возможно там можно просто правильно настроить списки WordChars, DelimChars и SpaceChars.
Ну и возможно подменять их в зависимости от состояния стековой машины.
Тут надо подумать.
А вот XML и так укладывается в существующую схему за счёт наличия формальной грамматики. Но он нам пока и не сильно то нужен.
А потом можно будет переделать и парсинг бинарного EVD подложив специальный парсер, который выделяет "токены" с фиксированной структурой.
Ну а потом можно будет подумать и о других бинарных форматах типа DOC etc.
Там на самом деле везде примерно стековые структуры, ну или обработка токена с обязательными параметрами справа.
Т.е. на самом деле бинарных форматов не так и много:
1. Либо XML-подобный:
2. Либо asm-подобный:
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 - опять же. И кроссплатформенность.
Если кому-то интересен данный проект - присоединяйтесь.
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 - опять же. И кроссплатформенность.
Если кому-то интересен данный проект - присоединяйтесь.
Комментариев нет:
Отправить комментарий