[Программирование, Алгоритмы, Компиляторы] Про LL-парсинг: Предложение по расширению грамматик для генераторов парсеров
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
В некоторых генераторах нисходящего(LL) синтаксического анализа с увеличением объема текста исходного кода время парсинга увеличивается в более чем арифметической прогрессии.
Идея состоит в том, чтобы ввести в самом парсере понятие препарсинга — разбиение текста исходной программы на блоки для отдельного парсинга.
Тексты программ имеют блочную структуру.
к примеру
1 уровень — namespace
2 уровень — классы
3 уровень — методы и свойства
и т.д.
Для Си-подобных языков блоки это просто {}
В языке же Clipper, например,
1 уровень — процедуры/функции/методы, классы, директивы
правило начала процедуры/функции:
funcProc
: funScope? (FUNCTION | PROCEDURE) identName ('(' params? ')')? crlfStmnt
;
funScope
: STATIC
| INIT
| EXIT
;
Окончанием процедуры/функции может быть
RETURN ( expression )? crlfStmnt
но RETURN может и отсутствовать, тогда окончанием будет EOF или начало блока первого уровня.
В генераторе парсеров ANTLR для грамматики можно устанавливать опции.
Т.е. мы можем определить
options { PreParse=ON; }
и после этого для правил указывать атрибуты, например:
[PreParseLevel = 1]
funcProcSection
: funcProcHead
statements
;
Также некоторые конструкции такие как лямбды/анонимные функции могут быть тоже выделены для отдельного парсинга. Для них можно установить PreParseLevel = 0.
Целью синтаксического анализа является построение дерева синтаксического разбора(abstract syntax tree (AST)). В процессе парсинга мы будем получать для каждого блока свое дерево, которое потом можно прицепить к основному дереву.
Конечно, кто-то использует парсер-комбинаторы и для него это все понятно и так.
Хотелось бы увидеть комментарии о данной концепции.
Разумно ли все это?
Применялось ли где?
Применяли ли вы в своей работе?
Стоит ли выносить это на обсуждение в англоязычном сообществе?
With best regards
===========
Источник:
habr.com
===========
Похожие новости:
- Релиз набора компиляторов LLVM 11.0
- [Алгоритмы, Математика, Машинное обучение] Курсы Computer Science клуба теперь онлайн
- [Тестирование IT-систем, Java, Тестирование веб-сервисов] Flame-графики: «огонь» из всех движков (перевод)
- [JavaScript, ReactJS, Программирование, Разработка веб-сайтов] Кастомные хуки. Part 1
- [Java, Oracle, Программирование, Промышленное программирование] Бинарные операторы в Java
- [Тестирование IT-систем, Программирование, Виртуализация, TDD] Язык тестовых сценариев Testo Lang: простая автоматизация сложных тестов
- [Программирование микроконтроллеров] STM32F3xx + FreeRTOS. Modbus RTU с аппаратным RS485 и CRC без таймеров и семафоров
- [Разработка веб-сайтов, JavaScript, Программирование, VueJS] Создание блога с помощью Nuxt Content(часть первая) (перевод)
- [C++, Алгоритмы, Математика] Кривые Безье. Немного о пересечениях и как можно проще
- Выпуск Redo Rescue 2.0.6, дистрибутива для резервного копирования и восстановления
Теги для поиска: #_programmirovanie (Программирование), #_algoritmy (Алгоритмы), #_kompiljatory (Компиляторы), #_sintaksicheskij_analiz (синтаксический анализ), #_ll, #_parsing (парсинг), #_programmirovanie (
Программирование
), #_algoritmy (
Алгоритмы
), #_kompiljatory (
Компиляторы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Май 09:02
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
|
В некоторых генераторах нисходящего(LL) синтаксического анализа с увеличением объема текста исходного кода время парсинга увеличивается в более чем арифметической прогрессии. Идея состоит в том, чтобы ввести в самом парсере понятие препарсинга — разбиение текста исходной программы на блоки для отдельного парсинга. Тексты программ имеют блочную структуру. к примеру 1 уровень — namespace 2 уровень — классы 3 уровень — методы и свойства и т.д. Для Си-подобных языков блоки это просто {} В языке же Clipper, например, 1 уровень — процедуры/функции/методы, классы, директивы правило начала процедуры/функции: funcProc : funScope? (FUNCTION | PROCEDURE) identName ('(' params? ')')? crlfStmnt ; funScope : STATIC | INIT | EXIT ; Окончанием процедуры/функции может быть RETURN ( expression )? crlfStmnt но RETURN может и отсутствовать, тогда окончанием будет EOF или начало блока первого уровня. В генераторе парсеров ANTLR для грамматики можно устанавливать опции. Т.е. мы можем определить options { PreParse=ON; } и после этого для правил указывать атрибуты, например: [PreParseLevel = 1] funcProcSection : funcProcHead statements ; Также некоторые конструкции такие как лямбды/анонимные функции могут быть тоже выделены для отдельного парсинга. Для них можно установить PreParseLevel = 0. Целью синтаксического анализа является построение дерева синтаксического разбора(abstract syntax tree (AST)). В процессе парсинга мы будем получать для каждого блока свое дерево, которое потом можно прицепить к основному дереву. Конечно, кто-то использует парсер-комбинаторы и для него это все понятно и так. Хотелось бы увидеть комментарии о данной концепции. Разумно ли все это? Применялось ли где? Применяли ли вы в своей работе? Стоит ли выносить это на обсуждение в англоязычном сообществе? With best regards =========== Источник: habr.com =========== Похожие новости:
Программирование ), #_algoritmy ( Алгоритмы ), #_kompiljatory ( Компиляторы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Май 09:02
Часовой пояс: UTC + 5