I recently wrote a paper Iteration and labelled iteration with Paul. Summary: When you naively add iteration to lambda calculus, nested loops with control are very inconvenient in the resulting language. The inconvenience is rather like trying to program with De Bruijn indices. We give an alternative syntax using second-order labels.
» paper html / pdf
My research is about improving functional programming, specifically tweaking algebraic effects and handlers to get stronger guarantees on the behaviour of effects: if
set effects are handled by runState, then we want to optimise e.g.
get() + get() to
2×get(). This is currently not generally possible, especially not under lambdas; the language feels too imperative for me. I think the first step towards such optimisations is coupling handlers to effect names: names should not be values but identifiers bound by the handler.
» more about my research