ничем не хуже yaml

а местами и получше

@kana_sama какие проблемы у .cabal?

как у формата

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

ставь везде

оно так работает

вообще там обязательно её ставить в зависимостях, т.к. без , могут быть сложности с парсеньем

стоит ставит stack?

или есть лучшие способы менеджмента хаскель-проектов?

стоит ставит stack?

да

stack проще особенно для начала

конечно в последнее время он нифига не развивается, там проявляется куча багов, но интерфейс гораздо более простой и понятный

чаще выполняется принцип of the least surprise

а есть что на подходе?

нет

cabal-install есть ещё

он сейчас пошустрее развивается и там больше фич

или есть лучшие способы менеджмента хаскель-проектов?

лучше есть, проще - нет

но там инопланетянский интерфейс

cabal-install есть ещё

А что, проблему cabal hell уже решили?

Да

В 2.0

её решили лет я даже не знаю сколько назад

(при помощи nix :peka:)

у меня в генте её и не было, на nix её не было, в cabal-dev её не было, с cabal sandbox её не было, в cabal-2.0 вообще хорошо

cabal-dev появился, когда я ещё начинал haskell-ем увлекаться, в cabal-install оно тоже уже лет 5 как приехало

ну как не было, можно было получить cabal hell, но если делать глупости

типа все ставить через cabal install в глобально

с сендбоксами только замучаешься компилировать

уж начинающий с 256 игрушечными проектами точно устанет линзы компилировать

Линзы не нужны, геттеров с префиксами достаточно :yoba:

можно ж шарить было сендбоксы

да, для этого и костыли были специальные, но не начинающему.

ну да, у стека более человеческий апи и был и остаётся

тому надо и так 10 раз через обруч прыгнуть чтоб сендбокс заработал, а не из глобальной базы все было

ну я уже с питоном и его пипами игрался

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

ну тет хотя бы механизм внутри один

*тут

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

(надеюсь это была не контрольная в универе..)

Нет, это была не контрольная, это одна из домашек по ФП, я по-своему решил, если что) мне очень помогла функция repicateM за нее еще раз спасибо

ну хоть по своему :)

я там выше ошибся немного, у меня как-то так получилось: import Data.List import Control.Monad solve n = id $ length $ filter and $ filter (not.null) $ map (\t -> zipWith3 (\a b c -> not a || not b || c) t (drop 1 t) (drop 2 t)) $ replicateM n [True,False]

вроде даже лишнего не должно аллоцироваться особо

а не, аллоцирует :/

на -O0

я потом обязательно погляжу решение) потому что мое подлиннее вроде вышло) countSolution :: Int -> Int countSolution n | n < 3 = error "n must be >= 3" | otherwise = length [solve | solve <- replicateM n [True, False], isSolve solve] isSolve :: [Bool] -> Bool isSolve (x:y:z:xs) | null xs = boolResult | otherwise = boolResult && isSolve (y:z:xs) where boolResult = not x || not y || z я на haskell всего неделю прогаю, полегче только благодаря прологу)

ФЯ 90-х | comp | VM | t | | --------------------- | --------------- | ------ | | ghc 8.2.2 (O2) llvm 6 | stg ghc x64 | 7 | | clean | abc | 40 | | ocaml 4.04 flambda O3 | | 72 | против ФЯ 2010-х | idris 0.99 | | 54308 | | purescript 0.11.4 | node v7.10.0 V8 | 128369 |

поразительный прогресс в избегании успеха, конечно

а что за t ?

время в секундах

количество секунд

результат паразительный конечно

я когда начал разные имплементации ФЯ бенчмаркать, думал разница будет порядка три. К такому меня жизнь не готовила

а что это за бенчмарк?

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

Интересно, что окамл в 10 раз медленнее хаскелл оказался

Интересно, что окамл в 10 раз медленнее хаскелл оказался

во первых, там авторы библиотеки ленивых списков чего-то перемудрили, я писал "наивный" код который где-то в два раза быстрее. Во вторых фьюжена нету, но и без фьюжена хаскель будет 20, мои ленивые списки на окамле 40, разница в два раза остающаяся - простая имплементация ленивости в окамле против СТГ. Так что тут все понятно более-менее

с идрисом тоже понятно, там Lazy не записывает вычисления а перевычисляет всякий раз заново, так что там асимптотика хуже

но это не случай пурскрипта. там лази как в окамле, а не как в идрисе: exports.defer = function () { function Defer(thunk) { if (this instanceof Defer) { this.thunk = thunk; return this; } else { return new Defer(thunk); } } Defer.prototype.force = function () { var value = this.thunk(); this.thunk = null; this.force = function () { return value; }; return value; }; return Defer; }();

надо будет на пурскрипте наивную имплементацию написать

а что это за бенчмарк?

primes = 2:3:filter isPrime [5,7..] :: [Int] isPrime x = all (/= 0) . map (rem x) . takeWhile ((<= x) . (^2)) $ primes main = print . length . takeWhile (<= 2^24) $ primes

ох уж эти синтетические бенчмарки

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

ERROR: S client not available

тут ФЯ в разы и на порядки отличаются и главное обычно понятно почему

как в этом вашем стеке сделать cabal init?

я делаю так: > package.yaml

sh-4.4$ cabal init cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).

@cblp_su и что оно зависимости с все other-extensions оно за тебя заполняет:

?

нет, это stack init, наверное, делает

зависимости я руками заполняю. зачем это автоматизировать?

stack init ничего не делает

оно ругается что stack init сделан выше

зависимости я руками заполняю. зачем это автоматизировать?

за тем, что я не хочу руками выписывать все пакеты откуда у меня импортированы модули

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

и вообще как пользователи hpack могут спрашивать зачем что-то автоматизировать

если пользуешься системой, которая автоматизирует все подряд (типа exposed/other-modules выписывания), то вопрос почему кто-то хочет что-то автоматизировать возникать не должен

хочет и все

вообще, в stack script есть гадалка по пакетам, но не уверен, что они её вроде ещё не встроили в другие места

а cabal init уже умеет гадать на пакетах?

поидее stack exec --no-ghc-package-path -- cabal init should work

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

и вставлять это в build-dependencies

в общем-то это даже ghc умеет делать, т.к. ему это нужно чтобы ghci/ghc работало

гадать на пакетах

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

вспомни что делает ghc в этом случае

у тебя локально есть список модулей со всего хакаджа?

ты мне хочешь доказать что автоматизация плохо?

не трать время

я считаю, что хорошо, а corner cases я разрулю руками

ок

согласен

поидее stack exec --no-ghc-package-path -- cabal init should work

сработало?

неа