jacobdweightman / allium

The Allium Programming Language
MIT License
2 stars 1 forks source link

Parsing for effect handlers #11

Closed jacobdweightman closed 2 years ago

jacobdweightman commented 2 years ago

This issue is related to the effects and handlers design document.

Implement parsing for handlers.

  1. The new keyword handle should be supported by the lexer.
  2. Add these grammar rules:
    <handler> := "handle" <effect-ref> "{" <0-or-more-effect-implications> "}"
    <effect-implication> := <effect-ctor-ref> "<-" <expression> ";"
  3. Add appropriate printing logic for running with --print-syntactic-ast
  4. Unit tests for the new parsing logic
kwalberg commented 2 years ago

After reading the effects/handlers design document, I have a couple questions about the intended syntax for effect handlers:

  1. Is the <effect-ctor-ref> component of an effect implication intended to be an effect constructor reference in the way that the parser defines it? Specifically, the parser defines an effect-ctor-ref as:

    <effect-ctor-ref> := "do" <identifier>
    <effect-ctor-ref> := "do" <identifier" "(" <comma-separated-arguments> ")"

    I'm essentially wondering if you want to have the "do" as part of the left-hand side of the effect implication.

  2. Are handlers required to come after implications in a predicate definition, or should it be possible for implications and handlers to be interleaved?

jacobdweightman commented 2 years ago
  1. I'm okay with having the do as part of the effect implication. I think that will make the parser change a little bit easier (or at least a little bit smaller).
  2. There are some parts of the design proposal that need to be changed. I'm not sure what would be best — in some sense, the way that Allium reconciles algebraic effects and handlers with logic programming will be its key contribution. I think this paper gives some helpful examples of how algebraic effects can work with functional programming (specifically Eff), so I'd like something that provides similar composability. The short answer right now is that all handlers should either go before the implications or after the implications (pick one).
kwalberg commented 2 years ago

Sounds good to me. I like those answers because they make the implementation of this issue a lot easier 😄