Vladislav
Плагином как ты себе это представляешь?
Alexander
кстати у тебя через Here|There?
Vladislav
Да
Vladislav
Правда я их назвал This и That
Vladislav
ну вон же в примере на матчинг preview, на конструкцию review
Зигохистоморфный
Зигохистоморфный
В секции where как раз на конструкцию?
Vladislav
Да
Зигохистоморфный
Ну по сути как то можно было заменить на Viewpatterns в матчинг
Vladislav
Там и есть ViewPatterns в синониме
Зигохистоморфный
Точно
Зигохистоморфный
Проглядел
Alexander
ну viewpattern напрочь убивают exhaustiveness analysis
Alexander
мне интересно возможно ли без большого количества indirection сеты делать
Alexander
но вроде никак т.е. Int не индуктивный
Igor
Третий день Хаскель ковыряю, и пока еще сильно плаваю. У меня вопрос: как по-человечески пишется что-то вроде mapM_ (\f -> readFile f >>= putStr) files?
Дима
https://t.me/haskell_learn
Igor
https://t.me/haskell_learn
Спасибо! А тут только серьезные вопросы обсуждаем? 🤔
Kirill
не особо
Kirill
а по вопросу вроде нормально "императивненько" записывается через forM_ files $ \f -> do{ contents <- readFile f; putStr contents}
Алексей
mapM (putStr <=< readFile) files
Алексей
Да
Igor
Из обоих чатов я понял, что forM_ + do привычнее. За <=< спасибо! Именно то, что искал.
Антон
Линзы — да, вещь удобная, но, во-первых, требуют TH, во-вторых, ломают вывод типов
Антон
> с этим бывают проблемы, кстати. В развесистом линзокоде у меня такое бывало - сделал s/$/./ и перестало чекаться ибо стало слишком полиморфно Есть пропозал для GHC разрешить do в позиции аргументов. В этом случае можно будет, в частности, отменить специальное правило типизации $
Aleksei (astynax)
TH необязателен - можно руками писать все линзы. Вывод типов с линзами обычно работает наоборот: знаешь, что что-то эдакое в линзах можно, пишешь сигнатуру и дальше жогглируешь traversed и прочим, пока не соёдется :)
A64m
отменить нельзя будет, никто код без $ переписывать не станет
Зигохистоморфный
Leonid 🦇
https://github.com/haskell/ecosystem-proposals/pull/6 чёт не холиварят
Alexander
наконец-то толково написали
Alexander
хотя и перемудрили
Anatolii
а ghcid не может поломаться из-за template-haskell?
Anatolii
stack ghci нормально загружается
Anatolii
а ghcid игнорит 2 модуля с persistent декларациями
Anatolii
может -fno-code виновен?
Dmitrii
а ghcid не может поломаться из-за template-haskell?
Может. Именно из-за этого и ломается скорей всего. Есть открытое issue: https://github.com/ndmitchell/ghcid/issues/101
Anatolii
ну я решил также проблему как в issue
Donat
для ghc ничего вроде distcc ещё не придумали?
Alexander
нет вроде
Donat
нагуглил несколько очень древних постов в которых обсуждение затихло после пары постов
Donat
видимо, никто не осилил...
Евгений
@qnikst выше
Alexander
+
Антон
Поругайте кот, пожалуйста: shiftedZipWith f vec = enumFromTo 0 (len-1) & map index &&& map (index . (`rem` len) . (+1)) & uncurry (zipWith f) where len = V.length vec index = (vec V.!) shiftedSum = shiftedZipWith (+) shiftedFSub = shiftedZipWith (flip (-)) polygonArea = curry $ (/2) . fromIntegral . abs . sum . uncurry (zipWith (*)) . (***) shiftedSum shiftedFSub
Aleksei (astynax)
Опять же, зачем flip (-), если можно сменить порядок прямо в shiftedZipWith, если уж для shiftedSum ничего не изменится (ибо (+) коммутативен)
Aleksei (astynax)
Опять же & не то чтобы чаcто используется, гораздо чаще встречается $. Иначе слишком часто придётся менять направление чтения - композиция то читается справа-налево в той же polygonArea
Aleksei (astynax)
shiftedZipWith f vec = V.zipWith f vec shiftedVec where shiftedVec = V.snoc (V.tail vec) (V.head vec)
Cheese
(&) и flip — ерунда по сравнению с enumFromTo, (&&&) и uncurry. когда кто-то из них встречается, здесь, вероятно, что-то переусложнено
Anonymous
Aslm
Антон
Или кто-то заюзал сервис pointfree
Не-не, всё вручную писал
Антон
shiftedZipWith f vec = V.zipWith f vec shiftedVec where shiftedVec = V.snoc (V.tail vec) (V.head vec)
Это да, но конкатенация векторов - это О(n), а мне хочется поэффективнее. Индексацией напрямую можно получить то же самое, но без конкатенации
Aleksei (astynax)
Нет конкатенации векторов, есть snoc
Aleksei (astynax)
К тому же n запросов по индексу, это та же сложность, не?
Aleksei (astynax)
Так zipWith все равно в обоих вариантах есть
Aleksei (astynax)
В любом случае это не то место чтобы оптимизировать, да и не тот способ
Anonymous
Hello
Влод
Hello
👋
Oleg
Не знаю, пофиксили ли, но встречал и испытывал на себе, что uncurry не лучший выбор в плане для перфоманса иногда https://stackoverflow.com/a/38440296/210905
Anonymous
Hy
Cheese
кстати, о денотационной семантике. где-нибудь есть достаточно официальный документ, в котором было бы достаточно полно написано, что должна делать каждая функция из Prelude, например?
Anonymous
Hello my frend
Leonid 🦇
https://twitter.com/jyothsnasrin/status/957595543194165249 А вы говорите ета не развивается
Sergey
Всем привет, делаю сжатие хаффмана, можете подсказать идею, как записать в файл полученныую последовательность битов?
Cheese
Упаковать в байты и потом Data.ByteString.writeFile
Sergey
так, хорошо, а сами биты использовать Data.Bits?
Sergey
и последний момент. Допустим получилось следующее: 1110001110 Тут получается 1 байт + 2 бита. Как с таким быть? Если сформируется байт 10000000, как его потом правильно раскодировать?
Anonymous
Byte - это Word8, не?
Cheese
ну, про нецелые байты — это вопрос вообще не про Хаскель, а про основы CS
Cheese
Byte - это Word8, не?
один из вариантов
Cheese
Word8 — один из вариантов представления байта в Хаскеле
Anonymous
[Word8] -> ByteString Очень просто, "без шума и пыли"
Sergey
окей, спасибо, буду разбираться
Anonymous
Data.Bits, Word8, ByteString Должно хватить