Мужики! Научите уму-разуму, плиз!
Занимаюсь похожим с вами делом — пишу IDE для MSIL (пока никуда не выложена). С помощью простой PEG-библиотечки генерю AST (уже есть грамматика почти для всего, кроме ОпКодов).
Есть редактор (FastColoredTextBox), где я буду жонглировать стилями. И вот в этом месте непонятно, куда впрягать лошадь! Вариант:
1. "Лошадь впереди телеги": Сразу засунуть весь текст в редактор, а потом оббежать всё AST (где ещё нужно сохранить позицию в тексте!) и применять стили там, где нужно.
2. "Лошадь позади телеги": брать AST и тупо восстанавливать текст, попутно применяя стили.
Влад говорил, что у вас ДВА дерева (как бы для редактора и компилятора). Теоретически, понимаю зачем, но практически — фик знает... Мне кажется, можно обойтись тем, что хранить "редакторскую" часть вместе с компилляционной (по кр. мере я не рассчитываю компилять мегабайтные простыни). В любом случае, интересно, каким способом вы раскрашиваете код?
Ну и если совсем не ноу-хау, что делать при изменении в редакторе? Вы что-то говорили про "высокоуровневую" структуру кода (типа уровня класса/деклараций), но если даже всунуть простую '{' в код, весь парсинг летит к чертям. Допускаю, что Nitra куда мощнее в плане распознавания, но это не избавляет от несуразности кода, который и человек-то может не понять! В общем, у меня при изменениях только одна идея — трясти надо надо перекомпилять. Тем более, что "вклеенный" код может быть весьма большим и декларативно значимым (пару пропертей ввели, например!).
Можно особо не расписывать, только идею киньте. Если не жалко.
Заранее спасибо!
Здравствуйте, Kolesiki, Вы писали:
K>1. "Лошадь впереди телеги": Сразу засунуть весь текст в редактор, а потом оббежать всё AST (где ещё нужно сохранить позицию в тексте!) и применять стили там, где нужно.
Примерно так и делается, но все сильно сложнее.
K>2. "Лошадь позади телеги": брать AST и тупо восстанавливать текст, попутно применяя стили.
Это совсем неверный путь.
K>Влад говорил, что у вас ДВА дерева (как бы для редактора и компилятора). Теоретически, понимаю зачем, но практически — фик знает... Мне кажется, можно обойтись тем, что хранить "редакторскую" часть вместе с компилляционной (по кр. мере я не рассчитываю компилять мегабайтные простыни). В любом случае, интересно, каким способом вы раскрашиваете код?
Для начала нужно понять какая функциональность требуется.
Если задача — подсветить ключевые слова, то для этого достаточно простенького лексера, который эти слова будет выявлять.
Если хочется полноценную IDE, с подсветкой типов, с автодополнением тех же типов и т.п. Это значительно сложнее и тут нужно знать очень много.
Если стоит вторая задача, а опыта в этой сфере нет, лучше просто взять Нитру и делать на ней. Она пока что не закончена, но скоро в ней появится все что нужно для начальной поддержке языков.
K>Ну и если совсем не ноу-хау, что делать при изменении в редакторе? Вы что-то говорили про "высокоуровневую" структуру кода (типа уровня класса/деклараций), но если даже всунуть простую '{' в код, весь парсинг летит к чертям. Допускаю, что Nitra куда мощнее в плане распознавания, но это не избавляет от несуразности кода, который и человек-то может не понять! В общем, у меня при изменениях только одна идея — трясти надо надо перекомпилять. Тем более, что "вклеенный" код может быть весьма большим и декларативно значимым (пару пропертей ввели, например!).
Начать надо с того, что в проекте может быть более одного файла. IDE должна отслеживать изменения в каждом из них и обновлять соответствующий AST.
K>Можно особо не расписывать, только идею киньте. Если не жалко.
Как раз общей идеи тут будет недостаточно. Нужно понимать принципы построения интеграции. Nitra, создается (в том числе) для того чтобы снять с создателя языка эту нагрузку. Но Nitra пока еще не закончена и не может снять всю нагрузку. Однако упростить жизнь она уже может. Только придется пользоваться нашими рабочими ветками, а не мастером (в нем все уже сильно устарело).
Описание о том как поднять язык на Nitra я оформил отдельной темой
Влад, спасибо за статью! Она даёт скорее общее понятие как это сделано именно через Нитру + переплетение с классикой (разрешение имён, типизация и т.п.). Что не совсем согласуется с моей схемой, так это наличие двух деревьев — PT & AST — у меня всё в одном. Вот это AST — без него совсем никак?
VD>Если хочется полноценную IDE...
Именно.
VD> Это значительно сложнее и тут нужно знать очень много.
Знать что-то из теории или знать что придётся писать? Пока что пишу — ничего особо страшного нет. Даже немного раскрашивается код Затыки пока только архитектурного плана — что и где хранить.
VD>Если стоит вторая задача, а опыта в этой сфере нет, лучше просто взять Нитру
Не вопрос, но тут пугают проблемы переходного этапа у Немерле: Нитра пишется на "старом" Немерле, после чего генерит, видимо, немерловый же код, который придётся использовать из того же Немерле (т.к. с C# не всё идеально стыкуется). Но писать на старом Немерле пока не готов, особенно предвидя "новый" Немерле, созданный при помощи Нитры.
Попутный вопрос по новому Немерле: он уже может быть реализован Нитрой, которая доступна сейчас? Или новую будут писать, только когда сама Нитра будет полностью написана?
И политический момент: почему обязательно превращать всё в "интеграцию" (со студией) ? А если я захочу только парсер? Что если сначала полностью допилить Нитру, а потом уже "улучшать её вылоп" в сторону VS?
Здравствуйте, Kolesiki, Вы писали:
K>Влад, спасибо за статью! Она даёт скорее общее понятие как это сделано именно через Нитру + переплетение с классикой (разрешение имён, типизация и т.п.). Что не совсем согласуется с моей схемой, так это наличие двух деревьев — PT & AST — у меня всё в одном. Вот это AST — без него совсем никак?
В простых случаях можно без AST. Но, в сложных (большие проекты, сложные языки) уже будет проблематично. По AST будут создаваться типы для символов.
К тому же есть еще одна проблема. Мы хотим оставить синтаксис чистым. По этому все вычисления мы вынесли в AST.
K>Знать что-то из теории или знать что придётся писать? Пока что пишу — ничего особо страшного нет. Даже немного раскрашивается код Затыки пока только архитектурного плана — что и где хранить.
Интеграция с IDE в ручную подразумевает много чего. Кроме знаний в области создания компиляторов еще нужно изучить всевозможные API IDE/редакторов. Так же нужно обеспечить приемлемую производительность сбора информации о проекте (символов). Это не сложно если расчет делается на один файл небольшого размера, но очень не просто, если расчет делается на большие проекты. Тут уже нужны стратегия кэширования, отложенные вычисления и много чего еще.
Собственно одна из задач Nitra спрятать все эти знания "под капот". Разработчик создает нужные описания, дает их Nitra, а та генерирует весь необходимый код.
Так как описание декларативно, мы развивая Nitra улучшаем поддержку IDE и качество компиляторов без изменения описания языка.
K>Не вопрос, но тут пугают проблемы переходного этапа у Немерле: Нитра пишется на "старом" Немерле, после чего генерит, видимо, немерловый же код, который придётся использовать из того же Немерле (т.к. с C# не всё идеально стыкуется). Но писать на старом Немерле пока не готов, особенно предвидя "новый" Немерле, созданный при помощи Нитры.
Немерл не так сильно отличается от шарпа, особенно в пределах необходимых для написания встроенного в наши DSL кода и прочего обвязочного кода.
Обычно, для начала, достаточно прочесть эту
статьи. Немерл даже поддерживает использование C#-файлов в проекте, но в них не будет интеллисенса.
K>Попутный вопрос по новому Немерле: он уже может быть реализован Нитрой, которая доступна сейчас? Или новую будут писать, только когда сама Нитра будет полностью написана?
Мы сейчас отрабатываем вопросы связывания и типизации. Связывание будет готово в ближайшее время, а вот типизация еще не очень скоро. Мы будем вести работы над Nemerle 2 параллельно с работой над Nitra, но конечный результат будет еще не скоро (думаю, через годик).
Собственно, поддержка MSIL-а будет полезна и нам. Так что я охотно буду помогать в его реализации. Мы сможем использовать ее для генерации код под дотнет. В наши концепции входит генерация кода переписыванием из более высокоуровневого языка в менее высокоуровневый.
K>И политический момент: почему обязательно превращать всё в "интеграцию" (со студией) ?
Потому что это промышленный стандарт для дотнета и в ней есть весь необходимый функционал. Но ничего не заставляет генерировать код и для других IDE.
K>А если я захочу только парсер?
Никаких проблем. Примеров этого в найтре куча. Просто что бы ты не делал с языком, все равно ты рано или поздно займешся типизацией, а нитра предоставляет весьма высокоуровневые решения для этого. Их так же можно использовать программно.
С Nitra идет тестовая утилита. В ней реализована все что поддерживает Nitra на сегодня и будет реализовано все что будет появляться. Можно считать ее микро IDE.
K>Что если сначала полностью допилить Нитру, а потом уже "улучшать её вылоп" в сторону VS?
Мы развиваем все параллельно. Это часть процесса тестирования.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В общем, у меня при изменениях только одна идея — 
