Здравствуйте, SergeyT., Вы писали:
ST>А чего молчите-то? JetBrains Company Blog — An Introduction to Nitra
ST>Ребята, поздравляю! Так держать!
Очень интересно во что это всё выльется.
Мне кажется перспективы просто нереальные.
Молодцы!!!
Народная мудрось
всем все никому ничего(с).
Re[2]: An Introduction to Nitra
От:
Аноним
Дата:
13.11.13 07:25
Оценка:
Здравствуйте, Tom, Вы писали:
Tom>Молодцы!!!
Молодцы будут после инсталятора и статьи на русском.
Собственно все готово, и инсталлятор, и дока на русском есть. Не выпускаем EAP потому что есть неприятные вылеты при редактировании. Выпустим EAP как только их устраним.
Если кто-то хочет попробовать Nitra уже сейчас, можете стучаться ко мне в скайп или на мыло и я дам инсталлятор. Только придется приготовиться к ассертами и вылетам при редактировании в IDE.
Языковая часть и API устоялись, так что серьезного их изменения уже не будет. Так что бояться что труд, сделанный на дорелизой сборке Nitra, пропадет не стоит. Сам компилятор так же стабилен (при работе на коде не содержащем ошибок).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Молодцы будут после инсталятора и статьи на русском.
И то, и другое уже есть. Ждем только фикса багов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: An Introduction to Nitra
От:
Аноним
Дата:
14.11.13 08:25
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Языковая часть и API устоялись, так что серьезного их изменения уже не будет. Так что бояться что труд, сделанный на дорелизой сборке Nitra, пропадет не стоит. Сам компилятор так же стабилен (при работе на коде не содержащем ошибок).
Значит ли это. что приоритет в выражениях так и останется числовым?
Как решили проблему того что в разных пакетах для одного и того же оператора могут быть указаны разные приоритеты?
Здравствуйте, Аноним, Вы писали:
А>Значит ли это. что приоритет в выражениях так и останется числовым?
Пока — да, но это не трудно будет исправить. В итоге будет динамически расширяемая таблица приоритетов на которую будут ссылаться операторы.
А>Как решили проблему того что в разных пакетах для одного и того же оператора могут быть указаны разные приоритеты?
Если это будет расширение для одного правила, то в рантайме вылезет неоднозначность, так как спарсятся оба варианта. Более того, если будут два расширения с одним приоритетом, то все равно будет неоднозначность.
Если это будут расширения для разных правил, то никаких проблем не возникнет. Так что если хочется сделать свой внедренный язык, то это можно будет сделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Хм... Вроде ж был разговор про любой язык/платформу?
С чего-то нужно начинать. Немерл пока работает только на дотнете. Кросплатформная компиляция — это следующий шаг. Мы проектируем все так, что это будет не сложно делать. Скорее всего мы сделаем гнерацию парсеров на С и их можно будет компилировать для любой платформы. Для Явы так же особых проблем не будет. При основном парсинге объекты почти не нужны. Объекты нужны только при восстановлении. Но и там не трудно будет заменить GC пулом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: An Introduction to Nitra
От:
Аноним
Дата:
14.11.13 14:14
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Хм... Вроде ж был разговор про любой язык/платформу?
VD>С чего-то нужно начинать. Немерл пока работает только на дотнете. Кросплатформная компиляция — это следующий шаг. Мы проектируем все так, что это будет не сложно делать. Скорее всего мы сделаем гнерацию парсеров на С и их можно будет компилировать для любой платформы. Для Явы так же особых проблем не будет. При основном парсинге объекты почти не нужны. Объекты нужны только при восстановлении. Но и там не трудно будет заменить GC пулом.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Хм... Вроде ж был разговор про любой язык/платформу?
VD>С чего-то нужно начинать. Немерл пока работает только на дотнете. Кросплатформная компиляция — это следующий шаг. Мы проектируем все так, что это будет не сложно делать. Скорее всего мы сделаем гнерацию парсеров на С и их можно будет компилировать для любой платформы. Для Явы так же особых проблем не будет. При основном парсинге объекты почти не нужны. Объекты нужны только при восстановлении. Но и там не трудно будет заменить GC пулом.
Ну что ж, буду ждать. Будет интересно сравнить потом.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Будет интересно сравнить потом.
VD>Чего с чем?
Плюсовые встроенные DSL с вашими по возможностям, включая качество сгенеренного нативного кода и удобство использования из основной программы, если это компонент.
Все-таки оптимизатор у плюсового компилятора достаточно мощный, жалко его выбрасывать и ограничиваться только Си.
Плюс, я так понимаю, то, что сгенерено Нитрой, будет в результате доступно в виде отдельной сишной библиотеки, так? Со стандартными сишными проблемами с управлением памятью, передачей параметров только по указателю, отсутствием исключений и прочим...
Не очень понятно, как интерфейситься с теми же плюсами — сишный уровень все-таки очень ограниченнный.
Здравствуйте, jazzer, Вы писали:
J>Плюсовые встроенные DSL с вашими по возможностям, включая качество сгенеренного нативного кода и удобство использования из основной программы, если это компонент.
Ты тут путаешь теплое с мягким. Я даже не говорю о сложности сравнения DSL-ей получающихся в С++ и созданных с помощью Nitra, потому как когда я говорю о генерации С-кода, то я говорю о коде парсера, а не о коде который может породить DSL.
Сейчас у нас схема такая:
1. Nitra.exe или компилятор/интеграция Nemerle парсит файл грамматики и генерирует дотнет-сборку (MSIL) парсера. Делается это средствами метапрограммирования Nemerle (хотя это скрыто от пользователя).
2. Программа на дотнете запускает парсер путем вызова некоторых API-функций.
3. Загруженный на этапе 2 парсер парсит то что ему скормят и выдает некую структуру данных ParseResult. Она на низком уровне описывает результат парсинга.
4. Программа на дотнете передает ParseResult в другие API-функции чтобы получить некоторые сервисы (например, объектный AST или для произведения вычислений).
Так вот мы можем генерировать не дотнет-сборку, а нативную DLL или даже ее исходный код. Это позволит на этапах 2-4 пользоваться не только .Net API, но и любым другим (Java или нативным).
Для каждой поддерживаемой платформы придется создать рантайм, но все рантаймы будут работать с единой структурой данных (ParseResult).
Это возможно, так как ParseResult — это очень низкоуровневая структура. По сути там только два куска динамически занимаемой памяти и эта память может быть занята средствами ОС. Кое какие сложности возникнут с представлением информации получаемой при восстановлении после ошибок, но ее тоже можно представить в виде простых сишных структур, а память для них выделять из пула (который можно будет освободить одним махом).
В наших алгоритмах почти не нужна динамическая память. Именно по этому их будет относительно легко перенести на С.
J>Все-таки оптимизатор у плюсового компилятора достаточно мощный, жалко его выбрасывать и ограничиваться только Си.
В природе нет никакого плюсового компилятора. Их множество. Все известные мне умеют компилировать С. Оптимизации при этом будут те же, за исключением число С++-ных оптимизаций которые на просто не нужны.
С же банально более переносимый язык. Он нужен только чтобы не возиться с генерацией нативного кода. Хотя нам как раз было бы проще генирировать именно его, так основная логика парсера — это упражнения с адресами памяти. Возможно стоит подумать на счет генерации чего-то вроде LLVM-кода. Проблема только в том, что LLVM на Винде не местный житель. Когда я смотрел LLVM его нельзя было даже собрать в 64-битном виде под Виндой. Возможно что-то изменилось с тех пор.
J>Плюс, я так понимаю, то, что сгенерено Нитрой, будет в результате доступно в виде отдельной сишной библиотеки, так?
В принцие, да. Только скорее ее нужно назвать "нативно". С — это только один из вариантов реализации. Но это библиотека содержащая внутри код парсера, а результат компиляции DSL-я. Это нужно отчетливо понимать.
J>Со стандартными сишными проблемами с управлением памятью, передачей параметров только по указателю, отсутствием исключений и прочим...
Проблемы управления память будет нашими проблемами. Мы не предлагаем использовать такие ДЛЛ-и самостоятельно. Они слишком низкоуровенвые для этого. Плюс в них есть не все что нужно. Кроме генерируемой части у парсеров есть и рукописная. Она находится в рантайме. Некоторые вещи просто нельзя будет написать на С, так как они зависят от платформы. Например, материализация AST должна порождать AST в виде объектов целевой платформы, а не структур С. Хотя если использовать наши AST-методы можно обойтись без материализации AST-а для конкретной платформы.
J>Не очень понятно, как интерфейситься с теми же плюсами — сишный уровень все-таки очень ограниченнный.
Для плюсов можно создать рантайм который будет прозрачно представлять данные для С++-программиста. Учитывая совместимость С++ и С это будет даже проще реализовать.
Что касается управления памятью, то парсеры используют столь низкоуровневые структуры данных, что это для них не проблема. Куда большей проблемой является кросплатформная реализация АСТ-методов. Во-первых, они пишутся на некотором языке. А во-вторых, оперируют частями грамматики как объектами и могут использовать такие фишки (которые будут предоставляться Nitra) как квази-цитирование. Конечно можно использовать в них язык целевой платформы, но он будет по определению ограничен своими возможностями. Например, в С++ будет невозможно использовать сопоставление с образцом для распознавания сложных сочетаний конструкций в коде. Ну, и опят же управление памятью начинает играть роль.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
