Здравствуйте, Ziaw, Вы писали:
Z>В том то и дело, как только мы начнем потреблять метапрограммирование, оно моментально уйдет за пределы минимальной области, через год будет куча интересных библиотек, модифицирующих код разными способами, а через три оно станет привычным инструментом архитектора дотнетчика.
Для aop — это безусловно так. Для макросов, которые расширяют синтаксис и/или требуют реврайта вызывающего кода — чойто я сомневаюсь.
С аор всё просто, с расширением языка сложно.
Во-первых, оно заразно — проникает в вызывающий код, примерно как с async-await — или не использовать, или использовать везде.
Во вторых, макросы видны по всему коду. Снова кривая аналогия, но это всё равно, что навешивать extension-метод на object — и не совсем очевидно, и контроль за распространением никакой. В принципе это можно решить явным включением макросов ч/з тот же юзинг, но тут лучше послушать немерлистов — у них опыт борьбы с такими вещами точно был.
В третьих, большинство попыток расширений языка из тех что я видел были вызваны
NIH, а не реальной необходимостью. Почти всегда то же самое можно было решить изучением языка или исправлением косяков в дизайне.
Ну не умеют люди дизайнить даже api как правило, что уж тут о языке говорить
Макросы с их лёгкостью добавления тут выглядят слишком большой пушкой.
Z>Расширение синтаксиса я пытаюсь оставить за скобками, рассматривая пока только то, что в Nemerle называется атрибутные макросы. Именно их я и вангую ко второй или третьей итерации рослина.
Тогда да, согласен целиком и полностью. Но это всё-таки полумеры получаются. Делаем кучу усилий для поддержки квазицитирования и изобретаем синтаксис для макросов, а на выходе получаем то, что наворачивается прям поверх текущего рослина без особых доработок.
Z>Живой редактор nemerle вполне умеет применять макросы (даже синтаксические) в реалтайме. Это не проблема. Про вирусные макросы не понял, можно пример?
Ну так это бонус в сторону N. В январе
в обсуждении один из доводов против макросов везде был такой:
But if generated parts are themselves the result of language syntax — e.g. attributes in source code, then things quickly get messy from a tooling perspective. A keystroke in file A may cause different code to be generated into file B by some custom program, which in turn may change the meaning of A. Not a feedback loop we're eager to have to handle in real time at 20 ms keystroke speed!
Выглядит конечно как натягивание на ровном месте, но без дополнительной информации я склонен доверять разработчикам рослина. У них опыт побольше будет.
Про "вирусные" макросы — например, использование в public api аналога std::list. Но такие вещи легко можно отсечь запретом использования макросов в качестве c++ templates. А вот пример с самописными await для самописных тасков посложнее будет. В общем, как только метапрограммирование опускается до отдельных инструкций или вылазит за пределы сборки — начинаются проблемы.
S>>По-моему нет. Немерль вместе с нитрой сейчас всё больше напоминает эдакий всемогутор для генерации dsl. Т.е. в принципе возможно всё, ошибся в дизайне — твой косяк.
Z>Нитра это не немерль, а отдельный инструмент, который предназначен для создания ЯП. К немерлю она имеет отношение как идейный потомок и как средство для будущего переписывания компилятора (ну и то, что она пишется на смеси немерла с собой).
Угу, я про N2 и говорил, нитра кажется будет в нём из коробки. Интересно, что у них в итоге получится.
Z>Сам же по себе немерль — такой же ЯП общего назначения как C# и F#. Я это говорю не для агитации за него (у него есть и серьезные недостатки), а для того, чтобы добавить понимания, никакого всемогутора нет.
Да ладно. Возможность дёшево написать произвольный dsl и получить на выходе аналог roslyn ast здорово меняет картину. Навскидку — свои форматы скриптов, формулы аля excel, нормальный синтаксис для кучи xaml-подобных языков, биз-скрипты, аналог specflow и тд и тп.
В шарпе это очень вряд ли появится.
