[TYPES] effect vs. coeffect expressiveness

Vikraman Choudhury vikraman.choudhury at gmail.com
Thu Apr 30 14:24:40 EDT 2020


Hi Jonathan,

I'd like to point out a recent paper[0] by Neel Krishnaswami and I,
"Recovering Purity with Comonads and Capabilities" which provides a
different take on this topic.

The ability to perform an effect can be encoded by the use of
permission/capability variables. A comonad/coeffect modality can be used
to control access to capability variables. Using this idea, we can
encode capability-safe and pure functions in an unsafe/impure calculus
-- a pure function is a capability-safe function with no capabilities!

We show that it is possible to use this comonad to embed the pure CBV
lambda calculus into an impure calculus, while preserving the full
beta-eta equational theory. This is not unlike the embedding of linear
logics into intuitionistic logic.

[0] https://arxiv.org/abs/1907.07283

Jonathan Aldrich writes:

> [ 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


--
Vikraman


More information about the Types-list mailing list