An interesting use of reflection about fused-effects HOT 3 CLOSED

Ah, I just read in the readme the typeclass-based carriers are actually a feature, as they are what make fusion possible.

from fused-effects.

Ah, I just read in the readme the typeclass-based carriers are actually a feature, as they are what make fusion possible.

Yep, exactly!

That’s a neat use of reflection, but you can actually get this behaviour a little more prosaically by using a higher-order function as an argument to the carrier:

newtype TraceC m a = TraceC { runTraceC :: (String -> m ()) -> m a }

runTrace :: Carrier sig m => (String -> m ()) -> Eff (TraceC m) a -> m a
runTrace f = runTraceC f . interpret

(For a more involved example, see Control.Effect.Resumable; this is pretty much what runResumableWith/ResumableWithC is doing.)

This definitely reduces boilerplate! However, by using a higher-order function, you’re cheating yourself out of efficiency—the compiler is much less able/willing to fuse, inline, and optimize away the interpreter.

That’s essentially the tradeoff that fused-effects makes: a little more code to write a new effect handler, but extremely efficient execution once you have done so. As you found, and as demonstrated above, it can also express reduced-boilerplate implementations, but my personal feeling is that they don’t belong in this library.

On the other hand, for quick experiments, you could always try a carrier something like this:

newtype InterpreterC eff m a = InterpreterC { runInterpreterC :: (forall x . eff m (m x) -> m x) -> m a }

instance Carrier sig m => Carrier (eff :+: sig) (InterpreterC eff m) where
  …

I’m not certain how to adapt the above to express carriers like StateC or ErrorC that wrap results in a functor, but it could probably be done.

from fused-effects.

I’m going to close this out now for tidiness, but thank you for sharing your use of reflection!

from fused-effects.