Three Dollar Quill

While I let renaming stuff for MOTR percolate a little, I'm going to consider some thoughts about how NABTO "should" work. The current topic: how even do variables work?

Let me see if I can explain what has me so unsure. Consider the following Python code:

def getter_and_setter(value: int = 0) -> tuple[
    Callable[[], int], Callable[[int], None]
]:
    def getter() -> int:
        return value

    def setter(new_value: int) -> None:
        nonlocal value
        value = new_value

    return getter, setter

Now, I understand Koka just well enough to expect that the relevant type signatures in an equivalent function definition would look somewhat different. Let's see how things shake out...

So. This doesn't compile. But the error it produces is very informative.

fun getter-setter( initial_value : int = 0 ) : _ (() -> _ int, int -> _ ())
  var value := initial_value
  ({ value }, fn( new_value : int ) { value := new_value })

It would be worth figuring out if it's possible to get this to compile, because I think I want code like this to work in NABTO, but I also want it to have sensible effect typing.

Anyway, the basic thing I learned about Koka from writing that code is that Koka distinguishes between local variables, and heap variables, in terms of the effect system. My initial, probably faulty read of the compiler error is that a variable has to be allocated on the heap in order to close over it. I'd be more confident of this, or alternatively know that I have it wrong, if I had a better understanding of how variable allocation is controlled in Koka.

Anyway, this may or may not be moot, because one thing I'm not sure of is whether values in NABTO should act more like Python values, or Koka values. I'm leaning towards Python (heap allocated, reference counted), but I'm not sure what knock-on effects that has on the design.

In any case, my thinking on the above code snippets is that equivalent code should be possible in NABTO, but it should have effects attached to the types. This is because the returned functions cannot be pure in the Koka sense, so they must have some effect other than raising an exception or diverging.

My intuition about this is, I need to get some experience with how variables work in Koka, and, say, Rust and Pony. I believe that would cover a good portion of the relevant design space.

Anyway, I need to wrap up for now.

Good night.