Это не только порезать, но и в рантайме манипулировать где какая реализация используется. coerce для того чтоб можно было расширять множество эффектов в рантайме По сути это вариация на тему ReaderT IO

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

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

Это тоже можно

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

Ну это не "в рантайме" же

В рантайме можешь решить чем заменять

или ты имеешь в виду overrideCap?

Его, да

Хмм. Вот это неплохо, да

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

С этим фреймворком там всегда делается lookup ровно перед использованием (поэтому late bound)

Такой fixed point над ReaderT со словариками

Надо будет это потом еще побенчмаркать и возможно заменить Map на unboxed Vector, тогда даже оверхед будет нормальный.

https://github.com/int-index/caps

как правильно подружить пулл потоков и древовидно рекурсивные функции?

типа сделать подобную ей структуру и распихать TVar из stm. только не знаю насколько ок рекурсивные tvar

хотя в таком случае потоки могут иметь неактуальные tvar там вообще подразумевается изменение структуры или ты её просто собираешься фолдить эффективно по потокам?

имея такое data (a :: * -> *) |> b class Member (t :: * -> *) r instance Member t (t |> r) instance Member t r => Member t (t' |> r) testReader :: Eff (Reader Int |> Void) Int testReader = do x <- ask y <- ask pure $ x + y пишет • Overlapping instances for Member (Reader Int) (Reader Int |> Void) arising from a use of ‘ask’ Matching instances: instance Member t (t |> r) instance Member t r => Member t (t' |> r) как это возможно, как они могут оверлапиться вообще?

второй инстанс на Reader Int |> Void невозможен, ведь Reader Int никак не может быть внутри Void, возможен только первый инстанс, откуда оверлапинг

предполагается, что кто-то может сделать Reader Int |> Reader Int |> Void?

думаю, этот тайпкласс вполне реально переписать на семейство

лол, да, на семействах все ок работает

type family t `Elem` ts :: Bool where _ `Elem` Void = False t `Elem` (t |> r) = True t `Elem` (t' |> r) = t `Elem` r type Member t r = t `Elem` r ~ True

может кто объяснить, в чем разница? Почему на тайпклассах не работает, а на семействах работает? Полагаю, причина в том же, почему не работает открытый Elem (type family без where), но тоже пока сформулировать четко не могу

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

где оверлап вроде понятно

В закрытых clauses по очереди перебираются и оверлап ок, в открытых оверлап приводит к конфликту и фейлу.

да, это я понял, но где именно оверлап в первом случае? В возможности Reader Int |> Reader Int |> Void?

оверлап потому, что в инстанс хэд один и тот же конструктор

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

там не для любого же, в первом и во втором аргументе они должны быть одинаковыми

t и t' тоже одинаковые заматчат

эта одинаковость контекст же, который для разрешения не используется

Member t (t |> r) Member t (t' |> r) Второе строго более общее, чем первое

И оверлаппит

хм, я понял, спасибо

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

Всегда должен был вызывать

там оверлап разрешен просто

без включенного оверлапа вообще мало что из такого олегинга работает

а, нашел, да {-# LANGUAGE OverlappingInstances #-}

Если там класс, а не семья типов, то могли быть OverlappingInstances

С семьями типов никак и никогда такое не работало с открытыми

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

всё так

(по крайней мере SPJ об этом с такого угла говорил)

Бедный, бедный Taylor Fausak… https://twitter.com/taylorfausak/status/939937217685966848

в хаскель-комьюнити какая-то санта-барбара

> blocked me on both GitHub and Twitter for no apparent reason. > no apparent reason

блочить плохо, но какой там к черту no apparent reason

и не говорить, что забанишь и достал и т.п. перед этим

Ты подписался на него, чтобы поддержать, надеюсь?

Вообще, самое удивительное, что у нас до сих пор один Haskell.

Боюсь, это только влияние SPJ.

нет, я не собираюсь вписываться в их споры, ни на чьей стороне

я подписался, чтобы видеть что пишут и формировать более полное мнение

I am on nobody's side, because nobody is on my side!

вот что-то такое

мне если честно бомбит со снойманитов

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

там такой my way or the highway что я даже hvr понимаю (хотя и не одобряю бан на гитхабе, это вообще за гранью добра и зла)

Да, я в общем согласен.

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

они по очереди создают баги во всех проектах, реддите и прочем до конца

причем в твиттерах ещё идёт их пассивно-агрессивный стиль, или как это зовется

с одной стороны и не ругают и все выглядит корректно, с другой ужасный blaming

и им так можно

а если что-то против, то все CoC, вызов SPJ и т.п.

выговорился

Спасибо!

SPJ жалко :)

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

Я не думаю, что он особенно страдает по этому поводу

надеюсь, до него этот ад особо не доходит

Вообще, самое удивительное, что у нас до сих пор один Haskell.

уже два, но второй довольно небольшой и слабый (и, вероятно, не жилец)

Это вы про что? Так-то по ходу много возникало, но всё отваливалось быстро

про eta

Вообще, самое удивительное, что у нас до сих пор один Haskell.

Как было с nodejs?) Ну они потом слились опять в одно

почему diffClockTimes дает отрицательное значение пикосекунд?

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