Tim Whiting

@anfelor I'd be very happy if I was wrong, I'll have to take a look at it deeper later. You probably are correct, and it probably works precisely due to...

> Thanks for checking, @TimWhiting! I wonder if we should rewrite the function to use in-place updates? We should, but due to the effect issue, we really need a way...

For multiple resumptions it makes sense that it would end up copying, but always filling the vector completely. However, I don't think that is safe for all effects. If the...

> > it isn't the vectors that are providing destructive update by themselves > > Ah, I think they are? Similar to how constructors can be reused, we could have...

> > It also looks like we have a different potential issue with the observability of destructive updates > > Hmm, I agree that this behavior could be counter-intuitive, but...

True, I guess the only way it mutates is if it is unique, so it's not really a drop, it is a free.

Given this discussion I think we need to do the following: - Adjust the map function to use in-place updates when the vector is unique - Provide another version of...

Daan actually already has a `kk_box_null` which he uses when initializing vectors (it's just in the runtime though, and not exposed as a koka value, so we would just need...

@anfelor I found some issues with our PR #550 It doesn't have correct behavior in the case of exceptions like I was afraid of. Specifically for the `assign/update` function. The...

```koka import std/num/int32 fun main() with handler ctl await(initiate) initiate(resume) try { println("before wait") wait(1.i32) println("after wait") } fn(err) { println(err) } alias aio = alias aiox = alias result...