Conversation

This library is built on top of low-level primitive operations for capturing slices of the RTS stack that I’ve added in my branch of GHC. Combined with a focus on minimizing allocation, `eff` generates incredibly good code. Here’s what the Core and STG output usually looks like.

In `eff`, I have taken great care to ensure code that doesn’t manipulate continuations doesn’t have to pay for them: low-level support for continuations means no need to CPS the program, which cuts down on heap allocation enormously. `eff` stack-allocates as much as possible.

To minimize heap allocation and pointer indirections, `eff` uses the new UnliftedNewtypes extension internally to avoid boxing as much as possible. To keep the code manageable, pattern synonyms are used where I can be confident the boxing will be optimized away.

`eff` follows a “pay only for what you use” philosophy: most common effects—including Reader, Error, State, and Writer—never capture the continuation even once. If you do use an effect that captures the continuation, `eff`’s internal state adapts to accommodate further captures.

The user-facing interface to `eff` is comparable to existing free monad-based encodings of extensible effects, and in some ways I think it’s actually simpler. None of the implementation complexity is visible to an end user of the library.

`eff` supports full delimited continuations with late binding of effectful operations: a captured continuation can be resumed with a completely different set of handlers, as long as all the effects are still handled.

`eff` is mostly working, but it is still only a prototype: • It only works on my modified fork of GHC. • The continuation primops need optimizing. • Support for IO exceptions and resource handling is 100% achievable but needs to be implemented. • Everything needs docs!

Andrej Bauer

@andrejbauer

Uhm, any particular reason you are calling it `eff`? That kind of clashes with the original Eff (eff-lang.org) and might cause some confusion.