Чистота методов в C #, оценка и пользовательский компилятор? - PullRequest
1 голос
/ 05 апреля 2009

Вы когда-нибудь были разочарованы тем, что Visual Studio не переоценивал некоторые выражения часов при пошаговом выполнении кода с помощью отладчика?

У меня есть, а кого-нибудь здесь интересуют чистые методы? Методы без побочных эффектов? В C # есть так много замечательных вещей, которые я люблю, но я не могу писать чистые функции, то есть статические методы без побочных эффектов.

Что, если бы вы собрали свой собственный компилятор C #, где вы могли бы написать что-то вроде этого.

function int func(readonly SomeRefType a, int x, int y) { return /*...*/; }

Выше не только бесплатная функция, увы, я не называю это методом, она гарантированно не имеет побочных эффектов. Здесь можно использовать ключевое слово C # readonly, чтобы указать именно это и предоставить контракт для чистых функций. Такого рода функции всегда можно изменить, не вызывая побочных эффектов. Это позволяет Visual Studio всегда оценивать мои функции в часах, несмотря на ошибочное предположение, что все вызовы методов и пользовательские операторы имеют побочные эффекты. Метод, в котором все параметры копируются по значению, никогда не может иметь побочных эффектов, однако Visual Studio не может распознать это.

Мне нравится C ++ за то, что вы можете делать во время компиляции, и я скучаю по этим вещам в C #, я думаю, что C # немного обескураживает пользователя и в основном не допускает определенной выразительности, причиняя вред программистам. Во многих вещах, которые на самом деле связаны с тем, что вы можете делать во время компиляции, я бы хотел увидеть больше метапрограмм, которые являются программами, выполняемыми компилятором для компиляции вашей исходной программы.

например. Хотя C # имеет логические значения и не допускает такие вещи, как if (var a = obj as MyRefType), он не генерирует код оценки. Я немного покопался и заметил, что C # не может генерировать адекватный IL для условных выражений без ветвей, например x > y ? 1 : 0, есть инструкция IL только для того, что компилятор C # не использует.

Хотели бы вы, или были бы заинтересованы в компиляторе .NET с открытым исходным кодом? Что похоже на C #, но является чем-то совершенно другим, более выразительным, более гибким и совершенно ненормальным с точки зрения того, что вы можете с ним сделать?

Ответы [ 5 ]

3 голосов
/ 05 апреля 2009

Не совсем. Если я хочу разные языковые опции, у меня уже есть:

  • F # для функционального изгиба
  • Boo для помощника DSL с пользовательскими этапами компиляции

Шансы на то, что язык "дизайн за комитетом" (или даже "дизайн будет создан одним любителем языка") в конечном итоге так же хорошо продуман, как C #, весьма малы, ИМО.

Было бы неплохо иметь возможность выразить еще несколько вещей? Совершенно верно.

Достаточно ли удобно иметь сотни тысяч людей, которые понимают один и тот же язык, встроенную интеграцию с Visual Studio от людей, которые действительно его знают, и т. Д.? Абсолютно! * * 1013

Для меня «похоже на C #, но это что-то совершенно другое» звучит как проблема, а не как решение.

1 голос
/ 05 апреля 2009

Реализация языка в наши дни - это намного больше, чем реализация компилятора. Я лично пристрастился к Resharper, и даже более ограниченные формы подсветки синтаксиса, подсказок, автозаполнения и компиляции в редакторе, предлагаемые простым Visual Studio, довольно сложные и полезные. Все эти элементы пользовательского интерфейса также должны быть переопределены.

Хорошим примером в этой области является язык Spec #. Вместо того, чтобы добавлять больше функций в C #, Microsoft вместо этого превратила его в библиотеку, которая предоставляет способ декорирования вашего кода и последующей статической проверки его после обычного этапа компиляции. Таким образом, он «привязан» к любому языку, который вы уже используете.

Возможно, это наиболее практичный способ добавить более сложные проверки в языки .NET.

Также обратите внимание, что хотя языковой компилятор генерирует IL с явно избыточными инструкциями, вы не видите, что делает JIT, когда он генерирует более оптимизированный нативный код.

1 голос
/ 05 апреля 2009

Если вы действительно хотите сочетание чистоты, но вы все еще можете пойти с императивным аспектом ООП, используйте F #. Он от Microsoft и будет производиться и интегрироваться в VS 2010.

Если вы действительно хотите по-настоящему чисто функциональное программирование, в котором вы можете быть уверены, что в ваших программных конструкциях есть чистые функции и четко различаются побочные эффекты, включая IO, исключения, вы можете использовать Haskell.

Для начала вы можете загрузить GHC, компилятор Haskell с открытым исходным кодом от Саймона Пейтона Джонса, исследователя из Microsoft. Вы также можете скачать Visual Haskell, плагин для VS 2005, который функционирует как IDE для Haskell.

Для получения дополнительной информации:

0 голосов
/ 05 апреля 2009

Просто следуйте этому простому соглашению: Если это не пустота, не трогайте параметры.

0 голосов
/ 05 апреля 2009

Зачем беспокоиться о написании другого компилятора? Вы можете достичь хотя бы чего-то из того, что вы здесь описываете, например, написав ткач PostSharp для изменения метода (umm, function) во время компиляции.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...