Do be do be do (2017) [pdf](arxiv.org)
arxiv.org
Do be do be do (2017) [pdf]
https://arxiv.org/abs/1611.09259
9 comments
also quoted in the linked paper :)
For the curious, "do be do be do" is a seminal paper in the literature on algebraic effects that introduces frank, quirky little language that has algebraic effects but not handlers, at least in the traditional sense.
Traditionally, an effect handler is an interpreter for a stream of commands, conforming to a specific interface. Generally, handlers surface in languages as a sort of generalized try/catch mechanism, that receive a "callback" to resume the "exception" that produced the command. In frank, not so.
Frank is based around the idea of operators, which generalize functions with the capability of interpreting multiple streams of commands. A plain function can be seen, in fact, as the special case of an operator that interprets no commands.
Operators are organized around ports and pegs. Pegs are the set of side effects that a computation needs. Each port is an offer to extend that set for downstream callers. Instead of building up a union of effects that each function needs, Frank propogated ambient ability inwards. Operators can then be composed based on the ports and pegs they offer.
operator: <port>X → [peg]Y
This works partially because operators are shallow handlers and not deep handlers. Handlers interpret commands: if the handler itself is in scope when interpreting a command, then the language is said to have deep handlers. Frank has shallow handlers, meaning that commands are interpreted in an environment without the handling operator present. Shallow handlers give greater control to the programmer with respect to how commands are interpreted: operators can propagate ambient ability, or choose not to.
(This is a bad explanation because you already need to know what I'm talking about to understand what I'm talking about, but oh well.)
My one critism of frank is that the effect model is kinda hard for the working programmer to understand. I can explain Koka effects as "exceptions plus multiple resumption". I don't really have a categorical phrase for frank, and that's its innovation. This isn't so much a criticism but a plea for the pedagogical ramp to this research to improve.
do be do be do.
If you're still curious, check out the compiler github repo:
https://github.com/frank-lang/frank
And if anything is wrong in the above explanation, please correct me, because we all benefit from Cunningham's Law in the end. Allow me to be the fool.
Traditionally, an effect handler is an interpreter for a stream of commands, conforming to a specific interface. Generally, handlers surface in languages as a sort of generalized try/catch mechanism, that receive a "callback" to resume the "exception" that produced the command. In frank, not so.
Frank is based around the idea of operators, which generalize functions with the capability of interpreting multiple streams of commands. A plain function can be seen, in fact, as the special case of an operator that interprets no commands.
Operators are organized around ports and pegs. Pegs are the set of side effects that a computation needs. Each port is an offer to extend that set for downstream callers. Instead of building up a union of effects that each function needs, Frank propogated ambient ability inwards. Operators can then be composed based on the ports and pegs they offer.
operator: <port>X → [peg]Y
This works partially because operators are shallow handlers and not deep handlers. Handlers interpret commands: if the handler itself is in scope when interpreting a command, then the language is said to have deep handlers. Frank has shallow handlers, meaning that commands are interpreted in an environment without the handling operator present. Shallow handlers give greater control to the programmer with respect to how commands are interpreted: operators can propagate ambient ability, or choose not to.
(This is a bad explanation because you already need to know what I'm talking about to understand what I'm talking about, but oh well.)
My one critism of frank is that the effect model is kinda hard for the working programmer to understand. I can explain Koka effects as "exceptions plus multiple resumption". I don't really have a categorical phrase for frank, and that's its innovation. This isn't so much a criticism but a plea for the pedagogical ramp to this research to improve.
do be do be do.
If you're still curious, check out the compiler github repo:
https://github.com/frank-lang/frank
And if anything is wrong in the above explanation, please correct me, because we all benefit from Cunningham's Law in the end. Allow me to be the fool.
This is really informative, helps to put Frank in context, thanks!
To be is to do.
-- I. Kant
To do is to be.
-- A. Sartre
Do be a Do Bee!
-- Miss Connie, Romper Room
Do be do be do!
-- F. Sinatra
Yabba-Dabba-Doo!
-- F. Flintstone
* https://quoteinvestigator.com/2013/09/16/do-be-do/
Also, from the link:
Also, from the link:
“Dabba dabba doo” — Kate Bush
“Scooby-doobee-doo” — Scooby Doo
“Hey-boo-boo” — Yogi BearBaloo's doo bah dee doo song
https://www.youtube.com/watch?v=qqV_xW8CdFQ
Where are you
[deleted]
* https://quoteinvestigator.com/2013/09/16/do-be-do/