AA
кметт
Size: a a a
2021 October 11
YS
S
спасибо
YS
А давно кана ушёл?
YS
Я думал он тут одменит
AA
не знаю, я попробовал @ его но не сработало
DG
А он в каком чате сидит?)
AA
в твиттере
2021 October 12
И
Привет, кто то читал эту статью - https://www.fpcomplete.com/haskell/tutorial/fundeps/ ?
Я чего то немного выпадаю на моменте:
Я чего то немного выпадаю на моменте:
greeting :: PersonReader StringПри этом до этого мы делаем инстанс:
greeting = do
person <- ask
pure $ show person
... we call ask in a context where type inference tells us that the value must be
ask :: PersonReader a. However, nothing tells us what that a must be. ...
instance MonadReader Person PersonReader whereПочему этого недостаточно для вывода типа и понимания того что
ask = PersonReader $ \env -> env
a должен быть равен PersonИ
То есть если у нас в классе типов
и после этого мы пишем инстанс
MonadReader указано что у функции ask должен быть тип ask :: m envи после этого мы пишем инстанс
instance MonadReader Person PersonReader where у нас разве не должен получится конкретный тип ask вида PersonReader Person?И
И
В общем вот тут - https://jsdw.me/posts/haskell-language-extensions/#multiparamtypeclasses нашел такое объяснение
Even if there is only one instance, the assumption is that more could be created, and so probably to avoid that changing existing behaviour, the compiler is pretty cautious.
Вроде это и есть ответ на мой вопрос, но довольно странно, что в ghc доке об этом ни слова, а в вики описано как то очень поверхностно - Naive use of MPTCs may result in ambiguity
Even if there is only one instance, the assumption is that more could be created, and so probably to avoid that changing existing behaviour, the compiler is pretty cautious.
Вроде это и есть ответ на мой вопрос, но довольно странно, что в ghc доке об этом ни слова, а в вики описано как то очень поверхностно - Naive use of MPTCs may result in ambiguity
AP
Одного параметра может быть недостаточно, чтобы выбрать инстанс, поэтому и ambiguity
AP
Решается через functional dependencies, например
AP
instance MonadReader Person PersonReader where
ask = PersonReader $ \env -> env
тут всего лишь сказано, что для этой конкретной пары — когда оба типа известны — инстанс будет такойИ
Да, спасибо, я уже разобрался вроде
AP
Без "
| m -> env" компилятор не может выбрать env, исходя только лишь из mAP
Есть и другой способ — ассоциированный тип. Когда-то где-то даже были трансформеры в таком стиле, но победили те, что на FunDep
И
Вроде как ограничивается кол-во инстансов. Не может быть другого инстанса для монады m но с другим конкретным типом env