Еще пару вопросов:
1) Как дебагать тайпчекер написанный на N2?
2) Как планируется структурировать такие тайпчекеры? Есть ли планы предоставить что-то большее, чем абстрактный фреймворк? Есть ли какие-нибудь кейс стади на эту тему? Меня очень заинтересовала тема генераторов тайпчекеров, поэтому познавательно было бы узнать, чего здесь можно достичь.
RuleName – имя правила. Для него создается вложенный (в модуль) класс. Этот класс наследуется от класса с именем RuleNameBase. Это сделано, так как кроме класса, представляющего дерево разбора N2, также генерирует классы RuleNameError и RuleNameSplice для представления ошибок в коде и для представления квази-цитат.
Непонятно. Так почему же всё таки класс наследуется от RuleNameBase? То ли RuleNameError и RuleNameSplice тоже наследуются от RuleNameBase, то ли просто так карты лягли?
using cp = Expression; // псевдоним для синтаксического модуля CalcParser
Видимо имелось ввиду Expression.
Если при используется отношение подтипа, основанное на наличии неявного применения типов, то информация об этом записывается в конкретизируемую переменную типов. Его можно использовать на стадии трансформации кода для вставки кода преобразующего типы. Можно делать проверки и, например, не допускать использование неявных приведений типов.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, VladD2, Вы писали:
F>
RuleName – имя правила. Для него создается вложенный (в модуль) класс. Этот класс наследуется от класса с именем RuleNameBase. Это сделано, так как кроме класса, представляющего дерево разбора N2, также генерирует классы RuleNameError и RuleNameSplice для представления ошибок в коде и для представления квази-цитат.
F> Непонятно. Так почему же всё таки класс наследуется от RuleNameBase? То ли RuleNameError и RuleNameSplice тоже наследуются от RuleNameBase, то ли просто так карты лягли?
Первое. В прочем, это детали реализации. На сегодня они отличаются. Так что можно это просто игнорировать.
F>
using cp = Expression; // псевдоним для синтаксического модуля CalcParser
F>Видимо имелось ввиду Expression.
Да. Это баг. Я его уже поправил. Но документ пока не обновил.
F>
F>Если при используется отношение подтипа, основанное на наличии неявного применения типов, то информация об этом записывается в конкретизируемую переменную типов. Его можно использовать на стадии трансформации кода для вставки кода преобразующего типы. Можно делать проверки и, например, не допускать использование неявных приведений типов.
Спасибо! Подправил.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да, почитал, половину, наверное ещё мозгом не осознал, со скопами вообще каша образавалась не понял — но всё вместе выглядит очень интересно. Попробовать бы уже поскорее.
Здравствуйте, fddima, Вы писали:
F>Да, почитал, половину, наверное ещё мозгом не осознал, со скопами вообще каша образавалась не понял — но всё вместе выглядит очень интересно. Попробовать бы уже поскорее.
Пока только парсер. Но он крут как вареное яйцо. За что отдельное благодарность WolfHound-у. Пример что я приводил как раз на нем сделан. Только он пока в несколько другом синтаксисе. Поля определяются в атрибуте Ast.
Собственно присоединяйся. Тем самым сократишь сор появления сия чуда.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Пока только парсер. Но он крут как вареное яйцо. За что отдельное благодарность WolfHound-у. Пример что я приводил как раз на нем сделан. Только он пока в несколько другом синтаксисе. Поля определяются в атрибуте Ast. VD>Собственно присоединяйся. Тем самым сократишь сор появления сия чуда.
Да в общем-то даже парсер интересен и без типизации и прочих чудес. Первая половина статьи расказывает как описывать разные не очень сложные вещи с синтаксисом не вырывающим глаза — толковых аналогов (опускаем алгоритм парсера) — не видел — и мне это очень понравилось. А в целом — хотелось бы просто вменяемого тулсета, и у N2 судя по описанию да и вообще разговорам на форуме — есть все шансы таким стать. Да и возможности несравнимые...
Вливаться — не знаю как — задач уйма помимо основной работы. Так что не вижу как я бы смог принести пользу, кроме того с N, всё же не знаком — особо ярых проблем с понимаем N не вызывает, но всё же на нём я ничего не писал. + пока, что та задача для которой бы сгодился DSL — уже выполнена, но тупо через XML. Неудобно. Но переписывать пока что смысла нет — после отладки эта модель более меняться не будет.
Но переделать ради домашнего задания, — для меня лично был бы наилучший практический пример.
Но в будущем я вижу необходимость ещё 1-3 DSL, — хотя как карта ляжет.
Поэтому если уже можно как-то пощупать минимальный функционал N2... было бы интересно.
Здравствуйте, fddima, Вы писали:
F> Да в общем-то даже парсер интересен и без типизации и прочих чудес. Первая половина статьи расказывает как описывать разные не очень сложные вещи с синтаксисом не вырывающим глаза — толковых аналогов (опускаем алгоритм парсера) — не видел — и мне это очень понравилось.
Сейчас синтаксис немного иной. Поля описываются атрибутом Ast перед правилом. А в правиле идут только ссылки на другие правила и т.п. Читается он тоже не плохо. Писать немного не удобно, так как когда полей становится много, то начинаешь путаться. Но скоро мы это дело приведем к синтаксису описанному в статье.
F>А в целом — хотелось бы просто вменяемого тулсета, и у N2 судя по описанию да и вообще разговорам на форуме — есть все шансы таким стать.
N2 задуман как интегрированное решение, но в приципе его можно использовать и по частям. Так генератор парсеров, в конце концов, генерирует банальный набор классов. Класс парсера и классы описывающие АСТ. Если есть желание, то с ними можно работать и вручную (на сегодня только вручную).
F>Да и возможности несравнимые...
Это да. Собственно на то и расчет, чтобы крутые возможности были скрыты за максимально простыми в использовании языками.
F> Вливаться — не знаю как — задач уйма помимо основной работы.
Дык все кто работал над Немерлом, и работают над N2 тоже имеют свои задачи. Если не найдем инвестора, то придется работать над проектом выделяя время отрывая его от других задач.
F>Так что не вижу как я бы смог принести пользу, кроме того с N, всё же не знаком — особо ярых проблем с понимаем N не вызывает, но всё же на нём я ничего не писал.
Все когда-то начинали. Через неделю втягиваешся и не понимаешь как мог программировать на чем то другом.
Я когда первый раз на немерле попрограммировал с месяц, потом ощутил дикую ломку когда обратно за шарп взялся.
F> Но переделать ради домашнего задания, — для меня лично был бы наилучший практический пример.
Тоже дело. В парсере хотя логика и работает, но еще не мало шероховатостей которые нужно выявлять и шлифовать. Так что свежий глаз сам по себе полезен.
F> Но в будущем я вижу необходимость ещё 1-3 DSL, — хотя как карта ляжет.
Тем более.
F> Поэтому если уже можно как-то пощупать минимальный функционал N2... было бы интересно.
Современная версия парсера доступна здесь. Для ее использования нужен свежаший вариант компилятора который лучше собрать из исходников, или, по крайней мере, взять из ночных сборок.
В проекте есть примеры. Изучать возможности нужно по ним. Если есть какие-то вопросы, то можно сюда задавать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, xeno.by, Вы писали:
XB>Еще пару вопросов: XB>1) Как дебагать тайпчекер написанный на N2?
Учитывая, что для вывода типов будет использоваться констрэйн-солвер — это не простой вопрос. Думаю, что мы сможем предоставить логи солвера. Можно сделать режим при котором неудачная унификация будет приводить к запуску отладчика или выводу некоторого отладочного ГУЙя.
XB>2) Как планируется структурировать такие тайпчекеры? Есть ли планы предоставить что-то большее, чем абстрактный фреймворк? Есть ли какие-нибудь кейс стади на эту тему? Меня очень заинтересовала тема генераторов тайпчекеров, поэтому познавательно было бы узнать, чего здесь можно достичь.
Код связанный с проверкой типов будет генерироваться по описанию. Не смотря на расширения и всевозможные выверты в системе типов, в основе все равно будет лежать граф типов и система унификации переменных типов в нем.
По сути, если взглянуть на рукописаный тап-чекер, то это тупой код бегающий по АСТ и связывающий между собой типы разных выражений (унифицирующий переменные предоставляющие эти типы). Если унификация удается, то делаются следующие проверки, если нет, то код пытается выбрать другой путь. По сути есть набор вариантов которые проходят или не проходят. Конечный результат — это такое состояние графа типов где на все типы наложены ограничения и они не противоречат друг другу.
Декларативное описание позволяет задать структур этого алгоритма и сгенерировать эффективный код по нему.
Собственно самая сложная част — это разрешение перегрузок. Здесь очень легко получить экспоненциальный рост переборов. Здесь нужны эвристики. Думаю, что мы предоставим подобные вещи из коробки и дадим людям настраивать мелкие детали.
В общем, это еще открытое поле для исследования. У нас есть прототип в виде рукописного тайпчекера немерла. Но эксперементов в этой области еще придется сделать не мало. Сейчас ясно только, что задача принципиально решаемая. И ясны общие пути ее решения.
Если хочешь, присоединяйся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Это все интересно, но пока только теория, все же хочется многое пощупать, как это работает и как удобно этим пользоваться. В процессе разработки проекта могут возникнуть разные трудности реализации тех идей, которые запланированы, вот лучше ближе к этому как привести все это в реальность. До конечного релиза все может серьезно поменяться, но как теоретическая база сгодиться.
Здравствуйте, VladD2, Вы писали:
VD>В проекте есть примеры. Изучать возможности нужно по ним. Если есть какие-то вопросы, то можно сюда задавать.
Что лучше использовать? https://github.com/rampelstinskin/ParserGenerator или https://github.com/rsdn/ParserGenerator — последний вроде чуток иногда отстаёт.
Примеры... ну понятно, всё что .n2 уже пример. Пока разбираюсь, пробую заюзать — с не привычки идёт туго. Интеграция показывает ерунду всяку. Впрочем... пошел качать ночную сборку.
Project overview нигде не нашел...
Что такое ExternalGrammar — для чего планируется?
N2Parser, N2ParserExtensions — а это для чего?
N2VsExtentions — есть ли там что-то работающее, стоит ли это пробовать?
ЗЫ: Как и говорил, решил потренироваться на "кошках", единственно, что внесу новых плюшек в свой генератор. Поскольку работать с получаемым AST в чистом виде вроде бы как и не очень удобно — хочется преобразовать в своё внутреннее представление. Правильно ли это, и есть ли какие-нибудь хорошо зарекомендовавшие себя техники для этого? Для моей задачи — в 90% будет более-менее тупое перебрасывание из AST в мою модель, ну правда там есть некоторое связывание, и некоторая доля преобразований (когда я генерирую сериализатор — мне проще работать с плоским набором полей, а не иерархией классов и разбираться где declared-only поля, а когда генерирую модели — наоборот, важны декларации).
ЗЗЫ: А можно ли генерировать классы из макросов с xmldoc-комментариями?
Здравствуйте, fddima, Вы писали:
F> Что лучше использовать? https://github.com/rampelstinskin/ParserGenerator или https://github.com/rsdn/ParserGenerator — последний вроде чуток иногда отстаёт.
В данный момент их лучше вообще не использовать.
Ибо данный проект находится в очень не стабильной фазе.
И ломающие изменения случаются регулярно и без предупреждений.
F> Project overview нигде не нашел... F> Что такое ExternalGrammar — для чего планируется? F> N2Parser, N2ParserExtensions — а это для чего? F> N2VsExtentions — есть ли там что-то работающее, стоит ли это пробовать?
Это все тестовые проекты.
F> ЗЫ: Как и говорил, решил потренироваться на "кошках", единственно, что внесу новых плюшек в свой генератор.
В какой свой?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>В данный момент их лучше вообще не использовать. WH>Ибо данный проект находится в очень не стабильной фазе. WH>И ломающие изменения случаются регулярно и без предупреждений.
Ну это не страшно. Резко новые версии можно ж и не брать.
F>> ЗЫ: Как и говорил, решил потренироваться на "кошках", единственно, что внесу новых плюшек в свой генератор. WH>В какой свой?
Я где-то здесь описывал, сейчас не вижу где. Есть генератор моделей и генератор сериализатора/десериализатора со своими особенностями. Исходная модель описана в XML. Вот на этих "кошках" в рамках домашнего задания и инетересно поразбираться.
Основной репозиторий https://github.com/rampelstinskin/ParserGenerator. Но использовать его для чего-то серьезного не стоит. Он будет существенно переделвываться. Причем не только реализация, но и синтаксис.
Если сейчас что-о нужно отпарсить, то используй Nemerle.Peg из поставки.
F> Project overview нигде не нашел...
. Но, сам понимаешь, сейчас большую часть описанного не воспроизвести. Да и изменится все по ходу дела.
F> Что такое ExternalGrammar — для чего планируется?
Детали реализации. На них вообще смотреть не надо. Все еще 100 раз изменится.
F> N2Parser, N2ParserExtensions — а это для чего?
Это зачаток примера изменяемого языка. Грубо говоря описание немерла в зачаточном виде. Там можно наблюдать динамическую загрузку грамматики.
F> N2VsExtentions — есть ли там что-то работающее, стоит ли это пробовать?
Кое как подсвечивает код для описанных языков. В принципе работает. Но это пока очень примитивный прототип. Опять таки со временем изменится очень сильно. Смотреть на него особого смысла нет.
F> ЗЫ: Как и говорил, решил потренироваться на "кошках", единственно, что внесу новых плюшек в свой генератор. Поскольку работать с получаемым AST в чистом виде вроде бы как и не очень удобно — хочется преобразовать в своё внутреннее представление.
Вообще-то работать с получаемым АСТ довольно удобно. Делать какой-то свой самопал точно смысла нет. Но в дальшейшем планируется, что с голым АСТ никто дело иметь не будет. Да и самого АСТ может не быть вовсе.
F>Правильно ли это, и есть ли какие-нибудь хорошо зарекомендовавшие себя техники для этого? Для моей задачи — в 90% будет более-менее тупое перебрасывание из AST в мою модель, ну правда там есть некоторое связывание, и некоторая доля преобразований (когда я генерирую сериализатор — мне проще работать с плоским набором полей, а не иерархией классов и разбираться где declared-only поля, а когда генерирую модели — наоборот, важны декларации).
Ты смотришь на совсем зачаточную стадию. Говорить о каких-то практиках просто невозможно. Единственное что можно гарантировать, что все это очень сильно изменится.
Так что воспринимай это на раннюю демонстрацию будущих возможностей. А не как на продукт с недокументированным АПИ.
F> ЗЗЫ: А можно ли генерировать классы из макросов с xmldoc-комментариями?
В будущем будет можно. Пока что там еще ничего по этому поводу не сделано.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
F>> ЗЫ: Как и говорил, решил потренироваться на "кошках", единственно, что внесу новых плюшек в свой генератор. Поскольку работать с получаемым AST в чистом виде вроде бы как и не очень удобно — хочется преобразовать в своё внутреннее представление. VD>Вообще-то работать с получаемым АСТ довольно удобно. Делать какой-то свой самопал точно смысла нет. Но в дальшейшем планируется, что с голым АСТ никто дело иметь не будет. Да и самого АСТ может не быть вовсе.
"Расширяя" его под свои нужды? (Рассматривая случай пока АСТ есть, конечно же). Вроде как-то делалось, если не изменяет память.
VD>Если сейчас что-о нужно отпарсить, то используй Nemerle.Peg из поставки. VD>Ты смотришь на совсем зачаточную стадию. Говорить о каких-то практиках просто невозможно. Единственное что можно гарантировать, что все это очень сильно изменится. VD>Так что воспринимай это на раннюю демонстрацию будущих возможностей. А не как на продукт с недокументированным АПИ.
Ну как я писал выше — мне оно не горит... Но поковырять не отказался бы. Тем более этот опыт нужен, что бы позже сделать уже нечто нужное. Иначе говоря — стоит ли ждать именно N2, или нет, — вот в чём вопрос. И какими эти тулзы будут...
Какая-то резкая смена позиции, — то всех зазывал, теперь говоришь юзай N.Peg и не парься. Не понимаю.
F>> ЗЗЫ: А можно ли генерировать классы из макросов с xmldoc-комментариями? VD>В будущем будет можно. Пока что там еще ничего по этому поводу не сделано.
Я ещё на примере DbImport увидел, что было бы неплохо иметь возможность в большей мере "подсказать" интеллисенсу / помощь в генерации документации. Но на самом деле и без этого можно обойтись / решить по другому.
Здравствуйте, fddima, Вы писали:
F> Какая-то резкая смена позиции, — то всех зазывал, теперь говоришь юзай N.Peg и не парься. Не понимаю.
Я просто оберегаю тебя от напрасного труда. Если поиграть, то не вопрос. Но если ты что-то серьезное хочешь делать, то стоит немного подождать, так как как раз в ближайшее время предстоят серьезные переделки.
F> Я ещё на примере DbImport увидел, что было бы неплохо иметь возможность в большей мере "подсказать" интеллисенсу / помощь в генерации документации.
Согласен. Надо будет подумать как это дело сделать по удобнее. В Немерле очень этого не хватает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
F>> Какая-то резкая смена позиции, — то всех зазывал, теперь говоришь юзай N.Peg и не парься. Не понимаю. VD>Я просто оберегаю тебя от напрасного труда. Если поиграть, то не вопрос. Но если ты что-то серьезное хочешь делать, то стоит немного подождать, так как как раз в ближайшее время предстоят серьезные переделки.
Понял. Спасибо.
