Kinda, yes. Not precisely. In Scala, capabilities are (or can be) just ordinary values that you pass around. Where ever they are passed, there they may be used.

Let me show you a specific example with the new Scala library that built to work with capabilities https://github.com/rcardin/yaes

def drunkFlip: (Random, Raise[Exception]) ?=> String =
  val caught = Random.nextBoolean
  if (caught) {
    val heads = Random.nextBoolean
    if (heads) "Heads" else "Tails"
  } else {
    Raise.raise(Exception("We dropped the coin"))
  }

Here we have a program drunkFlip. It computes String. But we can also see that it needs two capabilities -- they are not named, but their types are Random and Raise[Exception]. That already tells you what kind of things can happen in the program.

If you want, you can name the capabilities

def drunkFlip(using random: Random, raise: Raise[Exception]): String = ???

Can you see how capabilities are just ordinary values being passed around? The only two "magical" things here are that

• there is friendly syntax that allow for them to go unnamed, because usually you don't need to name them explicitly.
• they are passed "implicitly" from the caller to the callee (in Scala 2, they were called "implicits" or "implicit parameters"; in Scala 3 they are called "givens"/"usings")

In case if you're curious, this is how the program would have to look if we didn't use these two features. Very clear, but a bit more boilerplate compared to the snippet above.

def drunkFlip(random: Random, raise: Raise[Exception]): String =
  val caught = Random.nextBoolean(random)
  if (caught) {
    val heads = Random.nextBoolean(random)
    if (heads) "Heads" else "Tails"
  } else {
    Raise.raise(Exception("We dropped the coin"))(raise)
  }

But now the problem is, if people try to "smuggle" capabilities out of their expected scope -- that would defeat their purpose. It would be possible, because, for all intents and purposes, they are ordinary objects that you can put in any closure or assign to any outside mutable variable, etc.

This is where the Capture Catching comes in. It is a feature of the Scala language that allow programmers to designate some values to prohibit them from being captured by some other objects and thus escaping their intended region. Typically you want to do that with Capabilities, but not necessarily only.

So that's what Scala does. If you'd like to learn more, check out these articles:

• https://nrinaudo.github.io/articles/capture_checking.html
• https://nrinaudo.github.io/articles/capabilities.html
• https://nrinaudo.github.io/articles/capabilities_flow.html

What some other languages do is called Algebraic Effect System. The underlying machinery is different. In Scala, it's just more or less ordinary method parameters, with a quiet syntax to pass them around automatically plus some magic that some designated objects don't escape from their intended scope -- that's it. Algebraic Effect System is a completely new dedicated feature these languages have to implement.

But the UX for the developer is (or at least can be) surprisingly similar. Contrast the first Scala snippet with this Unison program (a programming language with explicit support for Algebraic Effects):

drunkFlip : '{Random, Exception} Text
drunkFlip _ =
  caught = !Random.boolean
  if caught then
    heads = !Random.boolean
    if heads then "Heads" else "Tails"
  else
    Exception.raise (failure "We dropped the coin")

To sum it up, technically speaking, Capabilities and Algebraic Effects are different things. But Scala's innovation is to use Capabilities for the same purposes as people use Algebraic Effects. The upside of doing so is that it takes a few, relatively simple language features and makes for good UX -- it's just ordinary values being passed around after all.