R:
Вроде же
(>>) это легаси, не?Почему (>>) легаси?
Size: a a a
2019 January 21
λ
Почему (>>) легаси?
Потому что уже есть
(*>), который делает в точности то же самое.λ
Точно так же, как
return.R:
Точно так же, как
return.Ну да, pure звучит лучше
R:
И не так конфьюзит новичков
λ
Ну да, pure звучит лучше
А ещё лучше описывает семантику.
ЗП
для
>> требования быть монадой избыточноЗП
поэтому
*> более правильныйYL
Да, но с другой стороны семантика монады предписывает выполнять выражения строго последовательно, а семантика applicative допускает вычисление параллельно. В случае effectful computation это имеет значение.
λ
Да, но с другой стороны семантика монады предписывает выполнять выражения строго последовательно, а семантика applicative допускает вычисление параллельно. В случае effectful computation это имеет значение.
Так нет же. Порядок эффектов задан как в монаде, так и в аппликативе.
p
это я к тому, можно ли (теоретически) захантить кого-нибудь на пурсовый проект из чатика
предполагаю, что сложно, но можно
предполагаю, что сложно, но можно
Теоретически можно 😂
YL
Так нет же. Порядок эффектов задан как в монаде, так и в аппликативе.
Конечно, с точки зрения имплементации порядок вычисления эффектов строго определён и на практике можно расчитывать что сперва выполнится эффект слева, его результат проигнорируется и потом вычислится эффект справа. Но вот с точки зрения контракта имхо такой гарантии нет. И если в какой то момент появится имплементация вычисляющая левое и правое выражение (с эффектами) параллельно, то мой код поламается.
YL
Например: https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo#Motivation
Some Monads have the property that Applicative bind is more efficient than Monad bind. Sometimes this is really important, such as when the Applicative bind is concurrent whereas the Monad bind is sequential (c.f. Haxl). For these monads we would like the do-notation to desugar to Applicative bind where possible, to take advantage of the improved behaviour but without forcing the user to explicitly choose.
Some Monads have the property that Applicative bind is more efficient than Monad bind. Sometimes this is really important, such as when the Applicative bind is concurrent whereas the Monad bind is sequential (c.f. Haxl). For these monads we would like the do-notation to desugar to Applicative bind where possible, to take advantage of the improved behaviour but without forcing the user to explicitly choose.
YL
(») имплементация использует (»=) + const, и тут независимо от того как имплементирован Applicative instance (последовательно или параллельно) есть гарантия строгой последовательности выполнения. В случае же (*>) последовательность или параллельность выполнения зависит от Applicative instance
YL
И вот ещё нашёл:
> The original Applicative/Monad proposal stated that after
implementation, the designated implementation of (>>) would become
(>>) :: forall a b. m a -> m b -> m b
(>>) = (*>)
by default. You might be inclined to change this to reflect the stated
proposal, but you really shouldn't! Why? Because people tend to define
such instances the /other/ way around: in particular, it is perfectly
legitimate to define an instance of Applicative (*>) in terms of (>>),
which would lead to an infinite loop for the default implementation of
Monad! And people do this in the wild.
This turned into a nasty bug that was tricky to track down, and rather
than eliminate it everywhere upstream, it's easier to just retain the
original default.
> The original Applicative/Monad proposal stated that after
implementation, the designated implementation of (>>) would become
(>>) :: forall a b. m a -> m b -> m b
(>>) = (*>)
by default. You might be inclined to change this to reflect the stated
proposal, but you really shouldn't! Why? Because people tend to define
such instances the /other/ way around: in particular, it is perfectly
legitimate to define an instance of Applicative (*>) in terms of (>>),
which would lead to an infinite loop for the default implementation of
Monad! And people do this in the wild.
This turned into a nasty bug that was tricky to track down, and rather
than eliminate it everywhere upstream, it's easier to just retain the
original default.
2019 January 23
YL
Кто может объяснить почему приведение типов в данном случае не работает?
aa :: forall r. (aff :: AFF | r) -> (aff :: AFF, effect :: EFFECT |r)
aa = identity
YL
[1/1 TypesDoNotUnify] test/Test.purs:45:6
45 aa = identity
Could not match type
( aff :: FProxy Aff
| r0
)
with type
( effect :: FProxy Effect
, aff :: FProxy Aff
| r0
)
VY
не знаю как правильно подобрать слова, но в типе ф-ции указано, что тип результата должен содержать ("в том числе и") метку e
ffect :: FProxy Effect, но тип аргумента же гаратнированно содержит лишь aff :: FProxy AffVY
наоборот бы можно было, я думаю, т.е. если бы было:
aa :: forall r. (aff :: AFF, effect :: EFFECT | r) -> (aff :: AFF | r)ЗП
Кто может объяснить почему приведение типов в данном случае не работает?
aa :: forall r. (aff :: AFF | r) -> (aff :: AFF, effect :: EFFECT |r)
aa = identity
все еще на версии 0.11?