Да

включил в фаерфоксе костыль, который все делает черным-черным только так смог различить по цвету посещенную и непосещенную ссылку на хекедже

Зачем? Ставишь stylish и там для хакаджа a:visited { color: #000000; //или какой там цвет нужен }

Кстати, return или pure?

Теорема Эскобара

Зачем? Ставишь stylish и там для хакаджа a:visited { color: #000000; //или какой там цвет нужен }

да, если так дальше пойдет - мастхэв плагин будет

Кстати, return или pure?

Только pure

Кстати, return или pure?

в апликативных выражениях pure в do нотации return

pure эффективнее на две буквы

Но зачем в do-нотации return, если pure и чище, и семантически ближе?

pure эффективнее на две буквы

Две сэкономленные буквы этому господину

Семантически они оба хрень какая-то на постном масле, а pure еще и не прилагательное. Но зато он на две буквы короче и поэтому победил.

А ещё он новичков не путает

да какая разница, при наборе все набирается тремя буквами, а читается все одним куском

А что с этим можно сделать?

Нужно писать servant-cli, как у жсеров

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

pure кстати мне не оч

а теперь мы создадим эффект с помощью pure

ня!

вообще вместо return надо монад компрехеншоны использовать, а вместо pure идиом брекеты

а теперь мы создадим эффект с помощью pure

так наоборот он же означает "для этого параметра без эффектов"

ну он говорит, что его параметр без эффектов

отличнненько

т.е. в рамках аппликативной гусеницы он логичен

ну да

а что за монад компрехеншоны? %) upd: загуглил https://ncatlab.org/nlab/files/WadlerMonads.pdf

Воу-воу, откуда такая любовь к return? Он вводит в заблуждение новичков. Встречаешь ты такой return в середине do-блока, и думаешь: тут, что, функция завершается, что ли

@dshevchenko ты отстаешь от bravit на 300 твитов, это где-то чуть больше, чем ты написал. без темы про гендеры не обойтись будет..

μ выигрывает и по длине и по семантике

только требует конфиг редактора или оси

а что за монад компрехеншоны? %) upd: загуглил https://ncatlab.org/nlab/files/WadlerMonads.pdf

тот же Вадлер вроде)

а так да

только требует конфиг редактора или оси

нет, если ты - грек

т.е. ещё по национальности ограничения?

Национализм в Хаскелле

интерсно, а кто-нить реально будет читать код проекта irc-simple

надо потом незаметно поменять текстовый протокол на protobuf убрать часть логики privmsg и сделать pub-sub сервисом, non-persistent

@A64m_qb0 https://mpickering.github.io/posts/2018-03-20-recordsvstypeclasses.html https://github.com/mpickering/rtcwrao-benchmarks

нам как раз такой нужен

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

Привет!

Я слышал что вы тут новис френдли

И у меня соответсвенно вопрос

Куда прописывать зависимость сервента

В кабал или стак?

В кабал, если используешь версию из снапшота, в стак в противном случае

в кабал в любом случае, если нету в снапшоте, то еще и в стек

Где можно почитать почему так

????

Ну или если не сложно объясните тут пожалуйста

в документации стака

там правда обновили уже инфу до hpack

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

https://docs.haskellstack.org/en/stable/stack_yaml_vs_cabal_package_file/#why-specify-deps-twice

а если кто-то использует package.yaml, он обречён на что-то?

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

а если кто-то использует package.yaml, он обречён на что-то?

это описания для генератора кабалового файла

со всеми понятными последствиями

Ага

Кажется я понял

И еще один вопрос

Где лучше указывать зависимости? В library или executable?

их и там и там надо указывать, это отдельные списки зависимостей

То есть

У меня есть зависимость

И я должен тянуть её и туда и туда?

указать надо и там, и там

а тянуть - один раз

Хм

Это несколько необычно

А почему так?

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

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

в каждом из таргетов

если library и executable - в обоих

если только один, то только в одном

Спасибо:)

Где лучше указывать зависимости? В library или executable?

если зависимость для кода в src, то library, если для app, то executable, это же разные списки для разных мест

WARNING: /mnt/d/Programming/Haskell/LKP/LKPBACK/LKPBACK.cabal was modified manually. Ignoring package.yaml in favor of cabal file. If you want to use package.yaml instead of the cabal file, then please delete the cabal file.

Я немного не понял

почему оно ругается