[TYPES] effect vs. coeffect expressiveness

Flavien Breuvart breuvart at lipn.univ-paris13.fr
Thu Apr 30 04:06:32 EDT 2020


Hi Jonathan,

There is not much more written as there is a lot that we do not 
understand here. I will present my point of view on the subject (this is 
an invitation for other point of view to express themselves ;).

First of all, I may have been attracted by the production/consumption 
distinction, I do not use it anymore. It is miss-leading and not that 
usefull as you said.

One thing is certain : monads are way more natural in call-by-value, and 
comonads are way more natural in call-by-name. I have to stop Haskeller 
complaints as an aparte : most monad in Haskell are intrincically CbV as 
the argument is evaluated to some extent by the bind, in addition 
Haskell is call-by-need, which is slightly different from this point of 
view.

The real distinction I use on effects/coeffects is related to this 
statement : *effects describe what happen when the piece of code is 
evaluated*, while *coeffects describe what append when it is manipulated 
*(copied/erased/distributed).

Following this idea, one can see that most coeffects can be somehow 
encapsulated into effects (basically by looking at what happened to the 
other copies of the codes); and worst, all applied coeffect on the 
literature are internally encoded this way since code manipulations are 
not accessible by programmers. But I believe that there is more to be 
discovered and used from coeffect, especially for writing concurrent 
programs or performing code analyses.

I was a bit expeditious,  I can develop some of the points if you are 
interested.

I hope you enjoyed those random thoughts, and I invite other to do the 
same. This subject is very interesting, but too fuzzy for it to be 
formalized yet :)

Cheers,

Flavien (the one from Gaboardi et al's ICFP paper)


Le 30/04/2020 à 01:48, Jonathan Aldrich a écrit :
> [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]
>
> Dear Types,
>
> I am curious about the relative expressiveness of effects and
> coeffects.  Has this been studied?
>
> The cleanest distinction I've seen is that effects capture the impact
> a program has on its environment, i.e. what it produces.  Coeffects
> capture the requirements that a program puts on its environment: what
> it consumes.  This is discussed, for example, in Gaboardi et al's ICFP
> 2016 paper, "Combining Effects and Coeffects via Grading" (and
> elsewhere).
>
> There is some useful intuition in this distinction, and it describes
> the different structure of checking rules in effect and coeffect
> systems.  However, I don't find this distinction very helpful in
> thinking about expressiveness.  It seems like many examples can be
> expressed in either an effect or a coeffect system.  For example, an
> exception is a classic example of an effect (e.g. in the paper
> mentioned above, and many others).  However, it seems to me that
> exceptions can also be modeled as coeffects: code that might throw an
> exception requires the caller to pass a handler for that exception to
> it--or perhaps an abstract "permission" to throw that exception.  So
> in what sense are exceptions an effect, rather than a coeffect?
>
> Is this true of all the kinds of things that are typically expressed
> with effects and coeffects--that they could just as easily be
> expressed in the other style?  If so, what are the benefits of one
> style vs. the other?  Or are there examples that can only be expressed
> in one style--or for which expression in the other style is much more
> awkward?
>
> Perhaps these questions have been written about, but I haven't been
> able to find it.  I would love to get some pointers.  I am
> particularly interested in a practical explanation of the differences
> in expressiveness, or theoretical results that have a direct and
> explicit relationship to practice--with practical examples in either
> case.  (co-)Monads and/or anything categorical are not a very helpful
> starting point for me, but effect systems and/or linear types are
> (I've done research on both).  I am also more interested in the
> descriptive view of effects/coeffects (in the sense of Filinski,
> ICFP'11) than the prescriptive view.
>
> Thanks,
>
> Jonathan


More information about the Types-list mailing list