да и вообще, fix может быть выражен через полную рекурсию

"хорошем" = оптимизатор справился

это я про hylo

если есть control structure, то логично по ней рекурсию делать

а список это нормальный control structure

если же структуры для рекурсии нету и мы не порождаем контрольную структуру на выходе, но анонимная рекурсия - разумный выбор

если мы порождаем контрольную структуру, то unfold* для этой структуры может быть понятнее

кстати foo = loop where loop = ... вместо fix мне не нравится, обычно его не документируют нормально + легче словить лик

особенно если там строков больше

А какой лик там можно словить?

я повторю свое утверждение, если вдруг я увижу код, который по моему внутренему чувству стиля становится лучше за счет его использования, я ничего против fix иметь не буду

Ну вот код. Надо пачками загружать данные в БД: bracket (R.open dbFile defOptions) R.close (\db -> do cont <- mmapFileByteString inputFn Nothing let batchOps = map (uncurry R.Put . second B.tail . B.span (/=',')) $ B.lines cont fix (\f i batches -> do let (before,after) = splitAt batchSize batches R.write db def before unless (null after) $ do print i f (i + batchSize) after ) 0 batchOps )

Заводить ради этого функцию как-то не очень...

вот тут, кстати, согласен

выше 2 примера об этом были

вот тут типа unfold лучше будет?

попробовал одну из функций переписать

один из них правда через forver / loopWhile можно переписать

@kana_sama я бы через unfold писал

я просто не вижу что стало луше в примере выше

врочем и что стало сильно хуже не вижу

если функция большая то ты не знаешь что написано в where тебе нужно смотреть вниз/скроллить

если функция большая это проблема функции

при этом если функция используется только 1 раз, то это не помогает

вон выше 7 строк

скролл = 20 строк

я про перевод взгляда не зря сказал

т.е. тебе нужно отвлечься от flow фукнкции и смотреть в другое место

когда же ты смотришь на where - обратная ситуация - неясно где и почему и сколько раз используется

если описание flow функции занимает 7 строк то это тоже стремно

в идеале описание flow сводится к композиции правильно подобранных фрагментов

:/

вот выше не так?

fix (\f -> recv >>= \case -- for some reason creating a sheet returns a 'SetOpenedWorkbook' rather -- than 'SetOpenedSheet' WsAPI.SetOpenedWorkbook ow -> case API.openedSheet ow <|> fmap API._sheetId (listToMaybe (API.openedWorkbookSheets ow)) of Nothing -> throwM $ userError "No sheet in workbook!" Just x -> pure x _ -> f) хотя бы так

ты про этот фрагмент?

нет, @dmalkr ; но тот выше тоже подойдёт

а по коду крылова у меня претензий и не было

достаточно чистый код в котором анонимная рекурсия оправдана

хотя имхо лучше бы выглядел ленивый список батчей которые потом заливаются в бд^$ а там он и есть

Ну да, чуть компактнее было бы.

там список, но не батчей

переписал на unfoldr)

catMaybes понадобился из-за того, что в unfoldr нельзя пропустить отдачу результата шага (то есть просто дальше анфолдить не добавляя ничего)

кстати, мне кажется хелпер который лениво превращает список в список списков ограниченной длины достаточно удобная штука

Вообще?

Или в данной задаче?

вообще

Есть же Data.List.Split, там этих нарезальщиков полно

ну тогда можно было бы его использовать вместо рекурсивного обхода

я по библиотекам плаваю поэтому был не в курсе

да, в split все есть

я по библиотекам плаваю поэтому был не в курсе

морской волк в библиотеках?

адмирал "никогда не работал в команде"

ну тогда можно было бы его использовать вместо рекурсивного обхода

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

streamTraverseKeys (Transaction txn) edb = do (cursorKey, cur) <- lift $ allocate mdb_cursor_openX mdb_cursor_close (keyKey, pkey) <- lift $ allocate calloc free (valKey, pval) <- lift $ allocate calloc free fix (\f cursOp -> do result <- liftIO $ mdb_cursor_get cursOp cur pkey pval when result $ do yieldKey pkey f MDB_NEXT_NODUP ) MDB_FIRST release valKey release keyKey release cursorKey where mdb_cursor_openX = mdb_cursor_open txn (getMdbDBI edb) yieldKey pkey = liftIO (peek >=> mdbValToByteString $ pkey) >>= Stream.yield кстати, вот это что у меня было с fix

требования к чистоте кода в экспериментах примерно на нуле :)

и fix мне нравится гораздо больше чем loopWhile и прочие монстры из monad-loops и т.п. которые придётся или использовать или переизобретать

которые тоже самое делают

окей, с fix вы меня переубедили

да, что важно, этих кейсов _мало_

т.е. грубо говоря в проекте на 20к+ строк из у меня 2

причем первым случаем я могу согласиться, что он там не обязателен, в общем не я его написал, я потил 0 времени на понимание, то почему бы и нет

у меня по жизни есть проблема с тем, что из того что я что то понимаю не следует что это понимают другие

веб-разработка, много джунов

поэтому осторожничаю

это логично

но вообще fix можно рассматривать как паттерн типа applicative

f <$> a <*> b <*> c - как работают понимают не все, но поняв что делает могут пользоваться и видеть его

или join $ atomicaly (более редкий), да и вообще join

собственно, я не встречал ни одного человека, который бы сходу понял как работает Y-комбинатор, но fix сравнительно понятен

с другой стороны, людей которые каждый факториал пишут как point-free fix я недолюбливаю

с этим соглашусь

ну вообще чтобы понять Y надо сначала проредуцировать на бумажке (\x -> x x) (\x -> x x) что есть база для рекурсии в ЛИ

я пробовал, не помогло

тогда у меня плохие новости)

ну хаскель тоже не может сам тип вывести

ну хаскель тоже не может сам тип вывести

ну а при чем тут хаскелль? это же ЛИ

ну хаскель тоже не может сам тип вывести

могу еще посоветовать такую кату https://www.codewars.com/kata/5443dd2d7fc4478154000ac6

так я понимаю как fix работает

я не понимаю почему

ну хаскель тоже не может сам тип вывести

так Ω и не имеет типа

где-то примерно тут https://youtu.be/7BPQ-gpXKt4?t=49m13s были эти слова