classy-effects-base: An interface for a handler-independent, typeclass-based effect system.

[ control, effect, library, mpl ] [ Propose Tags ]

This library provides definitions for CEPs (classy-effects protocols) to standardize and unify the definition of effects in Haskell in a backend-library-agnostic manner. Please refer to CEPs for details. This library provides only the fundamental definitions for classy-effects. Please also refer to the classy-effects package, which offers standard effect definitions compliant with CEPs, and the classy-effects-th package, which enables automatic compliance with CEPs.


[Skip to Readme]

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.1.0.0
Change log ChangeLog.md
Dependencies base (>=4.16.4.0 && <4.17), compdata (>=0.13 && <0.14) [details]
License MPL-2.0
Copyright 2023 Yamada Ryo, 2023 Casper Bach Poulsen and Cas van der Rest
Author Yamada Ryo <ymdfield@outlook.jp>
Maintainer Yamada Ryo <ymdfield@outlook.jp>
Category Control, Effect
Bug tracker https://github.com/sayo-hs/classy-effects
Source repo head: git clone https://github.com/sayo-hs/classy-effects(tag v0.1.0)(classy-effects-base)
Uploaded by YamadaRyo at 2023-09-18T06:39:48Z
Distributions
Reverse Dependencies 3 direct, 1 indirect [details]
Downloads 28 total (7 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]

Readme for classy-effects-base-0.1.0.0

[back to package description]

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.