Как упоминалось в этом форуме, вы планируете делать генератор парсеров на С (лучше на С++), очень интересует когда приблизительно его можна будет потрогать руками.
Планируете ли делать отдельную компоненту-редактор для DSL (подсветка синтаксиса, подсказки), очень неполохо бы иметь такой для WinFroms, WPF, а в моем случае на JavaScript?
(вполне возможно что платную)
P.S.
Попробовал добавить тебя в скайп, тишина...
P.P.S.
Может посоветуете из своего опыта существующий генеретор парсеров для С/C++, пока смотрю только на boost::spirit
Здравствуйте, Danchik, Вы писали:
D>* Как упоминалось в этом форуме, вы планируете делать генератор парсеров на С (лучше на С++), очень интересует когда приблизительно его можна будет потрогать руками.
Это не первостепенная задача. Сейчас в планах выпуск EAP (Early Access Program). По сему мы фиксим баги и переводим документацию на английский.
Далее мы хотим разделиться. Часть команды будет заниматься следующим этапом, а часть будет оптимизировать парсер. В частности генерация С-кода как раз одна из рассматриваемых оптимизаций.
Остальная часть команды займется следующим этапом. Он состоит из:
1. Поддержи проектной систем. Это позволит обрабатывать не отдельные файлы, а их группы составляющие вместе проект.
2. Поддержки символов. Это позволит декларативно описывать отображение грамматики на символы. Символ — это единица описания модели языка. Символы (или модель) можно использовать для понимания сути программы и дальнейшей обработки. В процессе реализации этого и предыдущего пункта к базовым IDE-сервисам, доступным сегодня: подсветка синтаксиса, сообщения об ошибках парсинга, фолдинг кода добавятся такие расширенные возможности как подсветка символов и ссылок на них (на подобии подсветки типов в VS), переход к определению символа по ссылкам на них, поиск ссылок на символы, рефакторинг переименования, всплывающие подсказки. Все это будет доступно в рамках проекта и солюшена.
3. Поддержки квази-цитирования. Это нужно для упрощения генерации кода на языке описанном на Nitra.
D>* Планируете ли делать отдельную компоненту-редактор для DSL (подсветка синтаксиса, подсказки), очень неполохо бы иметь такой для WinFroms, WPF, а в моем случае на JavaScript?
Мы это не планировали, но это будет не сложно сделать. У нас есть графическая утилита Nitra.Visualizer предназначенная для тестирования грамматик. В ней уже есть поддержка имеющихся сервисов. Можно реализовать компонент, а утилиту переписать на его основе. Учтем это в планах.
D>Попробовал добавить тебя в скайп, тишина...
Запросов не было. Мой скайп vc.rsdn.ru
D>Может посоветуете из своего опыта существующий генеретор парсеров для С/C++, пока смотрю только на boost::spirit
Когда я смотрел буст (а было это несколько лет назад) он был мало пригоден для разбора серьезных языков, но удобен для мелких языков и форматов которые нужно распасить в приложении. Если стоит задача пасить настоящий язык программирования, то лучше взять какой-нибудь ANTLR (у него есть бэкэнд генерирующий парсеры на С++, хотя сам он работает на Яве). Ну, или классический Bison. Хотя ANTLR будет по мощнее. Бизон поддерживает GLR, но сам GLR тормаз. Плюс с ним есть ряд проблем (то же восстановление после обнаружения ошибок скорее всего не реализовано). А базовый алгоритм LRAR слишком примитивен и требует много приседаний для того чтобы натянут на него грамматику современного языка.
Мы будем поддерживать генерацию в С, в лучшем случае через пол года. Плюс для использования из С++ придется написать не мало оберточного кода. Так что первый вариант будет хотя и "написан" (сгенерирован) на Си, но запускаться он будет из под дотнета (как компонент).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Danchik, Вы писали:
D>>* Планируете ли делать отдельную компоненту-редактор для DSL (подсветка синтаксиса, подсказки), очень неполохо бы иметь такой для WinFroms, WPF, а в моем случае на JavaScript?
VD>Мы это не планировали, но это будет не сложно сделать. У нас есть графическая утилита Nitra.Visualizer предназначенная для тестирования грамматик. В ней уже есть поддержка имеющихся сервисов. Можно реализовать компонент, а утилиту переписать на его основе. Учтем это в планах.
Это очень заманчивая вещь, язык будет интерпретируемым, и если бы я в браузер встроил его вменяемое редактирование, ну просто песня
D>>Попробовал добавить тебя в скайп, тишина...
VD>Запросов не было. Мой скайп vc.rsdn.ru
Получилось
D>>Может посоветуете из своего опыта существующий генеретор парсеров для С/C++, пока смотрю только на boost::spirit
VD>Когда я смотрел буст (а было это несколько лет назад) он был мало пригоден для разбора серьезных языков, но удобен для мелких языков и форматов которые нужно распасить в приложении. Если стоит задача пасить настоящий язык программирования, то лучше взять какой-нибудь ANTLR (у него есть бэкэнд генерирующий парсеры на С++, хотя сам он работает на Яве). Ну, или классический Bison. Хотя ANTLR будет по мощнее. Бизон поддерживает GLR, но сам GLR тормаз. Плюс с ним есть ряд проблем (то же восстановление после обнаружения ошибок скорее всего не реализовано). А базовый алгоритм LRAR слишком примитивен и требует много приседаний для того чтобы натянут на него грамматику современного языка.
VD>Мы будем поддерживать генерацию в С, в лучшем случае через пол года. Плюс для использования из С++ придется написать не мало оберточного кода. Так что первый вариант будет хотя и "написан" (сгенерирован) на Си, но запускаться он будет из под дотнета (как компонент).
