classy-effects: 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. It also includes several standard effect definitions defined in compliance with CEPs, and Template Haskell functions to automatically make type classes conform to CEPs as effect classes.

Please refer to CEPs for details.

The Template Haskell functions are re-exported from the classy-effects-th package, while the fundamental definitions are re-exported from the classy-effects-base package.

This 'classy-effects' project was abandoned due to the discovery of fundamental difficulties. The reasons are as follows: https://github.com/orgs/sayo-hs/projects/4?pane=issue&itemId=48547880 As an alternative, consider using 'sayo-hs/data-effects', a GADTs-based common effect representation foundation: https://github.com/sayo-hs/data-effects.


[Skip to Readme]

Modules

[Index] [Quick Jump]

Downloads

Maintainer's Corner

Package maintainers

  • No current members of group

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.1.0.0, 0.1.0.1
Change log ChangeLog.md
Dependencies base (>=4.16.4.0 && <4.17), classy-effects-base (>=0.1 && <0.2), classy-effects-th (>=0.1 && <0.2) [details]
License MPL-2.0
Copyright 2023 Yamada Ryo
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)
Uploaded by YamadaRyo at 2024-07-09T11:05:49Z
Distributions
Reverse Dependencies 1 direct, 0 indirect [details]
Downloads 50 total (14 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-0.1.0.1

[back to package description]

Status (2024) : This classy-effects project was abandoned due to the discovery of fundamental difficulties.

The reasons are as follows: https://github.com/orgs/sayo-hs/projects/4?pane=issue&itemId=48547880

As an alternative, consider using sayo-hs/data-effects, a GADTs-based common effect representation foundation: https://github.com/sayo-hs/data-effects

classy-effects

Hackage Hackage Hackage

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.

Credits

Parts of this project have been adapted or inspired by the following resources:

  • Hefty Algebras -- The Artifact

    • Copyright (c) 2023 Casper Bach Poulsen and Cas van der Rest
    • License: MIT
    • Modifications: The inspiration for the idea of Heftia. Code was used in the definition of LiftIns.
  • effet

    • Copyright (c) 2020 Michael Szvetits
    • License: BSD-3-Clause
    • Modifications: Used TemplateHaskell code to handle the effect type class.
  • compdata

    • Copyright (c) 2010--2011 Patrick Bahr, Tom Hvitved
    • License: BSD-3-Clause
    • Modifications: Used TemplateHaskell code to derive instances of the HFunctor type class.
1

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