4 ms·

Eff needs some additional optimization or some extra compiler support before it can thrive in the wild, because the constant overheads are pretty severe. The as

by Kutta 11y ago

Eff needs some additional optimization or some extra compiler support before it can thrive in the wild, because the constant overheads are pretty severe. The asymptotic overheads though are really good, basically they managed to get rid of all possible time complexity blowups with the last Eff refinement that added type-aligned sequences.

chowells 11y ago
Eff has a bigger semantic issue to deal with first. It is only composable for commutative effects. Once you introduce non-commutative effects like throw/catch or nondeterminism, the semantics of a block of code using more than one effect depends on the order in which interpreters are run. Monad transformers escape this issue by allowing code to specify the effect nesting order in the type. They're no panacea either, of course. But they currently allow somewhat better code reuse and abstraction properties than the Eff approach does. If Eff ever gets the ability to control the semantics of non-commutative effects, it will have a much more compelling story.
- Kutta 11y ago
  It's not particularly worse than monad transformers with respect to non-commutative effects. With monad transformers, one can trip up just as happily on exceptions, and mtl-style stack-polymorphic code can be run with various effect orderings with possibly varying semantics. I failed to mention though that Eff would also benefit from some boost to type inference for open sums. Currently it's throwing up hands for component effects with polymorphic inner type parameters, like `State s` or `Reader r`, so we can't do things like `put 0`, but only `put (0 :: Int)` (in the absence of other type annotations in outer scopes). It's fortunately not an impossible problem; we just need to allow for unique projections from sums in our type-level machinery (this requires some annoying boilerplate currently, but maybe GHC 8.0 will make it easier with the new kind system).
  - chowells 11y ago
    Yes, transformers allow you to get it wrong, too. But at least there is a way to get it right with them.

by Kutta 11y ago

chowells 11y ago

Eff has a bigger semantic issue to deal with first. It is only composable for commutative effects. Once you introduce non-commutative effects like throw/catch or nondeterminism, the semantics of a block of code using more than one effect depends on the order in which interpreters are run. Monad transformers escape this issue by allowing code to specify the effect nesting order in the type. They're no panacea either, of course. But they currently allow somewhat better code reuse and abstraction properties than the Eff approach does. If Eff ever gets the ability to control the semantics of non-commutative effects, it will have a much more compelling story.

Kutta 11y ago
It's not particularly worse than monad transformers with respect to non-commutative effects. With monad transformers, one can trip up just as happily on exceptions, and mtl-style stack-polymorphic code can be run with various effect orderings with possibly varying semantics. I failed to mention though that Eff would also benefit from some boost to type inference for open sums. Currently it's throwing up hands for component effects with polymorphic inner type parameters, like `State s` or `Reader r`, so we can't do things like `put 0`, but only `put (0 :: Int)` (in the absence of other type annotations in outer scopes). It's fortunately not an impossible problem; we just need to allow for unique projections from sums in our type-level machinery (this requires some annoying boilerplate currently, but maybe GHC 8.0 will make it easier with the new kind system).
- chowells 11y ago
  Yes, transformers allow you to get it wrong, too. But at least there is a way to get it right with them.