. Так вот, не могли бы сведущие в предмете (ComputationExpressions) объяснить таким танкистам, как я, какие задачи решает эта система макросов, для чего она нужна?
. Так вот, не могли бы сведущие в предмете (ComputationExpressions) объяснить таким танкистам, как я, какие задачи решает эта система макросов, для чего она нужна?
Главное ее предназначение — доказательство того, что язык с макросами на которых можно реализовать некоторую фичу мощнее чем язык в который встроили такую фичу.
. Так вот, не могли бы сведущие в предмете (ComputationExpressions) объяснить таким танкистам, как я, какие задачи решает эта система макросов, для чего она нужна?
VD>Главное ее предназначение — доказательство того, что язык с макросами на которых можно реализовать некоторую фичу мощнее чем язык в который встроили такую фичу.
Здравствуйте, hardcase, Вы писали:
H>Интересно, а можно ли ко всей этой кухне прикрутить сохранение (сериализацию) и возобновление состояния?
Не совсем понятно, что ты имеешь ввиду. А вообще, продолжение является монадой. Поэтому если ты можешь решить свою задачу через продолжение, то есть шансы, что можно создать соответствующее вычислительное выражение. Кстати, async из F# построен на основе продолжения, и он умеет передавать свое состояние между потоками, так же как и распространять исключения между ними.
Здравствуйте, hardcase, Вы писали:
H>какие задачи решает эта система макросов, для чего она нужна?
Я бы их использовал уже за то, что она умеет enumerable comprehension. Когда легко и непринужденно можно создавать объекты типа IEnumerable[_] в любом месте программы. Генераторы последовательности. В F# это зовется sequence comprehension. Ключевое слово seq. Здесь формат другой: comp enumerable {...}.
Кстати, работает быстрее, чем аналогичная вещь на F# Вообще, еnumerable comprehension создает ленивую последовательность, которая вычисляется только по требованию. Иногда незаменимая вещь.
Вот, более полезный пример. Лениво возвращает список всех файлов, включая вложенные, из заданного каталога.
let rec getAllFiles pattern folder =
seq { for x in Directory.GetDirectories folder do yield! getAllFiles pattern x
for x in Directory.GetFiles(folder, pattern) do yield x }
let rec getAllFiles pattern folder =
seq
{
for x in Directory.GetDirectories folder do
yield! getAllFiles pattern x
for x in Directory.GetFiles(folder, pattern) do
yield x
}
Итого: Разница в двух фигурных скобках и коротком алиасе который без труда можно добавить и в немерловый вариант.
Так делать нельзя. Теряется смысл в Delay. Потом, я написал отдельный DelayedEnumerable[T] : IEnumerable[T]. Через него будет эффективнее.
WH>Вот так гораздо лучше: WH>
На мой взгляд разницы большой нет. Но соглашусь, что так проще понять.
WH>Зачем нужно два void'а? WH>
WH> public sealed class ComputationVoid
WH> {
WH> public static Value : ComputationVoid = ComputationVoid ()
WH> }
WH> public variant FakeVoid
WH> {
WH> | FakeVoid
WH> }
WH>
Это вопрос остается открытым. Собирался оставить один
WH>А еще я вернул ComputationExpressions.sln который ты зачемто удалил. WH>Ибо многим работать в IDE банально удобнее. WH>[/list]
Просто у меня нет полноценной студии. Есть VS C# Express 2005 и VS 2008 Shell. Не знаю, можно ли к ним прикрутить интеграцию?
Здравствуйте, dsorokin, Вы писали:
D>Так делать нельзя. Теряется смысл в Delay. Потом, я написал отдельный DelayedEnumerable[T] : IEnumerable[T]. Через него будет эффективнее.
А... кажется понял в чем прикол.
D>На мой взгляд разницы большой нет. Но соглашусь, что так проще понять.
Так не только проще понять но еще и эффективнее.
D>Просто у меня нет полноценной студии. Есть VS C# Express 2005 и VS 2008 Shell. Не знаю, можно ли к ним прикрутить интеграцию?
Есть NemerleStudio. http://www.rsdn.ru/forum/prj.nemerle/2878763.1.aspx
Здравствуйте, dsorokin, Вы писали:
D>Просто у меня нет полноценной студии. Есть VS C# Express 2005 и VS 2008 Shell. Не знаю, можно ли к ним прикрутить интеграцию?
К Shell-у можно. Правда я всегда путаю Isolated и Integrated. Еще можно к SharpDevelop (формат проектов теперь идентичен).
Здравствуйте, hardcase, Вы писали:
H>К Shell-у можно. Правда я всегда путаю Isolated и Integrated. Еще можно к SharpDevelop (формат проектов теперь идентичен).
Пожалуй, SharpDevelop стоит снова мне поглядеть. Давно его не видел.
Здравствуйте, dsorokin, Вы писали:
D>Не совсем понятно, что ты имеешь ввиду. А вообще, продолжение является монадой.
Нет не является. Продолжения вещь несомненно более мощьная. Их состояние можено сериализовать или клонировать.
Об это собственно и речь.
Представь себе, что некий ворфлоу заморозили в некоторой точке и это замороженное состояние превратили в поток байтов и записали в файл или поместили в поле БД.
Далее, через несколько дней, достали от туда, восстановили состояние в другой экземпляр и запустили с той же точки.
D>Поэтому если ты можешь решить свою задачу через продолжение, то есть шансы, что можно создать соответствующее вычислительное выражение. Кстати, async из F# построен на основе продолжения, и он умеет передавать свое состояние между потоками, так же как и распространять исключения между ними.
Как я понимаю там есть только CSP который, лично я, не понимаю как можно сериализовать или клонировать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dsorokin, Вы писали:
D>Я бы их использовал уже за то, что она умеет enumerable comprehension. Когда легко и непринужденно можно создавать объекты типа IEnumerable[_] в любом месте программы. Генераторы последовательности. В F# это зовется sequence comprehension. Ключевое слово seq. Здесь формат другой: comp enumerable {...}.
Это конечно полезно, для решения тех же задач есть и другие средства (макра лист компрешхншон, yield-методы, Linq, стандартные ФВП). Так что это скорее вопрос предпочтений и привычек.
Но, на мой взгляд, несомненно одно — чем больше возможностей тем лучше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Для сравнения как следует отформатируем:...
Да по-моему как не форматируй, а код идентичен. Количество строк и пробелов ни на что не влияет.
Точнее так чем более компактно записан один и тот же смысловой фрагмент тем сложнее его понять.
Лично для меня код отличается только при условии, что есть значительный синтаксический шум или если он отличается сематнически.
А эти два примера — это близницы браться с поправкой на синтаксис.
ЗЫ
Если уж кому-то охота заняться пенесометрией объемов кода, то наверно стоит применять identation-синтаксис.
Специально для таких любителей пенесометрии в снипетах немерла есть пример raytracer.
Вот список файлов из этого каталога.