Спасибо

Пиши в чат, если не получится. И какая свёртка кстати, линейная или циклическая?

new :: (Hashable a, Ord a) => Config -> IO (Cache a b) new Config{..} = do ref <- newIORef PSQ.empty pure $ Cache { requestOrInternal = \tm k f -> mdo mbox <- atomicModifyIORef ref $ swap . PSQ.alter (\case Just (p,~v) | p >= tm ^-^ cacheLongestAge -> (Just v, Just (tm, v)) _ -> (Nothing, Just (tm, Lazy result))) k result <- maybe (trace "f" $ f k) (evaluate . getLazy) mbox atomicModifyIORef ref $ swap . PSQ.alterMin (\case Nothing -> ((), Nothing) Just (kk,p,v) | p < tm ^-^ cacheLongestAge -> ((), Nothing) | otherwise -> ((), Just (kk,p,v)) ) pure result }

так сработало

^-^ - найс

но добавление Lazy и getLazy не очевидно

из бонусов, что неявный лок на вызове evaluate . getLazy

т.е. только 1 тред будет работу работать

я очень люблю эту фишку, но я боюсь, что это accidental complexity

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

^-^ - найс

оператор "котик спрятался, видно только ушки"

оператор nya

а можно ли в семействах добавлять новые типопеременные?

оператор "котик спрятался, видно только ушки"

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

И это тоже. Псто я предложил менее виабушный вариант

f :: HasField "a" r0 r1 String Int => HasField "b" r1 r2 Int String => Record r0 -> Record r2 вот имею такой код, хочу написать хелпер для композиции HasField, но для этого придется скрыть из внешнего скоупа r1 и добавить в скоуп внутри семейства, это реально?

type family RecordDelta fs r0 rn :: Constraint where RecordDelta '[] r r = () RecordDelta ('(name, a -> b) ': fs) r0 rn = forall r1. (HasField name r0 r1 a b, RecordDelta fs r1 rn) типа такого

И это тоже. Псто я предложил менее виабушный вариант

а это всего-лишь AdditiveGroup

type family RecordDelta fs r0 rn :: Constraint where RecordDelta '[] r r = () RecordDelta ('(name, a -> b) ': fs) r0 rn = forall r1. (HasField name r0 r1 a b, RecordDelta fs r1 rn) типа такого

я такое никогда не делал

а это всего-лишь AdditiveGroup

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

Обычно сложением называют коммутативную операцию

Обычно сложением называют коммутативную операцию

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

википедия ссылаясь на "Каргаполов М. И., Мерзляков Ю.И. Основы теории групп. — 3-е изд.. — Москва: Наука, 1982. — С. 18. — 288 с. — 11 800 экз." использует аддитивная

но вообще это класс из vector-space пакета

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

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

в numeric-prelude достаточно большая иерархия

но полурешеток вроде нету

раздельные есть в lattices

простую я сам изобретал

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

т.к. сложность бешено быстро растет

сложность программирования

Что именно? Более вменяемые классы для чисел?

ага

ну вообще всю эту алгебру честную бы засунуть

у нас только vector-space и numeric-prelude как эксперименты

Ну хотя бы выдрать аддитивную группу и кольцо из Num

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

Ну хотя бы аддитивную группу

и fromInteger отделить как синтаксический костыль

и в transition period сделать Num зависяшим от себя

да-да-да

реально бесит

Всех — слишком много. Выходит по классу на операцию :( С одной стороны так и надо, с другой — морочно

ну т.е. будет промежуточный вариант, хочешь - используешь, не хочешь берёшь Int/Double где все есть

у нас только vector-space и numeric-prelude как эксперименты

есть еще пакет algebra

о кметтопакет

Вопрос, а почему я в рамках ду нотации часто вижу pure вместо return? Экономия на символах?

некоторые считают такой подход более принципиальнм

return - это реликт со времен, когда Monad и Applicative не были в одной иерархии

у меня получилась такая иерархия class CFoo a where foo :: TFoo class CFoo a => CFooBar a where foobar :: TFooBar class CFoo a => CFooBaz a where foobaz :: TFooBaz fooViaBar :: TFooBar -> TFoo fooViaBaz :: TFooBaz -> TFoo data X instance CFoo X where foo = fooViaBar instance CFooBar X where foobar = (realImplementation) data Y instance CFoo Y where foo = fooViaBaz instance CFooBaz Y where foobaz = (realImplementation) чувствую, что-то не так, но не могу понять как правильно. что посоветуете?

некоторые считают что return путает людей

и.к. это не ретурн из императивных яп

"pure - для аппликативных выражений, return - для do-блоков" :)

