@hackage classy-effects0.1.0.0

An interface for a handler-independent, typeclass-based effect system.

classy-effects

This repository is for CEPs and its associated Haskell library.

CEPs (Classy-Effects Protocols) are a collection of protocols for expressing and defining effects in Haskell, aimed at the fist objective in the Sayo Project:

Exploring ways to improve interoperability among the myriad Haskell effect system libraries

For more details, please refer to CEPs/README.md.

Background

In Haskell, there are numerous libraries to realize an effect system. The issue here is interoperability between these libraries. For instance, the Reader effect in fused-effects and the Reader effect in polysemy have completely identical definitions. If we could extract and define effects purely as interfaces, eliminating this redundancy in effect definitions, then an effectful program could be handled by both effect system library A and effect system library B. The specific mechanisms for handling effects vary from one library to another, and unifying them isn't the goal. We're specifically looking to unify the overlapping and common definitions of effects as interfaces.

Based on this idea, CEPs (classy-effects protocols) were developed. CEPs propose a convention (protocol) for unified effect definitions in Haskell. It's expected that effects defined in accordance with CEPs will be usable across various effect systems and backends.

Encoding of Effect

First, for the representation of effects, there is the GADTs encoding typical in Extensible Effects and the type-class encoding typical in the monad transformer approach. In principle, if the type class representing the effect is decided, GADTs can be automatically generated, and the reverse is probably also possible. There's a kind of symmetry here. However, type classes have the advantage of expressing inclusion relationships of effects naturally by specifying superclasses. From this perspective, CEPs primarily adopt type class representation for effects. Moreover, a mechanism has been implemented to derive GADTs from type classes1, and from GADTs and the type classes that cast them to monads (SendIns, SendSig), to automatically derive instances of the effect's type class (classy-effects-th). This allows compliance with CEPs automatically by just writing the type class that represents the effect.

Examples

Examples of using classy-effects combined with the Heftia effect handler backend can be found here.

Your contributions are welcome!

Please see CONTRIBUTING.md.

1

In the future, we might also consider implementing the derivation of type classes from GADTs.