<p>In Tyler Mandry's <a href="https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities" rel="noreferrer">&quot;Contexts and Capabilities&quot;</a>, he writes:</p>
<blockquote>
<p>What if Rust code could instead declare the context it needs, and the compiler took care of making sure that context was provided?</p>
<p>This general concept is addressed by a few different approaches in other languages:</p>
<ul>
<li>Dependency injection</li>
<li>Implicit arguments</li>
<li>Effects</li>
</ul>
</blockquote>
<p>I understand the connection to dependency injection and implicit arguments, but I don't really understand how an algebraic effects system could provide similar functionality. There's a footnote, which links to the <a href="https://en.wikipedia.org/wiki/Effect_system" rel="noreferrer">Wikipedia page</a> on effects and the <a href="https://koka-lang.github.io/koka/doc/book.html" rel="noreferrer">Koka language</a>, but I'm still not clear on how effects would work as an alternative to the &quot;contexts and capabilities&quot; model described in the blog post.</p>
<p>I do see some connection to IO as an algebraic effect, in the sense that perhaps functions using IO could require some kind of effect handler to determine the interface on which to perform an IO operation. But I'm not sure if that is actually something you can do in Koka or if that is what the blog post is trying to imply.</p>

<effect-systems>
How do algebraic effects provide similar capabilities as implicit contexts or dependency injection?
<p>On the type system level, effect systems have the same sort of &quot;infectious&quot; behavior as this post's with clauses. Any expression that performs an effect or uses a capability is noted as doing so in its type, and this gets propagated out to larger expressions, its containing function, and then expressions that call that function, until it stops at an effect handler or with expression.</p>
<p>You can translate the post's system of &quot;capabilities,&quot; &quot;with clauses,&quot; and &quot;with expressions&quot; 1:1 into effects by writing an effect signature for the <code>capability</code> item. Using <a href="https://koka-lang.github.io/koka/doc/book.html#sec-handling" rel="noreferrer">Koka's syntax</a>, you might write this example from the post...</p>
<pre><code>capability alloc: Allocator
</code></pre>
<p>...as this effect signature:</p>
<pre><code>effect alloc
  ctl allocate(l: layout): result&lt;ptr&gt; // making up some Koka syntax
</code></pre>
<p>Then this <code>with</code> expression...</p>
<pre><code>with alloc = SomeAllocator {
    do_some_allocation()
}
</code></pre>
<p>...would look like this effect handler:</p>
<pre><code>with handler
  ctl allocate(l) /* allocator implementation */ 
do_some_allocation()
</code></pre>
<p>(I picked the allocator example because it uses an interface designed to be implemented multiple ways, and effect signatures can similarly be handled multiple ways. You could also do the <code>BasicArena</code> example with a concrete type by making the effect signature just return an instance of that type, or any number of other variations- the general idea is still that of &quot;filling in&quot; some part of an expression/function &quot;from the outside.&quot;)</p>

CC BY-SA 4.0
2023-07-03T04:59:30.753Z
2023-07-03T04:59:30.753Z
rpjohnst
# How do algebraic effects provide similar capabilities as implicit contexts or dependency injection?
Posted by: username_0 on 2023-07-03
In Tyler Mandry's ["Contexts and Capabilities"](https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities), he writes:

> What if Rust code could instead declare the context it needs, and the compiler took care of making sure that context was provided?
>
> This general concept is addressed by a few different approaches in other languages:
>
> * Dependency injection
> * Implicit arguments
> * Effects

I understand the connection to dependency injection and implicit arguments, but I don't really understand how an algebraic effects system could provide similar functionality. There's a footnote, which links to the [Wikipedia page](https://en.wikipedia.org/wiki/Effect_system) on effects and the [Koka language](https://koka-lang.github.io/koka/doc/book.html), but I'm still not clear on how effects would work as an alternative to the "contexts and capabilities" model described in the blog post.

I do see some connection to IO as an algebraic effect, in the sense that perhaps functions using IO could require some kind of effect handler to determine the interface on which to perform an IO operation. But I'm not sure if that is actually something you can do in Koka or if that is what the blog post is trying to imply.
**Tags:** effect-systems
---
## 1 answers
### Answer by username_1 on 2023-07-03. Score: 5 | Accepted answer
On the type system level, effect systems have the same sort of "infectious" behavior as this post's with clauses. Any expression that performs an effect or uses a capability is noted as doing so in its type, and this gets propagated out to larger expressions, its containing function, and then expressions that call that function, until it stops at an effect handler or with expression.
You can translate the post's system of "capabilities," "with clauses," and "with expressions" 1:1 into effects by writing an effect signature for the capability item. Using Koka's syntax, you might write this example from the post...
capability alloc: Allocator

...as this effect signature:
effect alloc
  ctl allocate(l: layout): result // making up some Koka syntax

Then this with expression...
with alloc = SomeAllocator {
    do_some_allocation()
}

...would look like this effect handler:
with handler
  ctl allocate(l) /* allocator implementation */ 
do_some_allocation()

(I picked the allocator example because it uses an interface designed to be implemented multiple ways, and effect signatures can similarly be handled multiple ways. You could also do the BasicArena example with a concrete type by making the effect signature just return an instance of that type, or any number of other variations- the general idea is still that of "filling in" some part of an expression/function "from the outside.")
---
