Здравствуйте, Sinix, Вы писали:

S>Для aop — это безусловно так. Для макросов, которые расширяют синтаксис и/или требуют реврайта вызывающего кода — чойто я сомневаюсь.

Их не код вызывает, как и аспекты, они сбоку кода. Расширение синтаксиса C# дело настолько далекого будущего, что о нем говорить нет смысла.

S>С аор всё просто, с расширением языка сложно.
S>Во-первых, оно заразно — проникает в вызывающий код, примерно как с async-await — или не использовать, или использовать везде.
S>Во вторых, макросы видны по всему коду. Снова кривая аналогия, но это всё равно, что навешивать extension-метод на object — и не совсем очевидно, и контроль за распространением никакой. В принципе это можно решить явным включением макросов ч/з тот же юзинг, но тут лучше послушать немерлистов — у них опыт борьбы с такими вещами точно был.
S>В третьих, большинство попыток расширений языка из тех что я видел были вызваны NIH, а не реальной необходимостью. Почти всегда то же самое можно было решить изучением языка или исправлением косяков в дизайне.
S>Ну не умеют люди дизайнить даже api как правило, что уж тут о языке говорить Макросы с их лёгкостью добавления тут выглядят слишком большой пушкой.

Тем не менее люди относительно успешно дизайнят api и решают свои задачи. Если хочется обсудить именно расширение языка, давай сделаем отдельную ветку. Тема холиварная и задавит весь конструктив в данной ветке.

S>Тогда да, согласен целиком и полностью. Но это всё-таки полумеры получаются. Делаем кучу усилий для поддержки квазицитирования и изобретаем синтаксис для макросов, а на выходе получаем то, что наворачивается прям поверх текущего рослина без особых доработок.

Для атрибутных макросов не надо изобретать никакого синтаксиса. Им достаточно синтаксиса атрибутов. Именно потому, что легко наворачиваются поверх рослина они и появятся в ближайших его версиях.

S>Not a feedback loop we're eager to have to handle in real time at 20 ms keystroke speed!
S>Выглядит конечно как натягивание на ровном месте, но без дополнительной информации я склонен доверять разработчикам рослина. У них опыт побольше будет.

Тут лучше Влад расскажет, afaik, немерле не укладывается в 20мс, делая типизацию проекта в фоне, но и без этого вполне IDE достаточно неплохо реагирует.

S>Про "вирусные" макросы — например, использование в public api аналога std::list. Но такие вещи легко можно отсечь запретом использования макросов в качестве c++ templates. А вот пример с самописными await для самописных тасков посложнее будет. В общем, как только метапрограммирование опускается до отдельных инструкций или вылазит за пределы сборки — начинаются проблемы.

Проблемы есть всегда, от любой фичи.

S>Угу, я про N2 и говорил, нитра кажется будет в нём из коробки. Интересно, что у них в итоге получится.

Нитра отдельный и самодостаточный проект, а до N2 еще слишком далеко, чтобы что-то обсуждать.

S>Да ладно. Возможность дёшево написать произвольный dsl и получить на выходе аналог roslyn ast здорово меняет картину. Навскидку — свои форматы скриптов, формулы аля excel, нормальный синтаксис для кучи xaml-подобных языков, биз-скрипты, аналог specflow и тд и тп.

Да, это все очень и очень круто. Но и без синтаксического расширения nemerle очень неплох. Если взять его приятные фичи, то большое количество фич шарпа появилось в nemerle раньше. Дженерики(?), лямбды, вывод типов (шарповский все еще отдыхает), ET как ранний прототип инструмента работы с AST, ко/контрвариантность. Осталось — интерполяция строк, ?., import static classes(в ближайших планах), туплы, АТД и паттерн матчинг (в планах), метапрограммирование (в зачаточном виде уже есть в рослине), иммутабельные переменные (вроде бы тоже мелькали в планах, но могу ошибаться), все есть выражение (не скоро, пока только в лямбдах, но очень хочется).

Нельзя сказать, что копируются фичи немерла, просто это естественный неспешный ход эволюции, который экспериментальный язык смог проделать гораздо быстрее. Я к тому, что МП неизбежно придет в нашу жизнь, несмотря на кажущуюся сложность. Оно не сложнее ООП или ФП и не является им альтернативой, а лишь дополняет их, как ООП и ФП органично дополняют друг друга (хотя можно обходиться чем-то одним).

S>В шарпе это очень вряд ли появится.

Согласен, в обозримом будущем синтаксис расширять мы не сможем. Но лет через 10 картина может измениться.