S>>Decimal static CalcBalanceForDate(Date date, allTransfers)
S>> return (from t in allTransfers where t.Date <= date select t.Amount).Sum();
S>>
Сослепу LINQ перепутал с SQL. Это ничего не меняет в моем ответе (кроме нерелевантной ссылки на структуру таблиц), но вообще... Вообще, такие вещи я бы делал на стороне сервера. Что нельзя встроенными функциями агрегирования, то хранимками.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Твои представления об ООП наивны.
V>Это твои представления об ФП догматичны. А мои об ООП ровно такие, каково состояние дел в ООП прямо на сегодня у лидеров рынка.
Прям пичалька за рынок взяла
V>>>А "нечистое ФП" — это процедурный подход + функциональный тип. )) S>>нечистое ФП вполне может быть испачкано ООП-ой
V>Увы, тогда это будет уже скорее ООП. Оно итак испачкано ФП-ой чуть ли не изначально.
нечистое ФП — это скорее ООП.
V>>>Ключевое в связи ООП с мышлением я вижу именно в способности мышления человека моделировать окружающий мир. S>>Ничего что до ООП человек тоже мог моделировать окружающий мир? Или возможность моделирования открыл Др. Кэй?
V>Гы, ничего, что сейчас ты показал умение переворачивать всё с ног на голову почище моего? V>Жаль что под перевернутым на этот раз пусто, т.к. именно способность человека моделировать окружающий мир лежит в идее ООП. Никак не наоборот, ес-но. Ведь это человек назначает объектам роли, то бишь это не происходит "само по себе".
Способность человека моделировать лежит во всех других идеях ничуть не меньше, чем в ООП.
S>>С реакцией от истории в ФП все впорядке. Да и вся история как на ладони заодно.
V>Увы, если брать отдельно взятый функциональный объект — то не в порядке. В порядке там только при наличии состояния. А в чем оно заключается в "чистом ФП" (которое даже без монад) — я тебе уже писал... про стек вычислений и положение указателя команд в потоке исполнения.
Отдельно взятый функциональный объект ты походу взял из ООП. В ФП я о таких не слышал. Не занимается ФП отдельно взятыми из ООП объектами.
S>>что не так с отношениями?
V>Функциональная декомпозиция выглядит как набор независимых ф-ий. Сравни с иерархией ООП.
Объекты — замыкания для бедных
V>Ну а про классы типов я тебе уже говорил — тоже позднее заимствование (хоть ты старательно игноришь неудобные аргументы). Это же натуральный контракт, который в ООП есть кортеж обязательных методов, а в ФП кортеж обязательных ф-ий (тоже почему-то называемых методами в Хаскеле)... то бишь, ф-ий над аргументом некоего типа, проводя аналогию в ООП — подаваемого как this.
напомни, откуда в свою очередь позаимствовали LISP-атомы
Здравствуйте, samius, Вы писали:
I>>Легко, фп — вычислительные задачи "унутре" метода которые, кроме того, не требуют изменяемого состояния и всяких числодробилок. S>Если ты решил не пускать ФП дальше нутра метода объекта, то это границы не ФП, это границы твоего применения ФП.
Покажи как выставить в апи карированую функцию что бы её можно было легко использовать из любого другого доступного языка.
I>>Использование ФП на уровене АПИ пока что возможно только в закрытой нише, вроде Эрланга. S>В закрытой от ООП языков что ли?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Если ты решил не пускать ФП дальше нутра метода объекта, то это границы не ФП, это границы твоего применения ФП.
I>Покажи как выставить в апи карированую функцию что бы её можно было легко использовать из любого другого доступного языка.
внезапно с помощью декаррирования.
S>>В закрытой от ООП языков что ли?
I>В закрытой вообще от других языков. см выше.
Закрытость от других языков — слишком сильное утверждение.
Здравствуйте, samius, Вы писали:
I>>Покажи как выставить в апи карированую функцию что бы её можно было легко использовать из любого другого доступного языка. S>внезапно с помощью декаррирования.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
I>>>Покажи как выставить в апи карированую функцию что бы её можно было легко использовать из любого другого доступного языка. S>>внезапно с помощью декаррирования.
I>Покажи пример. А как быть с вариантами ?
uncurr:: (a -> b -> c) -> (a,b) -> c
uncurr f = \(a,b) -> f a b
f' = uncurr f
Здравствуйте, elmal, Вы писали:
SV.>>Давайте сделаем так. Приведите в пример не-ОО кусок API вашего продукта (можно воображаемого), который яснее, чем ОО, и мы продолжим с этой точки. E>
E>public class NotNullUtils {
E> public static <T> List<T> processNull(List<T> list) {
E> if (list == null) {
E> return new ArrayList<T>();
E> }
E> return list;
E> }
E> public static String processNull(String string) {
E> if (string == null) {
E> return"";
E> }
E> return string;
E> }
E>...
E>
E>Пожалуйста. Набор статических функций без какого либо состояния, которыми очень часто пользуюсь.
Я, наверное, плохо выразился. Ваш продукт что делает? Кучку разрозненных сервисов типа проверки на null предоставляет? Или что-то полезное? Это та же дверь и корова, извиняюсь за выражение (см. ниже по ветке).
P.S.
public static string SafeToString(this object o)
{
return o == null ? "" : o.ToString();
}
Здравствуйте, SV., Вы писали:
SV.>Я, наверное, плохо выразился. Ваш продукт что делает? Кучку разрозненных сервисов типа проверки на null предоставляет? Или что-то полезное? Это та же дверь и корова, извиняюсь за выражение (см. ниже по ветке).
Проверка на null (точнее обработка null) — это пример использования не ООП подхода.
Ладно. Другой пример. В проекте все данные хранятся в DTO. Пришел запрос с клиента, этот запрос десериализуется в DTO и путем цепочек преобразований попадает частично в локальный кеш, частично уходит через вебсервисы на сторону. DTO никаких зависимостей на другие классы не содержит, и если там есть логика, то тривиальная.
Запросы идут параллельно много, преобразования тоже идут параллельно. Да, проект представляет собой набор классов, и даже в некоторых случаев наследование там, вот только эти классы все stateless, существуют в единственном экземпляре и хоть и имеет приватные проперти, но они все инициализируются фреймворком, упрощающим dependency injection. SOLID, кстати, в основном соблюдается. Это считаем ОО подходом или нет? Учитывая что объекты не хранят состояния, и если б не были нужны фичи вроде АОП и удобного тестирования, то вообще б по существу там были б сплошные статические методы.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
I>>А с каких пор ООП это именно создавать классы Лужа и Камень ?
LCR>Вот я и говорю, что сначала нужно придумать (кстати, мышление гораздо свободнее ООП, и поэтому у нас хорошие шансы на успех) адекватную модель, затем понять как в терминах этой модели будет выглядеть решение. И я утверждаю, что обычные ООП-шные способы моделирования (выделить базовые сущности, определить взаимодействия) в данном случае не работают. Работают другие техники абстрагирования, такие как векторное поле, дифференциал. И абстракции из вычметодов — сеточная функция, норма, невязка. Ты видел объект "невязка"?
ООП работает там где в __решении__ задачи фигурируют физические объекты. Физический объект он с поведением и со свойствами. Вот здесь ООП работает. Собственно по этому во всех букварях по дизайну говорят, что надо моделировать объекты реального мира, но почему то этот совет понимается именно как генерация классов Лужа и Камень.
Что касается симметричных операторов, то в ООП решением будет введение например сумматора — вполне себе физический объект. И точно так же с задачей про Account и перевод средств между оным естественным образом решение выливается в некоего вычислителя, и это будет TransferService.
С примером как корова ест траву мне бы хотелось увидеть пример реализации в функциональной или какой угодно но парадигме отличной от ООП и я настаиваю на этом.
В ООП же все просто — решение нужно предложить в терминах физических объектов. Например в игрушке, где вместо коровы были медведи и ели они мертвечину, у каждого медведя был метод Act, внутри его была стратегия действия на текущий квант времени — выжидать, караулить, атаковать, искать, есть, защищаться, принимать дамаг, раздавать дамаг, умирать, тухнуть и тд и тд.
То есть всего то решение в конкретных терминах физических объектов и поведения. К слову, Act был почти единственным пабликовым методом.
Например действие есть сводилось к изменению некоторых характеристик поедаемого объекта и своих собственных. Дейтсвие тухнуть это просто генерация эффекта "смрад" который был точнотаким же физическим объектом как и медведь только с другими характеристиками и поведением + модификация собтсвенных характеристики.
Нужно всего то понять простую вещь — ООП(ООД) не даёт ответа на вопрос, какая модель будет наиболее подходящей для задачи и дать в принципе не может. Ровно тоже самое с ФП и любой другой парадигмой. Парадигма дает ответ, как именно выразить конкретное решение в виде кода.
То есть, если решение "медведь ест героя", то это будет this.Eat(World.Hero) а если "к медведю и герою применяется эффект пожирание" то World.EffectsRepository(Effects.Eating).Apply(bear, hero). Ничего странного — сколько решений, столько и моделей и это абсолютно нормально. Может даже так, эгоцентричный или hero-centric подход — все что ни делается делается с героем, тогда hero.devouredBy(bear)
Здравствуйте, samius, Вы писали:
I>>>>Покажи как выставить в апи карированую функцию что бы её можно было легко использовать из любого другого доступного языка. S>>>внезапно с помощью декаррирования.
I>>Покажи пример. А как быть с вариантами ? S>
S>uncurr:: (a -> b -> c) -> (a,b) -> c
S>uncurr f = \(a,b) -> f a b
S>f' = uncurr f
S>
То есть, дополнительные приседания ?
S>А что с вариантами?
Как выставить их из ФЯ что бы удобно было работать в C# ?
Здравствуйте, samius, Вы писали:
V>>Это твои представления об ФП догматичны. А мои об ООП ровно такие, каково состояние дел в ООП прямо на сегодня у лидеров рынка. S>Прям пичалька за рынок взяла
А какие проблемы? Конкуренция абсолютно честна и доступна всем желающим. Покажите сравнимые результаты на "остальных" парадигмах. Но пока что разница в характеристиках на порядок и больше не в пользу "остальных".
V>>Увы, тогда это будет уже скорее ООП. Оно итак испачкано ФП-ой чуть ли не изначально. S>нечистое ФП — это скорее ООП.
Не надоело со сфероконями бодаться? ))
Любое решение не столько от языка зависит, сколько от выбранного человеком подхода к решению задачи. На то она и парадигма. Даже на Хаскеле можно решать задачи в ООП-стиле, эмулируя недостающие в языке вещи. Другой вопрос — нужно ли маяться такой фигней, при наличии более подходящих под ОО-парадигму языков?
V>>Гы, ничего, что сейчас ты показал умение переворачивать всё с ног на голову почище моего? V>>именно способность человека моделировать окружающий мир лежит в идее ООП. Никак не наоборот, ес-но. Ведь это человек назначает объектам роли, то бишь это не происходит "само по себе". S>Способность человека моделировать лежит во всех других идеях ничуть не меньше, чем в ООП.
Объекты реального мира имеют характеристики, состояние и поведение. ООП тупо полностью копирует такой взгляд на вещи. А подход ФП заключается в полном абстракции от всего, включая способ работы вычислителя, на котором работает конечная программа. ИМХО, над излишним усердием в этом направлении я и иронизирую, явно сердя некоторых на этом сайте (судя по реакции). ))
V>>Увы, если брать отдельно взятый функциональный объект — то не в порядке. В порядке там только при наличии состояния. А в чем оно заключается в "чистом ФП" (которое даже без монад) — я тебе уже писал... про стек вычислений и положение указателя команд в потоке исполнения. S>Отдельно взятый функциональный объект ты походу взял из ООП. В ФП я о таких не слышал.
Значит, плохо слушал.
S>Не занимается ФП отдельно взятыми из ООП объектами.
Объект — это не только термин из ООП.
V>>Функциональная декомпозиция выглядит как набор независимых ф-ий. Сравни с иерархией ООП. S>Объекты — замыкания для бедных
Так и есть. Т.е. таки понимаешь, но абзацем раньше клоунадничаешь.
V>>Ну а про классы типов я тебе уже говорил — тоже позднее заимствование (хоть ты старательно игноришь неудобные аргументы). Это же натуральный контракт, который в ООП есть кортеж обязательных методов, а в ФП кортеж обязательных ф-ий (тоже почему-то называемых методами в Хаскеле)... то бишь, ф-ий над аргументом некоего типа, проводя аналогию в ООП — подаваемого как this. S>напомни, откуда в свою очередь позаимствовали LISP-атомы
Да что же за такое???
3-й раз уже этот аргумент про несчастные классы типов скипают.
С вами каши не сваришь. )))
=============
Кстате, полную семантику "атомов" в языках, не только в Лисп, а атк же истоки этого термина и его мутирование с течением времени я же и пояснял на этом сайте несколько лет назад. Если тебе интересно — поиск в руки.
Просто как бы в разное время были написаны интерпретаторы Лиспа на С++ и потом Схемы на дотнете... ))
Мне их внутренняя механика нужна была как p-код для своих DSL. Ну и плюс библиотечный код есть в исходниках. Так что, можешь о механике работы Лиспа задавать любые вопросы... Если догмы не помешают, ес-но.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
I>>>>>Покажи как выставить в апи карированую функцию что бы её можно было легко использовать из любого другого доступного языка. S>>>>внезапно с помощью декаррирования.
I>>>Покажи пример. А как быть с вариантами ? S>>
S>>uncurr:: (a -> b -> c) -> (a,b) -> c
S>>uncurr f = \(a,b) -> f a b
S>>f' = uncurr f
S>>
I>То есть, дополнительные приседания ?
Конечно. Без приседаний ты и "C++" из "C" не вызовешь и тем более C#.
Я думал что ты меня спросил за каррирование. Если тебя интересует именно "интероп" в широком смысле, то ситуация с интеропом конкретно хаскеля не распространяется на все языки функциональной парадигмы. А что бы вызвать функцию из конкретно хаскеля, нужно курить FFI, и декаррирование там не поможет.
S>>А что с вариантами?
I>Как выставить их из ФЯ что бы удобно было работать в C# ?
Опять, смотря в каком языке. В F# и Nemerle они уже выставлены. И работать с ними из C# не менее удобно, чем если бы ты варианты руками выписывал на C#. Ну а раз в C# нет и не предвидится паттерн-матчинга, то работать на C# с этими вариантами будет куда менее удобно, чем на F#/Nemerle.
Вобщем, ты не захочешь объект описывать в C# делегируя его методы в реализации на другом языке. Проще выставить из C# интерфейс и реализовать его в F#/Nemerle, т.к. они для работы с ООП куда более приспособлены, чем C# для работы с ФП
Здравствуйте, samius, Вы писали:
S>>>Так порассуждай и о Логическом программировании в таком же ключе. Получишь что и Логическое выросло из структурного.
V>>Дык, а я и рассуждаю обязательно. Язык — это ведь инструмент, им надо уметь пользоваться. Поэтому факты и правила в Пролог надо понимать в каком порядке подавать, чтобы не получить проседание быстродействия на порядок на ровном месте из-за непонимания работы вычислителя Пролога.
V>>Но ветвления в языке (относящимся к языку, а не расширениям) таки нет. S>В хаскеле тоже нет ветвления в структурном смысле просто потому что язык не описывает выполнение стейтментов и не оперирует побочными эффектами.
Вот та самая догматика. А кто мешает считать, что вычисления в ложных ветках if всё-таки производятся, но потом отбрасываются? Что в итоге у нас получается единственный и неповторимый результат всех вычислений после всех if, это те ветки, которые не были отброшены? А что мешает считать, что если результаты вычисления отбрасываются, то их и не было вовсе? (для Хаскеля так и есть)
Ну и верну тебя в русло: фокус был таки на том, что в конструкциях ПМ и if-then-else, учитывая только что сказанное, можно различить явный порядок вычисления аргументов. Ф-ия-предикат и тела при then-else в любом случае будут упорядочены в своих вычислениях за счет компоновки функциональных объектов и наложенного на эту компоновку механизма ленивости.
Помнишь еще, я как-то спрашивал твое мнение относительно того, почему одна и та же конструкция if-the-else может использоваться как для чистых ф-ий, так и для IO? На тот момент ты еще соглашался, но мне было бы интересно услышать сегодняшнее твоё мнение. Похоже оно чуть трансформировалось. ))
Здравствуйте, Ikemefula, Вы писали:
I>На мой взгляд (подсмотрел в профайлере) ты экономишь около нуля(но справа) ресурсов и для этого создал целую инфраструктуру.
Умножай свой около нуля на порядка 90-150тыщ сообщений в сек. GC ложится навзничь.
I>Итого, п.1 — прояснить не удалось п.2 жостких данных не было, были общие слова
Итого ты мистер-торопыжка. Сам спросил, сам же в своем посте не увидел ответа, сам же распинаешься по этому поводу. ))
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Прям пичалька за рынок взяла
V>А какие проблемы? Конкуренция абсолютно честна и доступна всем желающим. Покажите сравнимые результаты на "остальных" парадигмах. Но пока что разница в характеристиках на порядок и больше не в пользу "остальных".
Я уже отвечал здесь про Автоваз и Китай.
S>>нечистое ФП — это скорее ООП.
V>Не надоело со сфероконями бодаться? ))
Надоело. Завязывай с ними.
V>Любое решение не столько от языка зависит, сколько от выбранного человеком подхода к решению задачи. На то она и парадигма. Даже на Хаскеле можно решать задачи в ООП-стиле, эмулируя недостающие в языке вещи. Другой вопрос — нужно ли маяться такой фигней, при наличии более подходящих под ОО-парадигму языков?
А зачем выбирать ОО-решение, если собираешься писать на ФП языке? Бросай эту фигню. Писать на ОО языке функционально тоже не сахар.
S>>Способность человека моделировать лежит во всех других идеях ничуть не меньше, чем в ООП.
V>Объекты реального мира имеют характеристики, состояние и поведение. ООП тупо полностью копирует такой взгляд на вещи. А подход ФП заключается в полном абстракции от всего, включая способ работы вычислителя, на котором работает конечная программа. ИМХО, над излишним усердием в этом направлении я и иронизирую, явно сердя некоторых на этом сайте (судя по реакции). ))
Мы уже выяснили, что у двери поведения нет. И собственного компьютера (о котором писал Др. Кэй и который принимает сообщения от сквозняка) у двери тоже нет. Так что с копированием ты преувеличиваешь.
S>>Отдельно взятый функциональный объект ты походу взял из ООП. В ФП я о таких не слышал.
V>Значит, плохо слушал.
Возможно
S>>Не занимается ФП отдельно взятыми из ООП объектами.
V>Объект — это не только термин из ООП.
Термин объект из ООП — это только термин объект из ООП. С объектом из реальной жизни он никак не связан, кроме лишь того что призван представлять его в программе.
V>>>Функциональная декомпозиция выглядит как набор независимых ф-ий. Сравни с иерархией ООП. S>>Объекты — замыкания для бедных
V>Так и есть. Т.е. таки понимаешь, но абзацем раньше клоунадничаешь.
а мне кажется что ты клоунадничаешь. И я не одинок в этом.
V>>>Ну а про классы типов я тебе уже говорил — тоже позднее заимствование (хоть ты старательно игноришь неудобные аргументы). Это же натуральный контракт, который в ООП есть кортеж обязательных методов, а в ФП кортеж обязательных ф-ий (тоже почему-то называемых методами в Хаскеле)... то бишь, ф-ий над аргументом некоего типа, проводя аналогию в ООП — подаваемого как this. S>>напомни, откуда в свою очередь позаимствовали LISP-атомы
V>Да что же за такое??? V>3-й раз уже этот аргумент про несчастные классы типов скипают. V>С вами каши не сваришь. )))
Ох, а ты сколько скипаешь... Не пробовал считать?
V>============= V>Кстате, полную семантику "атомов" в языках, не только в Лисп, а атк же истоки этого термина и его мутирование с течением времени я же и пояснял на этом сайте несколько лет назад. Если тебе интересно — поиск в руки.
V>Просто как бы в разное время были написаны интерпретаторы Лиспа на С++ и потом Схемы на дотнете... )) V>Мне их внутренняя механика нужна была как p-код для своих DSL. Ну и плюс библиотечный код есть в исходниках. Так что, можешь о механике работы Лиспа задавать любые вопросы... Если догмы не помешают, ес-но.
Кэй писал что вдохновлялся атомами Лиспа. На самом деле от Лисп-атома до кортежа функций не так далеко. Так что то что хаскель заимствовал классы типов из ООП — ну это немного натянуто, особенно учитывая природу реализаци полиморфизма в нем.
Здравствуйте, vdimas, Вы писали:
I>>На мой взгляд (подсмотрел в профайлере) ты экономишь около нуля(но справа) ресурсов и для этого создал целую инфраструктуру.
V>Умножай свой около нуля на порядка 90-150тыщ сообщений в сек. GC ложится навзничь.
Не ложится Тест в студию, то есть, давай таки не общие слова а жосткие данные.
Если я тебе скажу, что GC выдерживает 20млн инстанцирований в секунду и память не растет вообще, ты сильно удивишься ?
I>>Итого, п.1 — прояснить не удалось п.2 жостких данных не было, были общие слова
V>Итого ты мистер-торопыжка. Сам спросил, сам же в своем посте не увидел ответа, сам же распинаешься по этому поводу. ))
Итого — ты в первом сообщении ничего не выдал, тоьлко общие слова и до сих пор только общие слова.
Здравствуйте, Ikemefula, Вы писали:
V>>Гы, абстракция — это упрощение. V>>Я так всегда считал, что смутное представление о чем-либо — это и есть чрезмерное упрощенное представление, не? I>Нет. Представь себе, что часть дороги накрыл туман. Если тумана нет, дорогая представляется тремя отрезками. А если туман есть, то ...
Насколько сильный туман? ))
Если тумана нет, то на дороге я вижу кучу подробностей, а если есть, то максимум вижу общее направление дороги.
I>>>Вот функциональная декомпозиция I>>>Order(x => x.ABC)
I>>>А вот процедурная
I>>>OrderByHellKnowsWhat
I>>>Надо ли объяснять разницу ?
V>>Ес-но надо. V>>Для начала приведи эквивалентный по функциональности код и там и там.
I>Ну, имя неудачное, так будет яснее OrderByAbc
Так и думал. ))
Все-равно не эквивалент.
Эквиваленты будут такие (исходный пример тоже подрихтую):
Order(listOfX, x => x.ABC)
vs
Order(listOfX, &CompareABC) или Order(listOfX, &ExtractABC), где
bool CompareABC(x, x) или
ABC ExtractABC(x)
V>>Если с наскока не получится — см. мою подсказку насчет того, что есть замыкание. I>Это не важно, что есть замыкание.
Как только выяснилось — важно, эквивалентный пример ты так и не привел.
I>Важно что лямбда позволяет сделать инверсию, а процедурная композиция никакой инверсии не предполагает.
Мде? А qsort в чистом Си видел?
Как эмулируется замыкание — я уже показал. С помощью указанной пары {ф-ия, контекст} можно делать в точности аналогичное на процедурном подходе. Достаточно умения вызывать обычную ф-ию по ссылке.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>В хаскеле тоже нет ветвления в структурном смысле просто потому что язык не описывает выполнение стейтментов и не оперирует побочными эффектами.
V>Вот та самая догматика. А кто мешает считать, что вычисления в ложных ветках if всё-таки производятся, но потом отбрасываются?
Считай, не буду мешать.
V>Что в итоге у нас получается единственный и неповторимый результат всех вычислений после всех if, это те ветки, которые не были отброшены? А что мешает считать, что если результаты вычисления отбрасываются, то их и не было вовсе? (для Хаскеля так и есть)
Тоже можно считать. Только результат if-а очень даже повторимый. Сколько не будешь вычислять с теми же аргументами, получишь то же самое.
V>Ну и верну тебя в русло: фокус был таки на том, что в конструкциях ПМ и if-then-else, учитывая только что сказанное, можно различить явный порядок вычисления аргументов. Ф-ия-предикат и тела при then-else в любом случае будут упорядочены в своих вычислениях за счет компоновки функциональных объектов и наложенного на эту компоновку механизма ленивости.
Дался тебе порядок вычисления чистых выражений. Ты мне побочный эффект покажи, а не порядок вычислений.
V>Помнишь еще, я как-то спрашивал твое мнение относительно того, почему одна и та же конструкция if-the-else может использоваться как для чистых ф-ий, так и для IO? На тот момент ты еще соглашался, но мне было бы интересно услышать сегодняшнее твоё мнение. Похоже оно чуть трансформировалось. ))
Не помню что ты спрашивал, но отвечу.
Любые допустимые взаимодействия с IO a кроме unsafePerformIO и подобных ему не делают побочных эффектов. Потому, если ты решил скомбинировать IO a в ветке if-а, то никакого криминала в этом нет. Особенно учитывая то, что if не выполняет ветки, а просто их возвращает.
Тест в студию, то есть, давай таки не общие слова а жосткие данные.