fram-lang / fram-lang/dbl

Parametric handlers via named parameters

Open
#205 1 comment 0 reactions 1 assignee Claimed by @Brychlikov View on GitHub
0. parsing 1. type inference 2. effect inference 3. core 4. eval proposal
Dominant language
OCaml
Stars
45
Forks
28
PR merge metrics
No merged PRs in 30d

Description

During the discussion with @forell and @Brychlikov we observed that parametric handlers can be combined with the general approach to named parameters, making Fram more uniform. For instance, the standard state handler could be written the following way.
```
let hState st0 =
handler ST
{ get = effect () => resume {st} st
, put = effect new_st => resume {st=new_st} ()
}
parameter st = st0
end
```
The parameter(s) of the handler are introduced by the `effect` construct, and the resumption is a polymorphic variable that expects such parameters. These parameters can be any named things, like types or implicits. Implicits are particularly interesting, as they allow to write handlers that provide more than one mutable cell, without unnecessary noise. For instance, consider the following definition.
```
let hPairOfStates stA0 stB0 =
handler
let hA = ST
{ get = effect () => resume ~stA
, put = effect st => resume {~stA=st}
}
let hB = ST
{ get = effect () => resume ~stB
, put = effect st => resume {~stB=st}
}
in (hA, hB)
parameter ~stA = stA0
parameter ~stB = stB0
end
```
I don't see any use cases for type parameters (yet?), but we could have them for free with this approach.

There are some design decisions that should be made. For instance:
- which parameters are implicitly introduced to the environment (all of them? only implicits? maybe it should be consistent with the rules for polymorphic abstraction?)
- what is the syntax, for explicit binding of these parameters in the effect construct? (some of it might be consistent with #145)
- how label types should look like?
- should we compile parametric handlers to the `finally` clause (or more precisely, regular let binding) in Core? Maybe Core should have similar feature? Can it be combined somehow with parametric resets proposed in #145?

With parametric handlers we could also consider removing `finally`clauses from the language, as they are counter-intuitive.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.