в пакет мне

https://github.com/int-index/union/issues/8

И матчить так: case u of OU1 a -> ... OU2 b -> ... OU3 c -> ...

А еще можно поэкспериментировать с type-indexed паттернами, чтобы было вроде case u of OU (a :: Integer) -> ... OU (b :: Bool) -> ... OU (c :: Char) -> ...

Правда мне кажется, что с exhaustiveness-чекером тут не договоришься

А еще можно поэкспериментировать с type-indexed паттернами, чтобы было вроде case u of OU (a :: Integer) -> ... OU (b :: Bool) -> ... OU (c :: Char) -> ...

Вот сейчас меня пробило, а что, так можно что-ли? Мне почему-то всю жизнь казалось, что ghc не хранит метки типов в рантайме.

Не хранит

Но там не просто так OU написано :)

Правда мне кажется, что с exhaustiveness-чекером тут не договоришься

100% не договоришься

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

В общем я сделал OU, а не exhaustiveness придется забить

pattern OU :: UElem a as (RIndex a as) => a -> OpenUnion as pattern OU a <- (preview openUnion -> Just a) where OU a = review openUnion a

Блин, бенчмарки не работают почему-то

Benchmark bench: RUNNING... benchmarking openUnion matching 1st time 4.897 ns (4.892 ns .. 4.905 ns) bench: <stdout>: commitBuffer: invalid argument (invalid character) 1.000 RBenchmark bench: ERROR

что это вообще такое

ТН могло бы помочь

С чем?

Ты предлагаешь каждый кейс генерить?

т.е. если у тебя есть split возвращающий элемент или сет без этого типа

Есть такой, да

тогда вложенные матчи чнкаются

pattern OU :: UElem a as (RIndex a as) => a -> OpenUnion as pattern OU a <- (preview openUnion -> Just a) where OU a = review openUnion a

всегда интересовало, почему pattern, а потом еще и where?

но писать это руками не хочется

чтобы разный код на матчинг/конструкцию

но писать это руками не хочется

Надо попробовать а-ля total

так вот с помощью ТН можно было бы переводить у удобную форму ну или плагином

Плагином как ты себе это представляешь?

кстати у тебя через Here|There?

Да

Правда я их назвал This и That

чтобы разный код на матчинг/конструкцию

Это как?

ну вон же в примере на матчинг preview, на конструкцию review

ну вон же в примере на матчинг preview, на конструкцию review

А это как матчинг и упаковка некая

В секции where как раз на конструкцию?

Да

Ну по сути как то можно было заменить на Viewpatterns в матчинг

Там и есть ViewPatterns в синониме

Точно

Проглядел

ну viewpattern напрочь убивают exhaustiveness analysis

мне интересно возможно ли без большого количества indirection сеты делать

но вроде никак т.е. Int не индуктивный

Третий день Хаскель ковыряю, и пока еще сильно плаваю. У меня вопрос: как по-человечески пишется что-то вроде mapM_ (\f -> readFile f >>= putStr) files?

https://t.me/haskell_learn

https://t.me/haskell_learn

Спасибо! А тут только серьезные вопросы обсуждаем? ?

не особо

а по вопросу вроде нормально "императивненько" записывается через forM_ files $ \f -> do{ contents <- readFile f; putStr contents}

mapM (putStr <=< readFile) files

mapM (putStr <=< readFile) files

s/mapM/mapM_

Да

Из обоих чатов я понял, что forM_ + do привычнее. За <=< спасибо! Именно то, что искал.

Линзы — да, вещь удобная, но, во-первых, требуют TH, во-вторых, ломают вывод типов

> с этим бывают проблемы, кстати. В развесистом линзокоде у меня такое бывало - сделал s/$/./ и перестало чекаться ибо стало слишком полиморфно Есть пропозал для GHC разрешить do в позиции аргументов. В этом случае можно будет, в частности, отменить специальное правило типизации $

TH необязателен - можно руками писать все линзы. Вывод типов с линзами обычно работает наоборот: знаешь, что что-то эдакое в линзах можно, пишешь сигнатуру и дальше жогглируешь traversed и прочим, пока не соёдется :)

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

ну viewpattern напрочь убивают exhaustiveness analysis

Зато в них есть удобство

https://github.com/haskell/ecosystem-proposals/pull/6 чёт не холиварят

наконец-то толково написали

хотя и перемудрили

а ghcid не может поломаться из-за template-haskell?

ERROR: S client not available

stack ghci нормально загружается

а ghcid игнорит 2 модуля с persistent декларациями

может -fno-code виновен?

а ghcid не может поломаться из-за template-haskell?

Может. Именно из-за этого и ломается скорей всего. Есть открытое issue: https://github.com/ndmitchell/ghcid/issues/101

ну я решил также проблему как в issue

для ghc ничего вроде distcc ещё не придумали?

нет вроде

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

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

@qnikst выше

+

Поругайте кот, пожалуйста: 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

Поругайте кот, пожалуйста: 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

Ругаю: выглядит слишком сложно для решаемой задачи

Опять же, зачем flip (-), если можно сменить порядок прямо в shiftedZipWith, если уж для shiftedSum ничего не изменится (ибо (+) коммутативен)

Опять же & не то чтобы чаcто используется, гораздо чаще встречается $. Иначе слишком часто придётся менять направление чтения - композиция то читается справа-налево в той же polygonArea

shiftedZipWith f vec = V.zipWith f vec shiftedVec where shiftedVec = V.snoc (V.tail vec) (V.head vec)

(&) и flip — ерунда по сравнению с enumFromTo, (&&&) и uncurry. когда кто-то из них встречается, здесь, вероятно, что-то переусложнено

(&) и flip — ерунда по сравнению с enumFromTo, (&&&) и uncurry. когда кто-то из них встречается, здесь, вероятно, что-то переусложнено

Или кто-то заюзал сервис pointfree

Aslm

Или кто-то заюзал сервис pointfree

Не-не, всё вручную писал

shiftedZipWith f vec = V.zipWith f vec shiftedVec where shiftedVec = V.snoc (V.tail vec) (V.head vec)

Это да, но конкатенация векторов - это О(n), а мне хочется поэффективнее. Индексацией напрямую можно получить то же самое, но без конкатенации

Нет конкатенации векторов, есть snoc

К тому же n запросов по индексу, это та же сложность, не?

К тому же n запросов по индексу, это та же сложность, не?

А разве в V.zipWith не индексация?

Так zipWith все равно в обоих вариантах есть

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

Hello

Hello

?

Не знаю, пофиксили ли, но встречал и испытывал на себе, что uncurry не лучший выбор в плане для перфоманса иногда https://stackoverflow.com/a/38440296/210905