m
> % stack --version
> Version 2.5.1, Git revision d6ab861544918185236cf826cb2028abb266d6d5 x86_64 hpack-0.33.0
Size: a a a
2021 April 28
JS
ага, но всё равно stack jobs гранулируются на уровень выше модулей
JS
а вот это плохо пахнет. должно было заработать без этого
ЗП
Если такого инстанса нет в либе, то на то есть причины наверное ибо StateT довольно популярный трансформер
JS
не могу сказать больше без погружения в код
JS
это скорее архитектурная задача
MK
Анлифтить можно только ридер
MK
Для остального есть монад контрол
ЗП
Где это описано?
JS
там задача — скрещивать StateT и persistent-postgresql
MK
В доке анлифтио
ЗП
Не так выразился, почему только Reader?
MK
Потому что у него не надо запоминать и восстанавливать стейт
m
Я не до конца понимаю суть, почему нельзя протягивать состояние.
Вот у меня такое:
Т.е. наверняка ж можно, как тут уже рекомендовали, для реализации
Вот у меня такое:
type PostgresT m = ReaderT Connection (StateT TxState m) -- Убрал RWST
type TxState = HMap TxStateKeySpace
data TxStateKeySpace
data HMap keySpace where
HMap :: Map Text (PropertyValue keySpace) -> HMap keySpace
data PropertyValue keySpace where
PropertyValue :: (IsKeySpaceProperty keySpace name t) => Key keySpace name t -> t -> PropertyValue keySpace
Т.е. наверняка ж можно, как тут уже рекомендовали, для реализации
MonadUnliftIO StateT просто через MVar перебросить?JS
но тогда лучше ReaderT MVar, чем StateT
JS
но State и MVar — это существенно разные вещи. State всегда контролируется, а MVar может уплыть в другую нитку