Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add algebraic effects to Zilch #7

Open
Mesabloo opened this issue Sep 5, 2021 · 0 comments
Open

Add algebraic effects to Zilch #7

Mesabloo opened this issue Sep 5, 2021 · 0 comments
Labels
about: design Related to design problems about: parsing Related to the lexer & parser about: type-checker Related to how types are statically checked kind: enhancement New feature or request
Milestone

Comments

@Mesabloo
Copy link
Member

Mesabloo commented Sep 5, 2021

Algebraic effects seem like a nice addition to the language, in order to be explicit about side effects of a given function.

  • Haskell (and some other functional programming languages) uses monad to show those inside function types (e.g. main :: IO ()), but this has the disadvantage to need a rather big amount of boilerplate code: composing multiple monads (e.g. State s with Except e) is achieved using monad transformers, which require extra typeclasses/instances, manual unfolding of monads, etc.
  • OCaml uses exceptions, which are not modeled into the type system, and do not model side effects such as console output

Algebraic effects generalize exceptions by allowing arbitrary computation-stopping (potentially resuming) functions to be called. Effects are also present in the type system, disallowing not handling some effects when required, or being effect-polymorphic.


Here is how the language can be extended for effects:

  • Add a construct to declare effects, e.g.
    effect <name>(<id>...) :=
      <op₁> : <type>
      <op₂> : <type>
      ⋯
      <opₙ> : <type>
    
    where each opᵢ is a way to “trigger” the effect handler for the declared effect, and must be unique across all effects
  • Allow creating handlers using a specific handle construct:
    • try <expr> with { <op₁> → <ex₁> ; <op₂> → <ex₂> ; ⋯ ; <opₙ> → <exₙ> ; return <id> → <exᵣ> } handles any effect that evaluating expr can have, going to the branch return ... → ... when no effect has been “thrown” (this might be extended in the same way as the Haskell language extension -XLambdaCase)

      When handling an effect, we have to handle all possible effects (but we may only handle one effect at a time)

  • Only functions can be effectful, where the return type of an arrow can be augmented with an effect row (no row means that a computation is pure)
    Grammar still needs to be fixed in order not to clash with reference capabilities

Foreign imported C functions cannot be made effectful, in order not to expose the internal effect handler API.
Specific ways of importing can be included in the language in order to somehow force adding effects to foreign functions by wrapping them in effect-triggering functions.

Originally posted by @Mesabloo in #4 (comment)

@Mesabloo Mesabloo added about: parsing Related to the lexer & parser about: type-checker Related to how types are statically checked about: design Related to design problems labels Sep 5, 2021
@Mesabloo Mesabloo added this to the Zilch v1 milestone Sep 5, 2021
@Mesabloo Mesabloo changed the title Add algebraic effets to Zilch Add algebraic effects to Zilch Sep 6, 2021
@Mesabloo Mesabloo added the kind: enhancement New feature or request label Sep 26, 2021
@Mesabloo Mesabloo moved this to In Progress in Issue tracker Nov 1, 2021
@Mesabloo Mesabloo moved this from In Progress to Todo in Issue tracker Nov 1, 2021
@Mesabloo Mesabloo mentioned this issue Aug 26, 2022
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
about: design Related to design problems about: parsing Related to the lexer & parser about: type-checker Related to how types are statically checked kind: enhancement New feature or request
Projects
Status: Todo
Development

No branches or pull requests

1 participant