И снова ООП и ФП.

b - это построитель. В интернете ты, наверное, уже видел один пример построителя: это async. Построитель и определяет то, как задается вычисление.

Ага. Я как понял, каждый builder соответствует одной монаде. Просто в этом контексте не совсем понятно семантически как переводить на скалу - там ведь нету builder-переменной.

А вообще в do-нотацию это, получается, не вписывается. В хаскельной аналог такого while (который будет вызываться внутри do-нотации) тоже не получишь, т.к. тут между строками внутри {} выражения, выходит, должны выполняться обычным, линейным способом, а не через монадическое связывание.

А вообще концепция виртуализации языка на computation expressions весьма похожа.

Как уже говорили выше, просто выучи Java и попробуй написать на ней что-нибудь

Есть ли годная книга по тому, как разрабатывать Ъ ООП способом, с задачками/решениями, а не просто описанием паттернов и нескольких составных паттернов?

Вся суть Ъ-ООП-мышления - это, по сути дела, умение программировать в функциональном стиле в рамках всех тех ограничений, которые накладывают псевдо-ООП языки.

очень суровая реальность потребует от тебя знания 1С и бухгалтерии, ага

Программирование в целом и есть раскладывание вещей по полкам.

Есть ли годная книга по тому, как разрабатывать Ъ ООП способом

Smalltalk BlueBook, книжки Бертрана Мейера, всякие Art of Metaobject Protocol

Ну у нас в компании, например, активно ocaml юзают. И его первую букву тоже.

Что тебя смущает? В ocaml есть обобщенные типы.

let rec map l f = if l = []
                    then []
                    else f (List.hd l) :: map (List.tl l) f;;

Программирование в целом и есть раскладывание вещей по полкам.

Боюсь, я не понял аллегории. Я бы сказал, что программирование - выстраивание некой логики (внутри определенных фреймов, паттернов), но вот чтобы логику называть раскладыванием вещей по полочкам - я, увы, этого не понимаю.

Сейчас программирование — это гораздо в большей степени «структуры данных», чем «алгоритмы».

Построитель в F# соответствует одной монаде (как async) или одному моноиду (как seq). В Scala можно было бы пихнуть все методы построителя в сам тип монады подобно flatMap, но мне совершенно не нравится такой подход (как и коллекции в Scala).

В хаскеле будет комбинатор для while. Там это нормально.

И как раз внутри while {} выражение тоже будет монадическим (или моноидом). Там тоже идет преобразование. Поэтому в моем примере «cexpr» заключены в кавычки. Это значит, что они подвергаются преобразованию.

Возможно, что так будет понятнее.

Конструкция while преобразуется в вызов метода While построителя.

В случае монады ожидается, что метод While имеет следующую сигнатуру:

member While:
(unit -> bool) * Result<unit> ->
Result<unit>

В случае моноида ожидаемая сигнатура будет другой:

member While:
(unit -> bool) * Result<'a> ->
Result<'a>

В хаскеле будет комбинатор для while.

Можно и в скале сделать комбинатор для while тогда, определив его как в хаскеле.

unit -> bool

Правильно я понимаю, что в нормальных языках этот бессмысленный тип выглядит как IO Bool?

Можно, но в плагине продолжений Scala поддерживают именно ключевые слова while, try-catch и try-finally. Получается бардак.

Плюс не забывай о фейковой переменной, поскольку там тип результата while будет Result[Unit] - мы это уже проходили выше по треду.

Так, сколько тебе лет?

как от этого зависит ответ? Ну, допустим, 11.

Тогда определение «нормального языка» в студию.

В которых результат функции может зависеть только от аргументов.

В хаскеле будет просто Bool. Там нету никакого IO и функция чистая, просто навернута санка вокруг вычисления.

А ты дебил, да, забыл добавить.

Все же IO Bool. While имеет смысл для императивной монады, где есть liftIO.

Ок, а почему тип некаррированный?

Вероятно, для того, чтобы можно было использовать из C#. Он в отличие от F# не поддерживает другие, как ты сказал, «каррированные» методы.

В которых результат функции может зависеть только от аргументов.

Только что прочитал сообщение одного упоротого напрочь эрлангиста. Могу сказать, что про упоротость некоторых хаскелистов уже давно можно слагать легенды. Это при том, что мне самому нравится хаскель, и я даже научился его успешно использовать.

fix $ \r p m -> p >>= (`when` (m >> r p m)) — выводится Monad m => m Bool -> m a -> m (), странно, что нет в base, хотя well-known.

Интересное использование комбинатора fix. Надо будет взять на заметку :)

А у него разве еще какое-то есть кроме продемонстрированного?

Надо бы p и m за fix вынести:

\p a -> fix $ \r -> p >>= (`when` (a >> r))

или через mfix (для функций):

\p a -> mfix (\r _ -> p >>= (`when` (a >> r))) ()

а учитывая http://www.haskell.org/haskellwiki/MonadFix — можно так же через RecursiveDo или mdo

\p a -> (do { rec { r <- \_ -> p >>= (`when` (a >> r)) }; return r }) ()

\p a -> (mdo { r <- \_ -> p >>= (`when` (a >> r)); return r }) ()

Ага, вот за это я и не люблю хаскелистов: как простое и очевидное сделать сложным и запутанным?

Если брать на заметку fix, то про mfix и mdo с RecursiveDo (тем более ты про него уже писал на ЛОРе) просто нельзя не сказать :)

А вообще это чтобы кинуть в ghci и посмотреть тип, реально нужно и Monad m => m a -> (a -> m Bool) -> (a -> m b) -> m (), и с нормальным кодом (надо бы посмотреть отличается ли core у «нормального кода» и кода с fix). То есть это не только IO или MonadIO (те же free monads над функторами, именно — ADT для eDSL в котором while имеет смысл и который будет превращаться в монадический с помощью Free, так что while заработает тоже for free, а IO или трансформер над IO вообще не при делах кроме как тип результата функций интерпретации или компиляции этого Free eDSL).

Да я пошутил :)

Тем не менее, есть у некоторых хаскелистов тяга к переусложнению (безточечный стиль и тому подобное). Даже hlint иногда такую фигню советует, что я отказался о его использования.