4 ms·

If you're interested in Eff then Conor McBride's "Frank" ought to be worth checking into as well: http://homepages.inf.ed.ac.uk/slindley/papers/frankly-draft-ma

by tel 12y ago

If you're interested in Eff then Conor McBride's "Frank" ought to be worth checking into as well: http://homepages.inf.ed.ac.uk/slindley/papers/frankly-draft-march2014.pdf http://homepages.inf.ed.ac.uk/slindley/papers/frankly-draft-...

cies 12y ago
I came here to post the same link (it was already in my ctrl-c memory). Does anyone know how these languages compare? To me as a noob in this field, the Frank language was a lot easier to grasp.
- tel 12y ago
  To be honest, Eff is a lot simpler, but I think the papers are written very differently. McBride wants to share with you his new toy demonstrating how many neat ideas can fit together nicely. Bauer and Pretnar are also trying to talk about the general idea of "algebraic effect handlers". Anyway, the big differences between Frank and Eff is that Frank (a) invents its own syntax while Eff just more or less steals ML's and (b) Frank also includes a very interesting "evaluation order" called Call-by-Push-Value. CBPV is kind of comparable to things like Call by Name and Call by Value, "non-strict" and "strict" evaluation orders. Really, however, it's not comparable. When you have a lambda calculus you have a little bit of ambiguity between evaluation orders---there's a question, should you use CBV or CBN? CBPV is an elaboration of the lambda calculus where that choice no longer remains as it has been made explicitly in the syntax and you can switch between them as you like. Another way of seeing it is that you can translate (Lambda Calculus + CBN) or (Lambda Calculus + CBV) into CBPV but you cannot directly translate (Lambda Calculus) alone due to the ambiguity I mentioned---CBPV won't tolerate that. So what Frank is showing is that CBPV is a neat way of building a language and that it works very nicely with algebraic effects, in fact, since a side effect of CBPV is to make segments of code where "computation" occurs very distinct from places where "values are described". Side effects, as it turns out, only show up during computation so you can recognize larger segments of you code which you just don't have to worry about side effecting at all.

by tel 12y ago

cies 12y ago

I came here to post the same link (it was already in my ctrl-c memory). Does anyone know how these languages compare? To me as a noob in this field, the Frank language was a lot easier to grasp.

tel 12y ago
To be honest, Eff is a lot simpler, but I think the papers are written very differently. McBride wants to share with you his new toy demonstrating how many neat ideas can fit together nicely. Bauer and Pretnar are also trying to talk about the general idea of "algebraic effect handlers". Anyway, the big differences between Frank and Eff is that Frank (a) invents its own syntax while Eff just more or less steals ML's and (b) Frank also includes a very interesting "evaluation order" called Call-by-Push-Value. CBPV is kind of comparable to things like Call by Name and Call by Value, "non-strict" and "strict" evaluation orders. Really, however, it's not comparable. When you have a lambda calculus you have a little bit of ambiguity between evaluation orders---there's a question, should you use CBV or CBN? CBPV is an elaboration of the lambda calculus where that choice no longer remains as it has been made explicitly in the syntax and you can switch between them as you like. Another way of seeing it is that you can translate (Lambda Calculus + CBN) or (Lambda Calculus + CBV) into CBPV but you cannot directly translate (Lambda Calculus) alone due to the ambiguity I mentioned---CBPV won't tolerate that. So what Frank is showing is that CBPV is a neat way of building a language and that it works very nicely with algebraic effects, in fact, since a side effect of CBPV is to make segments of code where "computation" occurs very distinct from places where "values are described". Side effects, as it turns out, only show up during computation so you can recognize larger segments of you code which you just don't have to worry about side effecting at all.