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

EC>Vlad2,

VladD2, если можно.

EC> ты тут очень увлекательно рассказывал о Nemerle (говорю без всякой иронии),
какие преимущества ты бы получил разрабатывая R# на Nemerle?

Имея Nemerle нет смысла заниматься R#-ом. Так что если бы я встретил такой проект в то время, то просто не стал бы заниматься R#-ом.

Дело в том, что R# — это попытка добавить в близкий к идеальном императивный яызык средства метапрограммирования. Макросы Nemerle — это уже готовая система метапрограммирования. Причем она более законченная и целостная.

Так что на сегодня R# имеет только одно приемущество над Nemerle — полноую обратную совместимость с C# 2.0 (а в будующем, думаю, и 3.0).

В общем-то идеи Nemerle можно 1 в 1 переносить в R#. Та же система квази-цитирования — это то, что я постоянно искал. В купе с идеей метаатрибутов (до которой я дошел еще не зная о Nemerle) получается полноценное и очень удобное решение практически всех вопросов метапрограммирования.

EC>Та же самая функциональность могла бы быть достигнута меньшим объёмом кода?

Еще раз. Скорее всего R#-а бы просто небыло бы.

Лучше описать разницу в подходах, чем думать о том, как R# выглядел бы на Nemerle.

Итак, в системе метапрограммирования нужны три вещи:
1. Средства порождения нового кода. Таким средством в Nemerle является квази-цитирование. В R# приходилось возиться с AST, что приводило к довольно сложному и трудно изменяемому коду. С подачи Вольфхаунда я ввел возможноть помечать код и получать помеченные куски AST относительно простым образом, но все же это намного сложнее чем использование квази-цитирования.
2. Средства привязки к имеющемуся коду. Поясню... Метакод в системах типа R# и Nemerle не может жить сам по себе. Он должен или по модели генерировать конечный код, или модифицировать имеющийся код. Во втором случае нужна некая привязка к коду явлющемуся моделью (т.е. коду который нужно изменить с помощью метапрограммы). Я додумался до очевидной идеии использования атрибутов C#, но долго мучался, и так и не пришел к тому как удобнее всего привязывать метапрограммы к коду методов. Я думал, о интерпретации вызовов функций как о макросах, но это не стыковалось с идеей использования атрибутов. Я даже думал о том, чтобы ввести атрибуты для кода методов. Но это привело бы к несовместимости с C#. А этого я очень нехотел. В Nemerle поступили просто. Они ввели метаатрибуты и макросы в стиле функций. Это решило все проблемы.
3. Средство поиска по AST. В R# было использовано довольно красивое рещение которое в общем-то даже в чем-то более мощьное чем то, что используется в Nemerle. Таким рещением стало использование XPath. Мы реализовали движок XPath-запросов над AST и таким образом получили возможность осуществлять сложнейший поиск кусков AST подлежащих анализу или модификации. В Nemerle для этих же целей используется сопоставление с образцом (pattrn matching). Учитывая, то, что в качестве образца можно применять квази-цитирование, и то, что в оразце можно задавать "активные части", т.е. переменные — это явилось очень хорошим решением проблемы. Хотя XPath более гибок как язык запросов, но он является, то что Nemerle-овцы называют "строковым DSL-ем", и плохо интегрируется с основным языком (C#-ом). Отсюда периодически возникает необходимость довольно некулюжих приведений типов и невозможность котроля типов во время компиляции. Кроме того в XPath нет средств модификации данных, и код которому требуется менять AST выглядит довольно громоздко.
Сопоставление с образцом не имеет этих проблем, хотя и хуже выглядит в качестве средства поиска по AST (поиск получается более императивным и громоздким). Однако на практике в макросах Nemerle все выглядит довольно гормонично.

EC>Код был бы понятнее?

Квази-цитирование, гигиеничность, сопоставление с образцом точно позволили бы сделать код короче и понятнее. Но все эти средства в общем-то можно встроить в R#.

EC>Код был бы надёжнее (менее подвержен ошибкам)?

Более короткий и более понятный код всегда более надежен.

EC>Как бы изменились требования к памяти?

