Parametric handlers via named parameters
- 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.