Здравствуйте, konst, Вы писали:
K>Здравствуйте, Чистяков Влад (VladD2), Вы писали:
K>Очень интересно. Но всё же поутру не очень понял, какие задачи призван решать R#? Совершенно серьёзно хотелось бы пару примеров или как-то попроще что ли объяснили "зачем"...
Вообще то в статье как раз сказано, что позволет делать R#. Так же очень советую поглядеть дискуссию на тему АОП в философии (Статья про АОП
Здравствуйте, Eugals, Вы писали:
E>Здравствуйте, AndrewVK, Вы писали:
E>Пользовался. Я именно про EBNF и говорю. Вот захотите вы добавить в язык какое-нибудь свой оператор (или даже просто ключевое слово) и придется перечитывать стандарт C#, на предмет того нельзя ли случайно такую же лексему получить комбинацией стандартных. А если попытаться добавить туда не просто оператор, а целую новую конструкцию (что-нибуть вроде "for <i> in <list> reverse" — наобум сказал), то вообще кирдык, это я и назвал "плотностью" синтаксиса
Ты уж извени, но я это называю рассуждения без наличия достаточных знаний.
Да еще и плохое восприятие информации.
Тебе уже сказали, что построение парсера ведется автоматизированным образом, и любое несоотвествие будет выявленно автоматически. Плюс будет куча тестов (банально скормим парсеру исходники Хоума, Моно, SSCLI и т.п.
Далее тебе сказали, что изменения синтаксиса не планируется. Так что конфликтов не может быть по определению. А уж если пойдем на такой радикальный шаг, то сто раз все проверим и продумаем.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
> ВВ>Ну знаешь живут же как-то расширения стандартов других языков. Можно все "нестандартные" ключевые слова начинать с двойного подчеркивания, напр. "__gc" > > Напомню, что пока нами не введено ни одного нового ключевого слова. И не планируется. В это восбтвенно и суть.
Здравствуйте, VladD2, Вы писали:
ВВ>>А где его можно взять? А то я как лох на каком-то долбаном 1.1 пишу VD>Это версия спецификации. Просто ее видимо поправли. В общем, сейчас на МС лежит именно 1.2.
1. Тянет за собой Яву и Ява-машиной.
2. Много ошибок и недоработок.
3. Плохое качество кода (его исходников).
4. Отсуствие полноценной граматики для шарпа (то что идет с ним долеко от идеала).
5. (тут я могу ошибаться) Он вроде как GNU-тый. А с GNU связываться не охота.
В общем, по большему счету все сводится к плохой модифицируемости.
Да и вроде как Коко очень даже ничего. Простой, удобный, легко модифицируемый. Очень не маловажно, что он сам создан на самом себе же. Это резко упрощает модификацию.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>1. Тянет за собой Яву и Ява-машиной. VD>2. Много ошибок и недоработок. VD>3. Плохое качество кода (его исходников). VD>4. Отсуствие полноценной граматики для шарпа (то что идет с ним долеко от идеала). VD>5. (тут я могу ошибаться) Он вроде как GNU-тый. А с GNU связываться не охота.
6. Тащит с собой рантайм.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, MaxMP, Вы писали:
MMP>>Можно вопрос: а чем вас не устроил ANTLR?
VD>1. Тянет за собой Яву и Ява-машиной.
Только на этапе компиляции граматики. К тому же anltr конвертиться в .net вариант соответствующей утилитой, т.к. java 1.1.4 совметим.
VD>2. Много ошибок и недоработок. VD>3. Плохое качество кода (его исходников).
Так скажем, production ready
VD>4. Отсуствие полноценной граматики для шарпа (то что идет с ним долеко от идеала).
По времени разработки языкового анализатора: лексический анализ — это 5%, синтаксический — 15%, семантический — 80%.
VD>5. (тут я могу ошибаться) Он вроде как GNU-тый. А с GNU связываться не охота.
Apache лицензия.
Плюсы antlr:
1. на выходе лескера-парсера имеем AST.
2. мощный язык грамматик.
3. инфраструктура AST-парсеров, резко упрощающая написание source-to-source конвертеров, семантических анализаторов и обладающих дополнительныо валидирующей граматику функциональностью.
4. поддержка hidden tokens aka comments, whitespaces etc. — полезно для форматеров исходного кода и подобного.
Runtime как таковой в реальных продуктах не применяется — для повышения производительности эти 5-6 необходимых классов переписываются и включаются в продукт.
Здравствуйте, MaxMP, Вы писали:
MMP>Только на этапе компиляции граматики. К тому же anltr конвертиться в .net вариант соответствующей утилитой, т.к. java 1.1.4 совметим.
Ну, и зачем нам этот трах?
MMP>По времени разработки языкового анализатора: лексический анализ — это 5%, синтаксический — 15%, семантический — 80%.
На этот счет есть и другие точки зрения. В любом, случае усложнять себе работу как-то не охота.
VD>>5. (тут я могу ошибаться) Он вроде как GNU-тый. А с GNU связываться не охота. MMP>Apache лицензия.
Ну, вот, а Кока фир.
MMP>1. на выходе лескера-парсера имеем AST.
Который нужно описывать в своеобразном синтаксисе. Да и получается то что получается, а не то что хочется.
MMP>2. мощный язык грамматик.
В коко придумана одна уловка позволяющая решать все проблемы. Язык получается проще но не менее мощным.
MMP>3. инфраструктура AST-парсеров, резко упрощающая написание source-to-source конвертеров, семантических анализаторов и обладающих дополнительныо валидирующей граматику функциональностью.
Так в чем эти приемущетсва?
MMP>4. поддержка hidden tokens aka comments, whitespaces etc. — полезно для форматеров исходного кода и подобного.
Все это прекрасно реализуется и в Коке.
MMP>Runtime как таковой в реальных продуктах не применяется — для повышения производительности эти 5-6 необходимых классов переписываются и включаются в продукт.
Зачем мне что-то переписывать?
Кайф Коки в его простоте и легкости расширения. Он сам создан на самом себе. Это резко упрощает его совершенствование.
Так же у Коки очень хорошо продумана отладка и диагностика.
PS
Я долго протрахался с изучением ANTLR-а, но так до конца и не проникся им. А с Кокой мне хватило двух дней.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MaxMP, Вы писали:
VD>>1. Тянет за собой Яву и Ява-машиной. MMP>Только на этапе компиляции граматики. К тому же anltr конвертиться в .net вариант соответствующей утилитой, т.к. java 1.1.4 совметим.
Ты пробовал?
VD>>3. Плохое качество кода (его исходников). MMP>Так скажем, production ready
Неа. В последней версии есть например глюк, приводящий к неработоспособности лексера с case-insensitive языками. Есть еще куча мелких и не очень глюков и недоделок. Плюс отвратительный стиль — публичные переменные, часть публичных методов в кемэл стиле, часть в паскале. Джавовские get/set практически нигде не преобразованы в свойства. Ну и в доверщение ко всему очень медленный (хотя и юникодный) лексер.
MMP>По времени разработки языкового анализатора: лексический анализ — это 5%, синтаксический — 15%, семантический — 80%.
А нам семантический на первом этапе в полном объеме и не нужен.
MMP>2. мощный язык грамматик.
Это не плюс, это пофигу, поскольку возможностей модифицированного Сосо для описания шарпа хватает, а больше и не нужно.
MMP>3. инфраструктура AST-парсеров, резко упрощающая написание source-to-source конвертеров, семантических анализаторов и обладающих дополнительныо валидирующей граматику функциональностью.
Это скорее минус, поскольку, как уже говорилось, качество кода весьма низкое, а в отличие от кода без специального рантайма не обойтись.
MMP>Runtime как таковой в реальных продуктах не применяется — для повышения производительности эти 5-6 необходимых классов переписываются и включаются в продукт.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, MaxMP, Вы писали:
VD>>>1. Тянет за собой Яву и Ява-машиной. MMP>>Только на этапе компиляции граматики. К тому же anltr конвертиться в .net вариант соответствующей утилитой, т.к. java 1.1.4 совметим.
AVK>Ты пробовал?
Конечно
AVK>Неа. В последней версии есть например глюк, приводящий к неработоспособности лексера с case-insensitive языками. Есть еще куча мелких и не очень глюков и недоделок. Плюс отвратительный стиль — публичные переменные, часть публичных методов в кемэл стиле, часть в паскале. Джавовские get/set практически нигде не преобразованы в свойства. Ну и в доверщение ко всему очень медленный (хотя и юникодный) лексер.
Согласен, многое пришлось переписать, но оно того стоило
MMP>>По времени разработки языкового анализатора: лексический анализ — это 5%, синтаксический — 15%, семантический — 80%.
AVK>А нам семантический на первом этапе в полном объеме и не нужен.
AVK> Ну и в доверщение ко всему очень медленный (хотя и юникодный) лексер.
Сейчас потестил coco — сгенеренный им лексер в два раза медленее сгенеренного antlr'ом (coco scanner — построен из cs.ATG ~ 71100 строк в секунду, antlr scanner ~ 134400 строк в секунду, протестировано файлов: 993, 195548 линий, 5865kb).
И это при том, что все методы в coco лексере статические (непорядок, а antlr работает с входным буфером через интерфейс, + мой лексер делает дополнительный анализ hidden токенов
А то я как лох на каком-то долбаном 1.1 пишу 
