Ещё один вариант перевода «kind» — «типаж», но лично мне оно не нравится :) «типаж типа» — брр :)
Однако если kinds называть «сортами», то как называть сами sorts, предназначенные для классификации kinds? В языке code.google.com/p/omega/ все уровни выше kind'ов называются «sorts» :)
Некорректное. Монада — это _тип_вычисления_ (Cont<T>, IEnumerable<T> и т.п.) и две функции: возврата тривиального вычисления (return) и композиции вычислений (bind). То есть монада — это тройка из одного типа и двух функции.
А вот newtype Cont r a = Cont { runCont :: (a -> r) -> r } — это _тип_монадического_вычисления_, часть этой тройки. Это нельзя называть самой «монадой».
IEnumerable<T> — это не монада, это опять же тип вычисления внутри монады Linq to Objects, тип монадического вычисления.
То, что вы привели — хаскельное определения record'а, с полем типа ((a -> r) -> r), для получения которого создаётся функция-акцессор ``runCont`` с сигнатурой (Cont r a -> ((a -> r) -> r)).
Исходная фраза такова: «Тогда монаду можно представить в виде такой делегаты». Вы меня извините, но это звучит как полный бред. Не «монаду» можно представить в виде «делегаты», а тип вычисления в монаде Cont можно представить в виде типа делегата .NET.
Этот вопрос и стоит обсудить :)
F# гораздо менее академический и более практичный, чем тот же Haskell, и тот факт, что он вошёл в VisualStudio 2010 наравне с C# и VB.NET уже о чём-то говорит :) К тому же на данный момент F# — единственный выбор, если Вам действительно необходимо разрабатывать в функциональном стиле для платформы .NET.
Личное имхо: если наловчиться на нём хорошо писать, то можно нехило повысить продуктивность и лаконичность кода для решения круга задач, хорошо ложащихся на парадигму.
вроде в jLinq подобное имеется, можно лямбды в стиле C# писать:
.select('x => x * 2')
Оно тупо парсит текст на аргументы и тело, а потом конструирует функцию конструктором Function(args, body). Из минусов — кавычки литералов, потеря подсветки кода и невозможность замкнуться на что-либо…
Если присмотреться к исходникам проекта, то можно обнаружить, что операторы являются энергичными, а не ленивыми как в LINQ. Where сразу бежит по массиву, рожая новый, то есть совсем другой behavior по сравнению LINQ…
Кстати, где-то видел анонимные функции в JS из одного expression в такой вот записи (ну прямо лямбды), вроде даже тестировал и вроде даже где-то работало:
Это проблема?
Что плохого в том, что в язык приобретает черты других парадигм?
Где грань «проблемы», что надо поддерживать C#, чтобы быть не хуже динамических языков? Передача словаря, как параметров — это настолько частая фича в динамических языках, что без неё язык можно считать ущербным?
Реально было бы лучше, если бы язык был чисто объектно-ориентированным?
Однако если kinds называть «сортами», то как называть сами sorts, предназначенные для классификации kinds? В языке code.google.com/p/omega/ все уровни выше kind'ов называются «sorts» :)
Код немного расстраивает пока, раздражает обилие
else:if (...) {throw ... / return
}
else {
...
}
В идеале хотелось бы иметь хоть какие-нибудь настройки форматирования :)
прокрутил листинги кода.
везде монада IO, с do-нотацией и без.
о каком «хаскеле без монад» вообще идёт речь?
просто пипец.
=> Seq.tryFind ((=) y)
Зачем постоянный |> там, где он явно избыточен?
Неужели ``newCars |> List.ofSeq`` понятнее, чем ``List.ofSeq newCars``?
;)
use message = new MailMessage(Body = content, Subject = subj, IsBodyHtml = true)
message.To.Add recepinet
А вот newtype Cont r a = Cont { runCont :: (a -> r) -> r } — это _тип_монадического_вычисления_, часть этой тройки. Это нельзя называть самой «монадой».
IEnumerable<T> — это не монада, это опять же тип вычисления внутри монады Linq to Objects, тип монадического вычисления.
Исходная фраза такова: «Тогда монаду можно представить в виде такой делегаты». Вы меня извините, но это звучит как полный бред. Не «монаду» можно представить в виде «делегаты», а тип вычисления в монаде Cont можно представить в виде типа делегата .NET.
F# гораздо менее академический и более практичный, чем тот же Haskell, и тот факт, что он вошёл в VisualStudio 2010 наравне с C# и VB.NET уже о чём-то говорит :) К тому же на данный момент F# — единственный выбор, если Вам действительно необходимо разрабатывать в функциональном стиле для платформы .NET.
Личное имхо: если наловчиться на нём хорошо писать, то можно нехило повысить продуктивность и лаконичность кода для решения круга задач, хорошо ложащихся на парадигму.
Оно тупо парсит текст на аргументы и тело, а потом конструирует функцию конструктором Function(args, body). Из минусов — кавычки литералов, потеря подсветки кода и невозможность замкнуться на что-либо…
Кстати, где-то видел анонимные функции в JS из одного expression в такой вот записи (ну прямо лямбды), вроде даже тестировал и вроде даже где-то работало:
Если такое существует, то может кто подкинет ссылку, с каких версий, в каких бразуерах и т.п.
Что плохого в том, что в язык приобретает черты других парадигм?
Где грань «проблемы», что надо поддерживать C#, чтобы быть не хуже динамических языков? Передача словаря, как параметров — это настолько частая фича в динамических языках, что без неё язык можно считать ущербным?
Реально было бы лучше, если бы язык был чисто объектно-ориентированным?