Скорее всего никак. Отличия в общем-то в диеях. Рантайм почти один и тот же. Ну, разве что Nemerle подталкивает к использованию функционального стиля который из-за недоделанности компилятора и некоторых особенностей нотнета может оказаться чуть менее эффективным, но в целом тут пожалуй разницы не будет.

EC>Изменились ли бы скростные характеристики кода?

Они зависят от степени оптимизации. В R# и так оптимизаций было сделано очень не много. В основном алгоритмические. Так движок XPath-запросов был переписан с использованием генерации кода на основе иформации о типах, а потом и с использованием самого R#-а. Это дало резкое увеличение работы XPath-движка. Однако XPath-движек можно было бы оптимизировать и сильнее. Идеи в этой области были. Но из-за объема работа пока что они не реализованы. В принципе Nemerle позволил бы реализовать движок запросво проще и качественнее. Но и сам R# будучи доделанным повзолил бы это сделать.

EC>Можно было бы уложиться в меньшие сроки разработки?

Откровенно говоря сроки скорее зависят от наличия свободного времени и желания.
Учитывая, что время ресурс дорогой имея Nemerle просто небыло бы смысла ваять R#.


ЗЫ

Попробую объяснить почему я вообще занялся R#-ом.

Когда-то моим любимым языком был С++. Я перепробовал много чего, но из виденного мной он пожалуй был самым гибким и добным. Однако почти с самого начала я видел массу недостатков в нем. Глядя на Васик и Дельфи я понимал, что языку очень нехватает таких свойств как компонентности и типобезопасности (причем второе я скорее чувствовал чем понимал осознанно). В своих разработках мы даже применяли связку Васика и С++. На первом клепались контролы и бизнес-логика, а на С++ более системные библиотеки.

Когда появился C# я вдруг обнаружил, что этот язык намного совершенее С++ во многих обаластях. Однако кое чего в нем все же нехватало. Это было обобщенное программирование и метапрограммирование. Причем если обобщенное программирование в С++ было действительно на высоте, то метапрограммирование в нем было в ужаснейшом состоянии. Макросы приводили к куче опасных проблем и небыли полноценным языком программирования, а метапрограммирование на шаблонах попросу было реализовано на базе побочных эффектов и имело огромное количество проблем. По сути во времена когда я во всю программировал на С++ этого подхода просто небыло. Ведь метапрограммирование на шаблонах использует возможности котрых почти небыло в VC++ 5-6 которые я использовал.

Так вот обобщенное программирование появилось в C# 2.0, а вопрос с метопрограммированием как раз и был призван решить R#.

R# задумывался как расширение (надстройка) C# привносящее в него средства метапрограммирования. Nemerle же кроме очень логичной системы метапрограммирования привнес еще и средства фунционального программирования. Причем Nemerle позволяет выбирать парадигму более всего подходящую для решения задач. Этот язык реально реализовал лозунги которые только провозглашаются в C# и С++. Причем реализовал замечательно и не в ущерб другим возможностям.

Например, в Nemerle идиально реализуется идеи фикс о которой так любят твердить фанаты С++:
1. Зачем вводить в язык то, что реализуется библиотекой?
2. Язык должен включать только базовые вещи, а весь синтаксический сахар должен реализоваться в виде библиотек.
С++ реально содержит кучу того, что можно было бы реализовать в библиотеках и не предоставляет нужной функциональности.
При этом Nemerle обладает такими же компонентными возможностями как и C#.
И более того, он позволяет писать в функциональном стиле не хуже чем ML или Хаскель.

В общем, Nemerle — это отличная работа! И будет очень жаль если она пройдет мимо мэйнстрима. При должной раскрутке и "техническом оснащении" (поддержке IDE, наличии полноценной помощи, книг и т.п.) он может прочно и на долго занять место лидера среди мэйнстрим языков общего назначения. При этом Васик мог бы занять нишу языка для прикладников и "домохазяек", С/С++ нишу битодробилок, а Nemerle займет нишу котрую сейчас занимают C# и С++, т.е. языка общего назначения для решения нетривиальных задач.

Однако возможно, что Nemerle так и не станет лидером в жолтой майке, тогда его идеи можно будет хотя бы частично реализовать в R# и C#.