Three Dollar Quill

After writing some more jank Koka, I believe that the state of local variables is the same after each call to resume() in Koka. Maybe there's an obvious reason that it has to be that way, but I was frankly pulling my mind in too many directions at once to be able to tell.

So, let's think some more about how variables should act. The big hurdle if I do go with "all stack variables are predictably-sized fat pointers to arbitrarily shaped objects on the heap, and there's a reference count somewhere", is that it gets kind of hard to to write a pure function, at least I think so.

Supposing we have a list/vector type that works kind of like in Python, because I think I want that. It's possible to express read-only semantics for the fat pointers here, but it doesn't actually help, because something else can take a reference to the object and mutate it. This is what has me thinking "hm, maybe capabilities would be useful somehow". Like, if a function relies on val, box, and tag type references to external data, then it shouldn't be possible to break purity by changing the objects behind those references, because they can't change from the perspective of the function.

This is complicated, so I'm going to try to break it down into reasonable steps.

• "Hey, I want a language that's similarly dynamic to Python, but it has an effet system."
• "Well, it's not obvious how to reconcile the effect system with how Python handles writing functions, so it doesn't make sense to work on the object system before addressing that."
• "So, I want to be able to write a Koka-pure function that relies on module-level variables."
  • This has some weird implications even before I get into trying to implement it, because it implies some way of saying "unlike other functions, this functions is not callable immediately after it is defined, but only after some external condition is met".
• "I bet something like Rust or Pony could help with this."

So, if I want things to work the way I think I want them to, then I need to be able to implement the following setup:

• Variables that are referenced via (probably fat) pointers, to data on the heap that contains some necessary metadata, and the actual data.
• The ability to construct mutable variables.
• The ability to define functions.
• A basic type system.
• A basic effect system.
  • Which handles mutability of shared state.

I won't say that's a lot of the work, but if I can't do that much, then I need to reconsider the entire big picture of the design.

The near-term stuff to do goes as follows, but not in any particular order:

• Take more of these notes
• Go through Rust tutorials
• Go through Pony tutorials
• Get back to Crafting Interpreters, and therefore, my Earley parser yak shave.

It's good that I have goals, but next up, I need a plan to make sure I actually work on them. I'll see how that goes. Anyway, no more to do for today.

Good night.