Add algebraic effects to Zilch #7
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
Algebraic effects seem like a nice addition to the language, in order to be explicit about side effects of a given function.
main :: IO ()
), but this has the disadvantage to need a rather big amount of boilerplate code: composing multiple monads (e.g.State s
withExcept e
) is achieved using monad transformers, which require extra typeclasses/instances, manual unfolding of monads, etc.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:
opᵢ
is a way to “trigger” the effect handler for the declared effect, and must be unique across all effectshandle
construct:try <expr> with { <op₁> → <ex₁> ; <op₂> → <ex₂> ; ⋯ ; <opₙ> → <exₙ> ; return <id> → <exᵣ> }
handles any effect that evaluatingexpr
can have, going to the branchreturn ... → ...
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)
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)
The text was updated successfully, but these errors were encountered: