Three Dollar Quill

So, Koka. Why am I interested in it? The main thing that's special about Koka vs the other languages I know, is its effect system. As far as I'm currently aware, the effect system does two-ish things. At least one and a half. It allows library writers to define new flow control concepts, and customize existing ones. This is because it's sort of like exceptions, but resumable, and, if you opt into the fancy code generation, resumable multiple times. The other thing is, unhandled effects are part of the signature for the function that's not handling them, so they can be used to mark side effects.

Now, what has me interested is, well...

pub fun map(xs : list<a>, f : a -> e b) : e list<b>
  match xs
    Cons(x,xx) -> Cons(f(x), xx.map(f))
    Nil -> Nil

The precise details of the code aren't too important, what's interesting is the signature. map takes a list of objects of some type, applies a function to each element, and produces a list of the results. So far, so normal. But the other thing going on here is the e, representing the effects of the input function f. Those effects are passed along and emitted by the call to map.

So, if you wrap a map call in a handler for a custom effect that is emitted by f... You should be able to use the same library function to map using a function that, say, does cooperative multitasking, as not. Basically, what I'm seeing here, is higher-order functions that are transparent to function color.

Koka's an experimental language, and that's the experiment I'm interested in. I want to see what happens if you put structured concurrency's new primitive into a language that's designed to be tiny and extensible, and make a bunch of decisions differently from Python. (I am not the first person who's been curious what this would be like.)

Before I design too much of that, I want to get some more experience with Koka, so my plan is to mess around with Koka trying to solve a somewhat more concrete problem. More on that tomorrow...

Good night.