Здравствуйте, samius, Вы писали:
VD>>В хаскеле много чего нет. Например, нет инкапсуляции и безопасности на ее основе. В общем, язык другой. S>Другой, но инкапсуляция все же есть. Это как если бы в C# все поля были открыты, но инкапсуляция бы обеспечивалась только тем, что у клиентского кода есть только интерфейс сущности и нет знаний о типе, его реализующем. У хаскеля роль интерфейсов играют классы типов. Чем не инкапсуляция?
Тем что fmap позволяет ее нарушить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
VD>>fmap написан на хаскеле или это какая-то "магическая" функция предоставляемая системой? VD>>Думаю, второе.
К>См. Functor, ничего магического
Из этого ответа я ровным счетом ничего не понимаю.
Я не понимаю как универсальная функция может получать возможность перебирать любые структуры дынных и строить их копии ничего не зная о них.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
ГВ>>В данном случае ключевой признак — отсутствие связей внутри отношения. Остальное — см. теорию РСУБД. IT>Дай ссылочку на твою теорию, я посмотрю. А то мне не понятно как внутри отношения (слова, которое означает 'связь, зависимость') могут отсутствовать связи.
Формулировка удивительная, но правильная по сути. Нормальные формы — как раз последовательное исключение функциональных связей.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Да... и желательно решение без создания лишних функций.
Хорошо, перефразирую первый вариант.
VD>А то как-то не красиво получается сравнивать оверхэд создаваемый лишними функциями с решением умещающимся на четырех строках.
namespace MyProgram { class Program {
static void sample1(int[] arr, F<int> func)
{
for(int i = 1; i < arr.Length; ++i)
{
if (arr[i] - arr[i - 1] == 1)
{
func(arr[i]);
++i;
}
}
}
static IEnumerable<int> sample1b(IEnumerable<int> arr)
{
bool first = true;
int prev = 0;
foreach (int i in arr)
{
if (first)
{
first = false;
prev = i;
}
else if (i - prev == 1)
{
yield return i;
first = true;
}
else prev = i;
}
}
static void Main(string[] args)
{
int[] arr = { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 };
foreach (int i in sample1b(arr))
Console.WriteLine(i);
sample1(arr, i => Console.WriteLine(i));
// Cпециально для VladD2for (int i = 1; i < arr.Length; ++i)
{
if (arr[i] - arr[i - 1] == 1)
{
Console.WriteLine(arr[i]);
++i;
}
}
}
}}
А вот речи об обязательном порождении нового массива в условии задачи не было.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace MyProgram { class Program {
delegate void F<in T>(T arg);static void sample1(int[] arr, F<int> func)
{
for(int i = 1; i < arr.Length; ++i)
{
if (arr[i] - arr[i - 1] == 1)
{
func(arr[i]);
++i;
}
}
}
static IEnumerable<int> sample1b(IEnumerable<int> arr)
{
bool first = true;
int prev = 0;
foreach (int i in arr)
{
if (first)
{
first = false;
prev = i;
}
else if (i - prev == 1)
{
yield return i;
first = true;
}
else prev = i;
}
}
static void Main(string[] args)
{
int[] arr = { 1, 2, 3, 3, 4, 4, 5, 1, 1, 2 };
foreach (int i in sample1b(arr))
Console.WriteLine(i);
sample1(arr, i => Console.WriteLine(i));
// Cпециально для VladD2for (int i = 1; i < arr.Length; ++i)
{
if (arr[i] - arr[i - 1] == 1)
{
Console.WriteLine(arr[i]);
++i;
}
}
}
}}
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Lloyd, Вы писали:
G>>Самокритично это было бы, если бы я говорил о себе. А я просто разъясняю тебе смысл фразы. И кроме того, ко мне это при всем желании отнести тяжело — у меня нет навязчивого желания кому-либо доказывать, что он неправ, "истины ради". Это вы у нас пережить не можете, если чье-то мнение с вашим не совпадает.
L>Вы очень тонкий психолог. Вот так, по паре десятков постов, точно поставить диагноз, это вызывает уважение. Браво, маэстро. Снимаю шляпу.
"Диагнозом" это было бы, если бы я заявил, что у вас "неврастеническое расстройство". А я просто характеризую поведение — то, которое наблюдаю (не только Ваше, уважаемый коллега), и его возможные мотивы — последнее необходимо для понимания собеседника.
Поведение и его мотивы, но не вашу личность. Во-первых — будучи и в самом деле неплохим психологом, я знаю, что о вашей личности невозможно составить адекватного представления даже по тысяче постов при всем желании. Люди ведут себя совершенно по разному на форумах и в жизни — ибо в интернете у них возникает ложное ощущение анонимности и безнаказанности. В личном общении они никогда себе не позволят того, что позволяют себе в сети.
И есть вторая причина, почему я не оцениваю вашу личность — она мне ни в малейшей степени не интересна. Меня интересует исключительно тема беседы, и то, что вы по поводу темы беседы можете сказать. И все.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
VD>>>fmap написан на хаскеле или это какая-то "магическая" функция предоставляемая системой? VD>>>Думаю, второе.
К>>См. Functor, ничего магического
VD>Из этого ответа я ровным счетом ничего не понимаю. VD>Я не понимаю как универсальная функция может получать возможность перебирать любые структуры дынных и строить их копии ничего не зная о них.
fmap — это не универсальная функция, а декларация о наличии конкретной функции для конкретных типов данных.
Здравствуйте, VladD2, Вы писали:
VD>>>4. Можно ли называть технологию более удобную для обработки объектов в памяти нежели для работы с СУБД "большому счету заточен под прикладную задачу, и нафиг не вперся в случае, если мы не работаем с реляционной БД"? ГВ>>Вопрос поставлен некорректно. Как понимать "более удобную для обработки объектов в памяти нежели для работы с СУБД"? Критерии сравнения "более менее" каковы?
VD>Это вопрос к Гапертону. Это его цитата которую ты так ревностно защищаешь.
Странно. Цитирую тебя, а вопросы — к Гапертону.
ГВ>>Вот ещё пара встречных вопросов: VD>Я просил ответить на мои вопросы.
Тем не менее, спасибо за ответы на мои.
VD>В прочем полученных ответов уже достаточно чтобы сделать вывод о том, что утверждения Гапертона ложны. А ЛИНК как ни странно является универсальным средством обработки данных. VD>Что и следовало доказать.
Полученные ответы ортогональны вопросу Гапертона, потому в данном контексте они ничего не доказывают.
VD>Так что остается последний вопрос. VD>Неужели тебе приятнее выглядеть человеком не владеющим азами логического мышления нежели человеком который ошибался, но понял свои ошибки?
В чьих глазах?
ГВ>>1) Имеем массив: {1, 2, 3, 7, 8, 9, 10}. Как из этого массива посредством LINQ извлечь элементы, на единицу большие предыдущего, при этом извлечённый элемент не должен принимать участия в последующем сравнении, т.е. результат должен быть {2, 8, 10}?
VD>Как-то так (Nemerle, так как писать на нем приятнее): VD>
VD>Объясняю преимущества перед использованием циклов. VD>1. Отсутствуют специальные случае вроде пустого массива которые можно забыть проверить.
i < arr.Length
спасает, как ни странно.
VD>2. Отсутствует работа с индексами, так что ошибка не приведет к генерации исключений в непротестированных случаях.
Каковые (случаи выхода за границы) попросту исчезают как данность.
VD>3. Решение задачи близко к ее постановке. Мы описывает, что хотим получить, а не то как мы это хотим получить. Нам не нужно думать о переборе значений, мы думаем только об алгоритме.
Угу. "Что" мы хотим получить в терминах ФП. Песню про "что-как" дихотомию я наслушался во времена ОО-истерии, хватит уже.
VD>Проблема только одна. Чтобы прочесть и понят данный код нужно иметь некоторый опыт использования ФВП и абстрагирования алгоритма от его реализации.
...а ещё он адски длинный и в нём очень трудно визуально выделить блоки. Этим же грешит неуёмное использование шаблонов C++.
ГВ>>Как ты понимаешь, традиционным for обе задачи решаются тривиально. VD>Не не понимаю. Я понимаю, что ты постарался подобрать задачку которая по твоим соображениям плохо решается с помощью линковских функций. Более правильным направлением было бы выбрать задачи обработки матриц. В прочем и там можно использовать линк, хотя не так уж и осмысленно.
Угу. Но матрицами было бы сложнее, а тут простенькая задачка, зато какая феерия!
VD>Вопрос не в том удалось тебе или не удалось придумать такие задачки. VD>Вопрос в том зачем ты это пытался сделать?
Мои мотивы выписаны во всём топике контрастными буквами.
VD>Ведь очевидно, что есть масса задач которые решаются с помощью линка в десятки раз удобнее. Будешь спорить? VD>И эти задачи никак не связаны с СУБД тем более с реляционными.
Пока что оказывается, что они очень сильно на них похожи.
VD>А раз так, то говорить о какой-то привязанности линка к РСУБД — это просто идти против базовых концепций логики. Говоря простыми словами — это полный идиотизм.
Последи за лексикой, ладно? Поскольку у тебя всё равно рука не поднимется самого себя забанить, то я тебя прошу по-хорошему.
VD>Так что ты еще не понял, и что ты пыташся доказать? VD>Или ты все же давно все понял и просто троллишь специально не желая мыслить логически?
Логически здесь как раз следует, что в ряде случаев LINQ — не пришей кобыле хвост. Одна лишь демонстрация крутизны на ровном месте. Да и честно сказать, даже реализация на Nemerle круто проигрывает банальному циклу в читабельности. Зато, что любопытно, реализация на Go
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Угу. Вполне это допускаю, что ради интеграции LINQ пришлось доработать C#. Значит, -1 аргумент в пользу "благих намерений" MS.
МС — это не один человек. Там есть Хейльсберг который потихоничку превращается в Страустурпа или даже в комитет (в плане консерватизма) и есть люди вроде Меера.
Я конечно свечку не держал, но думаю, что одной из уловок Меера было протаскивание ФП под видом черт знает чего.
VD>>Возможности для программирования в функциональном стиле были и в 2.0. Но удобным это стало только в 3.0, так как: VD>>А. Язык расширели выводом типов, локаничными лямбдами и деревьями выражений.
ГВ>Угу-угу. Отображать структуру IL-кода прайвеси не позволяет, могут не понять. Потому пришлось городить дополнительный огород с отображаемыми выражениями. Между прочим, это самый простой и естественный способ построения развитого ORM даже средствами C++. Уж поверь мне на слово.
Ты опять в своем изолированном мире варишься. Тебя даже понять нельзя.
ГВ>Ёлки зелёные. Это никак не отражается на том назначении LINQ, которое (на мой взгляд) просвечивает у него через все дырки.
У тебя явно пунктик по поводу назначения. Повторять тебе что-то считаю бессмысленным. Живи в своем вымешленном мире дальше.
ГВ>Ну, и я прекрасно понимаю автора. Под соусом адаптации к SQL построить довольно интересную штуковину.
Кончай повторять бред. Не было там никаких адаптаций. Несколько функций переименовали просто чтобы людям не так страшно было новый мир осваивать. Map переименовали в Select, Filter в Where, Fold в Aggregate, Sort в OrderBy. По сути же как были функции, так и остались.
Или ты думаешь, что Хаскель тоже проектировали под соусом адаптации к SQL?
ГВ>И ни на йоту оного автора не осуждаю. Я бы тоже так поступил на его месте. Тем более, что ФП-фичи и в самом деле довольно полезная штука. Как и ОО-фичи, если без излишней голубоглазости ими пользоваться.
Замечательно что ты это понял. Осталось расстаться с предрассудками которые ты тут пытался насаждать в неокрепшие умы масс.
ГВ>Давай замнём этот вопрос для ясности. Так оно спокойней.
Давай просто перестанет повторять необоснованные суждения противоречащие собственным же высказываниям.
Пойми, я тоже с трудом признаю не правоту. Порой на это уходит недели или даже месяцы. Но если не признавать свою не правоту, то рано или поздно становишься догматиком и твои суждения уже никому не будут интересны.
ГВ>Иными словами, тебе плевать на установление действительных причин. Согласен, гораздо проще руководствоваться иллюзиями альтруизма MS.
Мне вообще плевать на причины, если обсуждается конеретная технология или вещь. К примеру бесполезно обсуждать причины появления паравого двигателя в споре о том является ли он частным решением для перекачки воды или общим решением — двигателем. Из того факта, что паровой двигатель был изобретен для перекачки воды не следует, что он только для этого и предназначен. Или хотя бы в первую очередь для этого...
К тому же ты уже достал повторять чушь. Тебе сказали, что в Хаскеле может и думали только о СУБД. Но когда разрабатывали ЛИНК, то думали только и исключительно об универсальном решении. Просто средство доступа к данным никто в язык общего назначения не включил бы.
ГВ>>>Вот теперь иди и покупай учебник по логике сам. Факт единственно лишь того, что LINQ работает с РСУБД не рассматривался в качестве достаточного для выводов основания ни мной, ни, полагаю, Гапертоном. VD>>Да, ну? А что же за "факты" ты использовал? VD>>И можно поинтересоваться, ты серьезно считаешь, что если факт ничего не говорящий о проблеме соединить с другими, то он начнет хоть как-то относиться к проблеме или влиять на общий вывод?
ГВ>Я очень хорошо знаю о проблеме ORM и соответствующих фактах наличия сторонних средств.
Я тебя не спрашивал что ты знаешь о "проблеме ORM". Я задал конкретный вопрос. Можно отвечать именно на него, а не выдавать мнение на отвлеченные темы?
Я же уже четко продемонстрировал тебе, что отвлекаться на них не буду.
ГВ> И очень хорошо знаю, что до LINQ собственных более или менее адекватных средств разрешения этой проблемы у MS не было. Почему я должен скидывать эти два соображения со счетов — сие мне неведомо.
Потому что они не имеют отношения к делу.
ГВ>Ещё я очень хорошо знаю, что под "источником данных" чаще всего подразумевается РСУБД, такова общая практика. Ещё я могу припомнить кое-что из своей практики, после всего этого, поверь, можно сделать очень много выводов.
Опять же. Никому нет никокого дела до того что и под чем понимают люди и с какой частотой.
LINQ to Object используют чаще чем LINQ to SQL. Но из этого не следует, что LINQ создан толко для обработки данных в памяти.
VD>>А мне не надо об этом думать. Информация о том что явилось причиной для разработки универсального механизма никак не влияет на факт его использования.
ГВ>Если тебе не надо об этом думать — никто тебя не заставляет.
Ну, как же? Ты все время меня пытаешься заставить подумать о разной фигне не относящейся к делу.
ГВ>Просто скажи, что тебе не интересно это обсуждать и выйди из обсуждения.
Ага. Не интересно. Я лучше тебя знаю был задуман и реализован линк.
ГВ> Только какой смысл при этом встревать с опровержениями высказываний других?
Потому что "другие" пытаются путем подмены обсуждаемых понятий обосновать ложные умозаключения.
ГВ> Ты считаешь LINQ универсальным средством, введённым MS ради заботы о малых сих — нет проблем.
Я считаю LINQ универсальным средством и мне по фиг ради чего он введен.
Это факт и его глупо оспаривать.
ГВ> А я этого не считаю и поддерживаю разными +-*/ тех, кто высказывается в таком ключе, вот и весь спор.
Ты не просто поддерживаешь. Ты постоянно нарушаешь принципы логического вывода в своих суждениях.
ГВ> Переубедить меня сможет, вполне вероятно, письмо Билла Гейтса, датированное 2001-м годом, где будет написано: "...we need to implement functional programming for our customers, are you know somebody good in functional languages development?" Если у тебя завалялось такое, то я с удовольствием соглашусь с твоими доводами. Если нет или потёр случайно — ну извини, я продолжаю считать, что первопричиной разработки LINQ явился OR-импеданс. Это просто, понятно и лишено обоснований с привлечением иррациональных соображений.
Тебя ничего не сможет переубедить. Ты имеешь мнение и оспорить его невозомжно, так как при его обосновании ты просто плюешь на логические рассуждения и подменяешь понятия.
VD>>Использовать деревья выражений можно как угодно. Их можно трансформировать в рантайме и скомпилировать. На этом принципе, в не малой степени реализован тип dinamic в C# 4.0. Их можно использовать для генерации запросов к ООБД которая никогда не пользовалась реляционными принципами. Их можно вообще не использовать. Например, LINQ to Objects и LINQ to XML вообще их не использут, но при этом позволяют как использовать ФВП входящие в состав LINQ-а, так и синтаксические расширения языков.
ГВ>Для "как угодно" у них довольно узкий набор,
Очередное голословное утверждение.
ГВ> хотя вполне достаточный для построения сложных выражений, не буду спорить.
Так и не спорь.
ГВ> Но вот кое-чего в Linq.Expressions нет. Например, нет меток/goto. По странному стечению обстоятельств goto отсутствует и в выражениях SQL-запросов.
В Хаскле и Nemerle тоже нет GOTO. Видимо тут тоже странное стечение обстоятельств.
Их тоже писали под влиянием SQL?
Ты хоть понимаешь каких чудесных выводов можно добиться таким образом?
Кстати, в Яве тоже нет GOTO!
ГВ>Кстати, этот факт служит дополнительным аргументом (помимо других) для введения ФП-свойств в любой язык программирования, который предполагается использовать в тесной связи с SQL-серверами.
Гениально!
А чему служит факт, что современный SQL поддерживает рекурсивные запросы (на базе CTE), а ЛИНК нет?
VD>>Это не понятно только с твоей колокольни. Если перестать думать о LINQ-е как о каком-то ESQL-е переростке, то все станет сразу очевидным. LINQ не набивают фичами. Наоборот на его основе делают необходимые в конкретных предметных областых расширения.
ГВ>Ладно, согласен.
Ого! Прогресс?
ГВ>Не набивают, а пришивают куда угодно. На основное соображение, оспариваемое без малого двумя сотнями сообщений это никак не влияет.
... кажется нет.
Заметь, кстати, две сотни накатали 2 человека. Один уже свалил из спора (похоже).
VD>>Пойми. Все очень просто. Линк — это абстрагирование от паттернов кодирования. Абстрагирование от них делает код более декларативным.
ГВ>Вот за такую постановку задачи бьют канделябром. Исключение составляют совсем юные и синеглазые. Им можно изъясняться подобными оборотами.
Ну, канделябром ни каждому получится вдарить. Ведь нападающему могут этот канделябр и засунуть куда не следует .
А то что ты не понимаешь моих слов говорит только о том, что ты не умеешь глядеть на вещи с разных углов.
VD>>А декларативный код можно интерпретировать по разному. Его вычисление можно организовать по разному. Можно распараллеливание (как в PLINQ), можно превратить код в дерево выражений в рантайме передать некоему провайдеру который сделает с ним то что нужно провайдеру (передаст на выполнение на другую машину или сформирует SQL и выполнит его в СУБД).
ГВ>Ну да-да. "Слоны всем, в ямы никого, Джунгахора!" Ладно, если не вышучивать, то всё это — вполне естественные следствия ФП. Хотя на мой взгляд, подо всё это хозяйство логичнее было бы завести подходящие атрибуты в C#.
Что за атрибуты? Выражайтесь яснее (с)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>>Насчёт состояние == мутабельность, это, конечно, не совсем так, но обычно, когда говорят "состояние" подразумевают именно изменяемое состояние.
L>Gaperton, куда ж ты слился-то. Ты же так активно отстаивал, что состояние == мутабльность. А теперь так резко замолчал.
Ты внимательно почитай, что тебе lomeo пишет. И задумайся как следует, почему именно он не возражает мне, а пытается что-то втолковать тебе. Разъясняя тебе, что именно я имел в виду.
И в будущем, пожалуйста избегай выражений вроде "слился", когда хочешь обратиться ко мне, будь так любезен.
Здравствуйте, Gaperton, Вы писали:
L>>>Насчёт состояние == мутабельность, это, конечно, не совсем так, но обычно, когда говорят "состояние" подразумевают именно изменяемое состояние.
L>>Gaperton, куда ж ты слился-то. Ты же так активно отстаивал, что состояние == мутабльность. А теперь так резко замолчал.
G>Ты внимательно почитай, что тебе lomeo пишет. И задумайся как следует, почему именно он не возражает мне, а пытается что-то втолковать тебе. Разъясняя тебе, что именно я имел в виду.
Я читаю внимательно все посты, на которые отвечаю, в том числе и твои. И не заметить твоих многократных уверений, что из наличия состояния обязательного следует мутабельность, не смог. При этом тебе приводились примеры, из которых однозначно следовало, что ты не прав, но ты продолжал упорствовать.
G>И в будущем, пожалуйста избегай выражений вроде "слился", когда хочешь обратиться ко мне, будь так любезен.
Извини, я не смог подобрать из моего языкового запаса слова, лучше отражающее то, что я видел. Но я буду работать над этим.
ГВ>А вот речи об обязательном порождении нового массива в условии задачи не было.
Ну, давай добавим.
Так же давай попробуем в твоем решении заменить массив на энумератор.
Надеюсь мы установили, что ЛИНК-ом она тоже решается и не так уж страшно?
Тут проблема то в чем. Пока задачка детская ее конечно по фигу чем решать.
А вот когда задачки наслаиваются друг на друга, когда они становятся не тривиальны, то циклы очень быстро превращаются в одну большую кашу.
Конечно разбивая все на функции можно добиваться приемлемой сложности отдельно взятых фрагментов, но намного удобнее использовать ФВП которые в шарпе предоставляет ЛИНК.
Не веришь?
Давай тогда решим другие задачки. Скажем те что требуют группировки и сортировки данных. А еще лучше требующие комплексой их обработки в соответствии с некоторыми условиями.
Ты ведь еще не знаешь, что линк позволяет делать условные запросы динамически?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Там все несколько сложнее. Есть конкретные реализации завязанные на IEnumerable/IQueryable, а есть "query expression pattern" который абстрагирован от конкретики: VD>Ты где-то видишь здесь IEnumerable/IQueryable?
VD>fmap написан на хаскеле или это какая-то "магическая" функция предоставляемая системой? VD>Думаю, второе.
Первое. По аналогии с LINQ для своего типа мы реализуем её по своему.
data Tree a = Node [Tree a] -- дерево - это нода со списком деревьев.instance Functor Tree where
fmap f (Node xs) = fmap (fmap f) xs
VD>Потенциально конечно можно реализовать query expression pattern через рефлексию и ты получишь полный аналог fmap за исключением ограничений безопасности. Но оно надо, такое решение?
Такое тоже есть gmap, но сейчас не об этом.
L>>Для дерева результат — это дерево, для функции — функция, для любого другого типа данных, являющегося функтором — соответствующее отображение. VD>В хаскеле много чего нет. Например, нет инкапсуляции и безопасности на ее основе. В общем, язык другой.
Инкапсуляция есть. Ограничения на уровне модуля — говорим, что импортируем.
module Test
(Foo, mkFoo, fromFoo)
where
data Foo = Foo Int
mkFoo = Foo
fromFoo (Foo i) = i
Ты не сможешь залезть в потроха Foo иначе чем через fromFoo, создать Foo сможешь тоже только с помощью функции mkFoo. Иначе говоря, паттерн-матчингом разобрать не сможешь.
VD>Я же тебе хотел сказать о другом. В хаскеле вполне можно работат с деревьями без fmap. Более того скорее всего для реальной прикладной задачи ты как раз не будешь использовать fmap. Ты или напишешь рекурсивную функцию, или будешь работать с деревом используя знания о его структуре. Вот та же фигня и в линке.
В Haskell есть даже такое понятие как type class morphism. Для своих типов данных считается хорошим тоном реализовывать инстансы стандартных классов типов. Т.е. если я реализую дерево — то я, скорее всего, напишу для него реализацию Functor/Foldable/Traversable и т.д. Наоборот, если я пользуюсь чьим то типом данных, то я ожидаю, что у него есть соответствующие инстансы, и ожидаю от них соответствующего поведения (потому что это достаточно абстрактные вещи, которые есть у многих многих типов данных — вспомним бананы, линзы, колючую проволоку).
С другой стороны, в Haskell работать с рекурсивными типами данных через рекурсивные функции считается плохим тоном, если есть готовые комбинаторы для соответствующих морфизмов. Обычно они есть.
Поскольку LINQ очень сильно похож на Functor/Monad, то я ожидал увидеть схожее поведение. Интерфейс, который ты мне показал, на это способен, но используют его обычно только для последовательностей (это я так понял, может я ошибаюсь).
Спасибо, я, кажется, разобрался. Поправь меня — в принципе, ничто не мешает конкретной реализации LINQ возвращать любой тип в Select, например, отличающийся от исходного (без учёта типов-аргументов).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, samius, Вы писали:
S>>fmap — это не универсальная функция, а декларация о наличии конкретной функции для конкретных типов данных.
VD>Тогда она в данном разговоре не в кассу. Ведь к любому типу можно прикрутить интерфейс.
В защиту хаскеля: классы типов гораздо круче интерфейсов.
Здравствуйте, VladD2, Вы писали:
S>>fmap — это не универсальная функция, а декларация о наличии конкретной функции для конкретных типов данных. VD>Тогда она в данном разговоре не в кассу. Ведь к любому типу можно прикрутить интерфейс.
Я её сравнивал с Select. Его же тоже можно к любому типу прикрутить.
Здравствуйте, VladD2, Вы писали:
VD>Я конечно свечку не держал, но думаю, что одной из уловок Меера было протаскивание ФП под видом черт знает чего.
Удивительное дело, как мы тут с тобой совпадаем.
ГВ>>Угу-угу. Отображать структуру IL-кода прайвеси не позволяет, могут не понять. Потому пришлось городить дополнительный огород с отображаемыми выражениями. Между прочим, это самый простой и естественный способ построения развитого ORM даже средствами C++. Уж поверь мне на слово. VD>Ты опять в своем изолированном мире варишься. Тебя даже понять нельзя.
Что тебе не понятно? Что было бы куда прикольней, если бы MS сделала прямое отображение IL на SQL-Server?
ГВ>>Ну, и я прекрасно понимаю автора. Под соусом адаптации к SQL построить довольно интересную штуковину. VD>Кончай повторять бред.
Хм. Читаем цитату в начале этого постинга... Тут случится дзен, почти обещаю.
VD>Не было там никаких адаптаций. Несколько функций переименовали просто чтобы людям не так страшно было новый мир осваивать. Map переименовали в Select, Filter в Where, Fold в Aggregate, Sort в OrderBy. По сути же как были функции, так и остались. VD>Или ты думаешь, что Хаскель тоже проектировали под соусом адаптации к SQL?
Нет, разумеется.
ГВ>>И ни на йоту оного автора не осуждаю. Я бы тоже так поступил на его месте. Тем более, что ФП-фичи и в самом деле довольно полезная штука. Как и ОО-фичи, если без излишней голубоглазости ими пользоваться. VD>Замечательно что ты это понял. Осталось расстаться с предрассудками которые ты тут пытался насаждать в неокрепшие умы масс.
Да... 36-й уровень вложеннности в дискуссии — самое удачное место для обработки масс, кто бы спорил.
ГВ>>Давай замнём этот вопрос для ясности. Так оно спокойней. VD>Давай просто перестанет повторять необоснованные суждения противоречащие собственным же высказываниям.
Встречная просьба того же порядка.
VD>Пойми, я тоже с трудом признаю не правоту. Порой на это уходит недели или даже месяцы. Но если не признавать свою не правоту, то рано или поздно становишься догматиком и твои суждения уже никому не будут интересны.
Угу. Как всегда, когда доказать не удаётся, остаётся уговорить.
ГВ>>Иными словами, тебе плевать на установление действительных причин. Согласен, гораздо проще руководствоваться иллюзиями альтруизма MS.
VD>Мне вообще плевать на причины, если обсуждается конеретная технология или вещь. К примеру бесполезно обсуждать причины появления паравого двигателя в споре о том является ли он частным решением для перекачки воды или общим решением — двигателем. Из того факта, что паровой двигатель был изобретен для перекачки воды не следует, что он только для этого и предназначен. Или хотя бы в первую очередь для этого...
Проблема в том, что сейчас мы обсуждаем как раз причины.
VD>К тому же ты уже достал повторять чушь. Тебе сказали, что в Хаскеле может и думали только о СУБД. Но когда разрабатывали ЛИНК, то думали только и исключительно об универсальном решении. Просто средство доступа к данным никто в язык общего назначения не включил бы.
Об универсальном решении чего?
ГВ>>>>Вот теперь иди и покупай учебник по логике сам. Факт единственно лишь того, что LINQ работает с РСУБД не рассматривался в качестве достаточного для выводов основания ни мной, ни, полагаю, Гапертоном. VD>>>Да, ну? А что же за "факты" ты использовал? VD>>>И можно поинтересоваться, ты серьезно считаешь, что если факт ничего не говорящий о проблеме соединить с другими, то он начнет хоть как-то относиться к проблеме или влиять на общий вывод? ГВ>>Я очень хорошо знаю о проблеме ORM и соответствующих фактах наличия сторонних средств. VD>Я тебя не спрашивал что ты знаешь о "проблеме ORM". Я задал конкретный вопрос. Можно отвечать именно на него, а не выдавать мнение на отвлеченные темы? VD>Я же уже четко продемонстрировал тебе, что отвлекаться на них не буду.
Это один из фактов, наводящих на вполне определённые размышления о причинно-следственных связях. Извини за длинную цитату.
ГВ>> И очень хорошо знаю, что до LINQ собственных более или менее адекватных средств разрешения этой проблемы у MS не было. Почему я должен скидывать эти два соображения со счетов — сие мне неведомо. VD>Потому что они не имеют отношения к делу.
Не-не-не. Это ты настаиваешь на том, что я должен от них абстрагироваться. Почему я должен абстрагироваться от весьма весомых причин в контексте обсуждения причин — ещё одна тайна.
ГВ>>Ещё я очень хорошо знаю, что под "источником данных" чаще всего подразумевается РСУБД, такова общая практика. Ещё я могу припомнить кое-что из своей практики, после всего этого, поверь, можно сделать очень много выводов. VD>Опять же. Никому нет никокого дела до того что и под чем понимают люди и с какой частотой. VD>LINQ to Object используют чаще чем LINQ to SQL. Но из этого не следует, что LINQ создан толко для обработки данных в памяти.
А кто-то это утверждает?
VD>>>А мне не надо об этом думать. Информация о том что явилось причиной для разработки универсального механизма никак не влияет на факт его использования. ГВ>>Если тебе не надо об этом думать — никто тебя не заставляет. VD>Ну, как же? Ты все время меня пытаешься заставить подумать о разной фигне не относящейся к делу.
Странно. Обсуждаем, вроде бы, назначение. А факторы, которые в немалой степени определяют это самое назначение, почему-то нужно выбросить из рассмотрения.
ГВ>>Просто скажи, что тебе не интересно это обсуждать и выйди из обсуждения. VD>Ага. Не интересно. Я лучше тебя знаю был задуман и реализован линк.
Дык. Жду прямых доказательств ошибочности моих суждений.
ГВ>> Только какой смысл при этом встревать с опровержениями высказываний других? VD>Потому что "другие" пытаются путем подмены обсуждаемых понятий обосновать ложные умозаключения.
Ага. Иными словами — неймётся. Так и запишем.
ГВ>> Ты считаешь LINQ универсальным средством, введённым MS ради заботы о малых сих — нет проблем. VD>Я считаю LINQ универсальным средством и мне по фиг ради чего он введен. VD>Это факт и его глупо оспаривать.
Ну пофиг, так пофиг. Я ж не требую от тебя изменить своё мировоззрение.
ГВ>> А я этого не считаю и поддерживаю разными +-*/ тех, кто высказывается в таком ключе, вот и весь спор. VD>Ты не просто поддерживаешь. Ты постоянно нарушаешь принципы логического вывода в своих суждениях.
Да-да. Например, путём учёта контекста. Ясное дело — грубейшее нарушение принципов логического вывода.
VD>Тебя ничего не сможет переубедить. Ты имеешь мнение и оспорить его невозомжно, так как при его обосновании ты просто плюешь на логические рассуждения и подменяешь понятия.
Ну, чуть выше ты утверждал, что лучше меня знаешь, как и почему был задуман LINQ. Так я жду рассказа. Желательно, с указанием причин событий, а не: "...и тут он решил, что было бы здорово...". Сначала расскажи о том, почему "он" получил право решать что-то.
VD>>>Использовать деревья выражений можно как угодно.[...] ГВ>>Для "как угодно" у них довольно узкий набор, VD>Очередное голословное утверждение.
Хм. Прочесть два предложения следом — не дозволяет религия?
ГВ>> хотя вполне достаточный для построения сложных выражений, не буду спорить. VD>Так и не спорь.
С этим и не спорю.
ГВ>> Но вот кое-чего в Linq.Expressions нет. Например, нет меток/goto. По странному стечению обстоятельств goto отсутствует и в выражениях SQL-запросов. VD>В Хаскле и Nemerle тоже нет GOTO. Видимо тут тоже странное стечение обстоятельств. VD>Их тоже писали под влиянием SQL?
Нет. Одно с другим не связано. Я просто отметил странное совпадение. А ещё goto — имманентная составляющая циклов.
VD>Ты хоть понимаешь каких чудесных выводов можно добиться таким образом? VD>Кстати, в Яве тоже нет GOTO!
Зато в Яве есть for/while. Вот незадача.
ГВ>>Кстати, этот факт служит дополнительным аргументом (помимо других) для введения ФП-свойств в любой язык программирования, который предполагается использовать в тесной связи с SQL-серверами. VD>Гениально! VD>А чему служит факт, что современный SQL поддерживает рекурсивные запросы (на базе CTE), а ЛИНК нет?
Вероятно, подтверждению моего высказывания о том, что возможности SQL Server всё ещё шире LINQ. Было тут где-то оно...
VD>>>Это не понятно только с твоей колокольни. Если перестать думать о LINQ-е как о каком-то ESQL-е переростке, то все станет сразу очевидным. LINQ не набивают фичами. Наоборот на его основе делают необходимые в конкретных предметных областых расширения. ГВ>>Ладно, согласен. VD>Ого! Прогресс?
А ты думал?!
ГВ>>Не набивают, а пришивают куда угодно. На основное соображение, оспариваемое без малого двумя сотнями сообщений это никак не влияет. VD>... кажется нет. VD>Заметь, кстати, две сотни накатали 2 человека. Один уже свалил из спора (похоже).
Без паники. Зато я остался. Приключения продолжаются.
VD>>>Пойми. Все очень просто. Линк — это абстрагирование от паттернов кодирования. Абстрагирование от них делает код более декларативным. ГВ>>Вот за такую постановку задачи бьют канделябром. Исключение составляют совсем юные и синеглазые. Им можно изъясняться подобными оборотами. VD>Ну, канделябром ни каждому получится вдарить. Ведь нападающему могут этот канделябр и засунуть куда не следует . VD>А то что ты не понимаешь моих слов говорит только о том, что ты не умеешь глядеть на вещи с разных углов.
Дык. Тут такой угол, что всем углам — щель.
VD>>>А декларативный код можно интерпретировать по разному. Его вычисление можно организовать по разному. Можно распараллеливание (как в PLINQ), можно превратить код в дерево выражений в рантайме передать некоему провайдеру который сделает с ним то что нужно провайдеру (передаст на выполнение на другую машину или сформирует SQL и выполнит его в СУБД). ГВ>>Ну да-да. "Слоны всем, в ямы никого, Джунгахора!" Ладно, если не вышучивать, то всё это — вполне естественные следствия ФП. Хотя на мой взгляд, подо всё это хозяйство логичнее было бы завести подходящие атрибуты в C#. VD>Что за атрибуты? Выражайтесь яснее (с)
Я тебе должен рассказать, что такое атрибуты в C#? Хм. VladD2 расспрашивает ГВ про C#? Ради этого момента стоило поспорить!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, samius, Вы писали:
VD>>В хаскеле много чего нет. Например, нет инкапсуляции и безопасности на ее основе. В общем, язык другой. S>Другой, но инкапсуляция все же есть. Это как если бы в C# все поля были открыты, но инкапсуляция бы обеспечивалась только тем, что у клиентского кода есть только интерфейс сущности и нет знаний о типе, его реализующем. У хаскеля роль интерфейсов играют классы типов. Чем не инкапсуляция?
Не то, чтоб я спорил, просто хочу уточнить. Наиболее корректный смысл "инкапсуляции" в том виде, в котором она употребляется в ООП (инкапсуляция, наследование, полиморфизм) — это обычно ADT (Abstract Data Type) + mutable state. То есть, мы взяли мутабельный стейт, но не дали доступа к его структуре, вместо этого выставили интерфейс из функций. Капитан очевидность на связи, и готов сообщить, что такая штука называется "объект".
Таких штук в Хаскеле, насколько я понимаю, нет. В Хаскеле есть просто ATD. Это не плохо, и не хорошо. Это нормально. Просто "инкапсуляция" хреновый и замыленный термин, понимаемый всеми по своему (прям как "архитектор" и "архитектура"), которого лучше избегать, чтобы избежать неоднозначности в беседе и достичь понимания.
Здравствуйте, lomeo, Вы писали:
L>Ты не сможешь залезть в потроха Foo иначе чем через fromFoo, создать Foo сможешь тоже только с помощью функции mkFoo. Иначе говоря, паттерн-матчингом разобрать не сможешь.
А как же gmap?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Это вы у нас пережить не можете, если чье-то мнение с вашим не совпадает. 
Ради этого момента стоило поспорить! 