Здравствуйте, lomeo, Вы писали:
L>Спасибо, я не знаю C#, к сожалению. L>Если можно расскажи подробнее.
Query comprehension работает при наличии т.н. query pattern, т.е. наличия методов определенной сигнатуры у аргумента (или наличия для него extension методов с аналогичной сигнатурой с учетом this параметра). Минимально необходимый метод один — C<U> Select<U>(Func<T,U> selector). При его наличии будет работать такое:
var res = from x in Arg select x.Foo;
Что эквивалентно:
var res = Arg.Select(x => x.Foo);
Если еще есть метод C<T> Where(Func<T,bool> predicate), то возможно такое:
var res =
from x in Arg
where x.Foo > 5
select x.Foo;
Что эквивалентно:
var res = Arg.Where(x => x.Foo > 5).Select(x => x.Foo);
Ну и т.д. Весь query pattern выглядит так:
class C
{
public C<T> Cast<T>();
}
class C<T>
{
public C<T> Where(Func<T,bool> predicate);
public C<U> Select<U>(Func<T,U> selector);
public C<U> SelectMany<U>(Func<T,C<U>> selector);
public C<V> Join<U,K,V>(C<U> inner, Func<T,K> outerKeySelector,
Func<U,K> innerKeySelector, Func<T,U,V> resultSelector);
public C<V> GroupJoin<U,K,V>(C<U> inner, Func<T,K> outerKeySelector,
Func<U,K> innerKeySelector, Func<T,C<U>,V> resultSelector);
public O<T> OrderBy<K>(Func<T,K> keySelector);
public O<T> OrderByDescending<K>(Func<T,K> keySelector);
public C<G<K,T>> GroupBy<K>(Func<T,K> keySelector);
public C<G<K,E>> GroupBy<K,E>(Func<T,K> keySelector,
Func<T,E> elementSelector);
}
class O<T> : C<T>
{
public O<T> ThenBy<K>(Func<T,K> keySelector);
public O<T> ThenByDescending<K>(Func<T,K> keySelector);
}
class G<K,T> : C<T>
{
public K Key { get; }
}
Сорри, перечитал и усомнился, похоже какая то левая спецификация под руку попала. Вот правильный query pattern:
delegate R Func<T1,R>(T1 arg1);
delegate R Func<T1,T2,R>(T1 arg1, T2 arg2);
class C
{
public C<T> Cast<T>();
}
class C<T> : C
{
public C<T> Where(Func<T,bool> predicate);
public C<U> Select<U>(Func<T,U> selector);
public C<V> SelectMany<U,V>(Func<T,C<U>> selector,
Func<T,U,V> resultSelector);
public C<V> Join<U,K,V>(C<U> inner, Func<T,K> outerKeySelector,
Func<U,K> innerKeySelector, Func<T,U,V> resultSelector);
public C<V> GroupJoin<U,K,V>(C<U> inner, Func<T,K> outerKeySelector,
Func<U,K> innerKeySelector, Func<T,C<U>,V> resultSelector);
public O<T> OrderBy<K>(Func<T,K> keySelector);
public O<T> OrderByDescending<K>(Func<T,K> keySelector);
public C<G<K,T>> GroupBy<K>(Func<T,K> keySelector);
public C<G<K,E>> GroupBy<K,E>(Func<T,K> keySelector,
Func<T,E> elementSelector);
}
class O<T> : C<T>
{
public O<T> ThenBy<K>(Func<T,K> keySelector);
public O<T> ThenByDescending<K>(Func<T,K> keySelector);
}
class G<K,T> : C<T>
{
public K Key { get; }
}
Здравствуйте, lomeo, Вы писали:
L>Во-первых, из этого описания можно понять различия в поддержке ФП языков. Однако его надо читать. Значит это будет вроде пояснения к тем оценкам, что ты выставил этим языкам, верно я понял?
Я бы рассматривал эти оценки более абстрактно, ну, как номера описаний, что ли. Это точно не аналог универсальной системе школьных оценок.
L>Во-вторых, (частности) подход к ФП может быть разным, а из этого описания можно сделать вывод, что Хаскель является подмножеством Немерле.
Дык, когда будет сравниваться поддержка ФП, тогда на свет и выплывут частности. А так, по сути и получается, что язык поддерживающий одну парадигму является подмножеством языка поддерживающего две (включая первую). Но это же очень поверхностный взгляд на вещи.
L> Однако, это не так,
Мы же не пытаемся посторить отношение между языками. Мы хотим сравнить сравнимое и описать то, что сравнить нельзя.
L>...вещи как multiparameter type classes, type families, GADT (тут, правда, не уверен) и т.д.
Это все относится к системе типов. Вот в ее описании и надо продумать сравнение. Система типов Хаскеля конечно уникальна, но состоит она из вполне понятных всем вещей. В ней есть и плюсы и минусы. В других языках есть другие идиомы. Где-то они удобнее, где-то нет.
Главное, что эти вопросы имеют очень косвенное отношение к поддержке именно ФП. Система типов Хаскеля несомненно сильная сторона Хаскеля, но не всего ФП как парадигмы. Так и нужно оценивая ФП оценивать его основные моменты. Если есть какие-то аспекты системы типов которые позволяют писать в ФС более удобно, то их нужно оговорить и продемонстрировать. Причем в других языках нужно попытаться найти средства заменяющие данные (если такие есть). Скажем монады и классы типов в том же Немерле или Шарпе заменяются наличием классов, наследования и интерфейсов. То что классы типов чем-то лучше или хуже в применении нужно разбирать при рассмотрении системы типов, а не при рассмотрении поддержки ФП.
L> как не относящиеся к ФП, то ещё остаётся масса различий — разница в выводе типов,
Вот и будем разбирать этот вопрос при рассмотрении системы типов.
L> разница в системе типов (пример с гарантией на уровне типов в отсутствии side effect-ов внутри atomically у STM),
Вот это можно внести как пункт ФП-таблице. Я бы обобщил этот вопрос. Нужно рассматривать гарантии отсуствия побочных эффектов как таковых. А уж то, что оные есть на уровне типов — это частности которые должны стать подразделом.
L> pattern guards,
Ну, это вообще ни в какие вороста. Тут даже ФП не особ причем. Будет раздел посвященный сопоставлению с обрзцом. В нем скажем С++ и C# получат баранку, а языки реализующие данную фичу получат ее оценку по отдельным пунтам.
L> view patterns,
Тоже самое.
L> использование карринга в качестве порождения комбинаторов (eDSL) и т.д.
Это вопрос ДСЛ-естрония. Что до каринга, то мы уже о нем говорили. Это сахар для комбинирования фунций. Вот при расмотрении этого вопроса и надо его рассматривать.
Опять же никто не мешате рассматривать одну фичу в разных аспектах. Но не надо смешивать. ДСЛ-и, ДСЛ-ями, а кобинирование фунций комбинированием. Скажем Шарп не очень то позиционирется как ДСЛ-язык (хотя библиотеку аля Парсек на нем таки повторили), а в Немерле есть более мощьные средства для этого.
L> Стоит ли дописывать об этой разнице?
Стоит. Но всему свое место. Не надо все мешать в одну кучу. Те кого трогает ДСЛ-естроение откроют соответствующий раздел и прочут его. А те кому интересны возможности поддержки ФП — прочтут соответствующий раздел.
L>Мне это представляется в целом так. Есть стандартная проблема — такая то. На языке таком то она решается так-то, на этом так-то, на этом даже проблемы такой не стоит, а на этом мы никак её не обойдём. У этого решения такие то преимущества в таких то условиях, а у этого такие то недостатки. До сих пор всё понятно.
К сожалению, даже на одном и том же языке одни ти те же проблемы могут решаться по разному. А уж на разных языках и подоавно. Скажем вопросы автоматизации раеализации паттернов ОО-проектирования мало интересуют тех кто пишет на Хаскеле хотя бы потому, что Хаскель не предназначен для ООП. И наоборот, вопросы чистоты мало трогают тех кто пришет на С++.
К тому же чтобы сравнивать решения нужно хорошо знать язвк (чтобы свободно читат код на нем).
Подобное сравнение тоже конечно интересно, но мне кажется оно должно быть бонусом более формальному срвнению.
В качестве примера можно взять Гапертоновскую "Проблему К". Привести примеры реализаций с коментариями, что делается в коде и почему выбраны те или иные решения.
L>Но вот дальше слишком много субъективного, это уровень генерации флейма. Хотя у этого решения такие то недостатки, но для одного они более важны, так как он чаще работает вот в таких то условиях, а для другого менее. Оценки могут не просто отличаться, они могут существенно различаться.
Скажу больше. Самое кривое решение может оказаться приемлемым для большинства, так как оно в духе ООП, а оно (большинство) только его пока и знает. А другие решения вообще будут казаться чем-то сильно запутанным, так как им — Блабам, просто не понятны идеомы используемые в решении.
L>Давай что ли начнём что нибудь обсуждать, а там поглядим, насколько страшно то, чего я опасаюсь?
Вот это разумное предложение. Надо создать отдельную ветку, скажем, посвященную поддержке парадигм, а там будет видно.
L>ОК, т.е. всё таки получается миниэнциклопедия?
Хоть горшком, только не в печь...
L>Осмелюсь заявить, что наличие LH в Haskell не сильно то...
Это детали. Вот когда дойдем до него, тогда и обсудим.
L>Кстати, query comprehension в C# — это скорее do-syntax, т.к. query работает для разных IEnumerable, а do для разных монад. Может быть стоит сравнивать именно их?
Я думаю, что их вообще бесполезно сравнивать. Сравнивать, в данном случае, лучше решение проблем обработки последовательностей, т.е. того на что направлены данные механизмы.
L>Уже есть масса информации в таблицах. Может стоит поменять представление, добавить к таблицам описания, а то они в сносках. L>Чтобы не начинать всё с самого начала.
Если ты о таблицах в Вики, то там неточной информации больше. Я бы начал с нуля.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Во-вторых, (частности) подход к ФП может быть разным, а из этого описания можно сделать вывод, что Хаскель является подмножеством Немерле. Однако, это не так, даже если оставить такие глобальные вещи как multiparameter type classes, type families, GADT (тут, правда, не уверен) и т.д. как не относящиеся к ФП, то ещё остаётся масса различий — разница в выводе типов, разница в системе типов (пример с гарантией на уровне типов в отсутствии side effect-ов внутри atomically у STM), pattern guards, view patterns, использование карринга в качестве порождения комбинаторов (eDSL) и т.д. Стоит ли дописывать об этой разнице?
стоит ли спорить с Владом? он во-первых, во всём этом не разбирается, во-вторых, уверен, что всё в чём он не смог разобраться, не нужно. сейчас пошёл частный вариант этого убеждения — что оно не относится к ФП
я бы лично дал оценку ml 8, а хаскелу — 12: ФП далеко ушло от простого использования higher-order functions and anonymous lambdas, которыми ограничены оценки Влада
Здравствуйте, BulatZiganshin, Вы писали:
BZ>стоит ли спорить с Владом? он во-первых, во всём этом не разбирается, во-вторых, уверен, что всё в чём он не смог разобраться, не нужно. сейчас пошёл частный вариант этого убеждения — что оно не относится к ФП
Этого я тоже боюсь, есть у него такая черта, непробиваемость называется. Но с другой стороны — не спорить я всегда успею Потом, Влад всё таки будет не единственным, полагаю.
BZ>я бы лично дал оценку ml 8, а хаскелу — 12: ФП далеко ушло от простого использования higher-order functions and anonymous lambdas, которыми ограничены оценки Влада
Вот-вот, оценки уж очень зависят от оценивающего, его опыта, взглядов, пристрастий, да даже объективно — от места приложения оцениваемого пункта, с другой стороны не оценивать при проведении сравнения нельзя.
Я просто не знаю, как это делать. У тебя есть предложение, как можно сделать качественное сравнение языков?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>стоит ли спорить с Владом? он во-первых, во всём этом не разбирается, во-вторых, уверен, что всё в чём он не смог разобраться, не нужно. сейчас пошёл частный вариант этого убеждения — что оно не относится к ФП
Прости за авториторизм, но следующее обсуждение моей песоны с твоей стороны приведет тебя в баню на месяц. И мне по фигу в шутку оно там или всерьез. Мне это уже надоело. Во всем должна быть мера.
BZ>я бы лично дал оценку ml 8, а хаскелу — 12: ФП далеко ушло от простого использования higher-order functions and anonymous lambdas,
Это твое мнение. Высказывайся, обосновывай — обсудим.
BZ>которыми ограничены оценки Влада
Мм... полгода.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>По делу сказать есть что? Если нет, то проходим даельше.
Что-то все заглохло.
Я тут нашел чудную статью по теме http://home.perm.ru/~strannik/st_txt_prog_07.html
Ладно то что программу на итоне если правильно написать можно ужать до 3 строчек, простительно, но то что самый шустрый среди сравниваемых языыков у него оказался самым медленным это что-то
Да, правда чудная статья. Где-то использована сортировка из библиотеки, а где-то почему-то реализована вручную, несмотря на наличие библиотечной. Потом еще удивляется длине исходников и скорости.. Почему при наличии компиляторов использовались интерпретаторы тоже непонятно.
Потом, Влад всё таки будет не единственным, полагаю.