у меня получилась такая иерархия class CFoo a where foo :: TFoo class CFoo a => CFooBar a where foobar :: TFooBar class CFoo a => CFooBaz a where foobaz :: TFooBaz fooViaBar :: TFooBar -> TFoo fooViaBaz :: TFooBaz -> TFoo data X instance CFoo X where foo = fooViaBar instance CFooBar X where foobar = (realImplementation) data Y instance CFoo Y where foo = fooViaBaz instance CFooBaz Y where foobaz = (realImplementation) чувствую, что-то не так, но не могу понять как правильно. что посоветуете?

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

у меня получилась такая иерархия class CFoo a where foo :: TFoo class CFoo a => CFooBar a where foobar :: TFooBar class CFoo a => CFooBaz a where foobaz :: TFooBaz fooViaBar :: TFooBar -> TFoo fooViaBaz :: TFooBaz -> TFoo data X instance CFoo X where foo = fooViaBar instance CFooBar X where foobar = (realImplementation) data Y instance CFoo Y where foo = fooViaBaz instance CFooBaz Y where foobaz = (realImplementation) чувствую, что-то не так, но не могу понять как правильно. что посоветуете?

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

Нужны классы-синонимы. Тогда развесистые иерархии не страшны и можно дробить тайпкласссы. Что-то вроде class Functor a => Applicative a = Pointed a, Apply a class Pointed ... class Apply ... Можно объявлять инстансы по отдельности, а можно вместе. instance Applicative даёт инстансы Pointed и Apply, инстансы Pointed и Apply дают Applicative

у меня получилась такая иерархия class CFoo a where foo :: TFoo class CFoo a => CFooBar a where foobar :: TFooBar class CFoo a => CFooBaz a where foobaz :: TFooBaz fooViaBar :: TFooBar -> TFoo fooViaBaz :: TFooBaz -> TFoo data X instance CFoo X where foo = fooViaBar instance CFooBar X where foobar = (realImplementation) data Y instance CFoo Y where foo = fooViaBaz instance CFooBaz Y where foobaz = (realImplementation) чувствую, что-то не так, но не могу понять как правильно. что посоветуете?

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

Гранулярная иерархия становится нестрашной

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

Ассоциированный тип в Foo и диспетчеризация по нему?

Ассоциированный тип в Foo и диспетчеризация по нему?

да, об этом и думаю

Нужны классы-синонимы. Тогда развесистые иерархии не страшны и можно дробить тайпкласссы. Что-то вроде class Functor a => Applicative a = Pointed a, Apply a class Pointed ... class Apply ... Можно объявлять инстансы по отдельности, а можно вместе. instance Applicative даёт инстансы Pointed и Apply, инстансы Pointed и Apply дают Applicative

не понял синтаксис

type Applicative a = (Functor a, Pointed a, Apply a)?

Да, плюс сахар для объявления инстансов

instance Applicative f where pure = ... (<*>) = ... рассахаривается в instance Pointed f where pure = ... instance Apply f where (<*>) = ...

Да, плюс сахар для объявления инстансов

а, это про алгебру, не про мой вопрос?

Это про страдания с классами.

Тредов нет

всё вперемешку

а ещё можно Old.Applicative

+ deriving via

Просто в этом случае мы автоматически получаем инстансы для Pointed и Apply. Для всех типов, где есть Applicative

но с дерайвинг в другую сторону не будет

А тут в обе стороны

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

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

classy (+) :: a -> a -> a instance (+) :: Int -> Int -> Int where ....

Автоматические классы?

Автоматические классы?

полуявные

Это уже что-то нездоровое, кмк