koka icon indicating copy to clipboard operation
koka copied to clipboard

rename ref.modify -> ref.access

Open timbertson opened this issue 7 months ago • 3 comments

This caused me some confusion when I was getting started, particularly because ref.modify { x => x + 1 } is exactly how you would increment a Ref[Int] in scala's cats-effect, but produces surprising results in koka.

When I found out how it worked I thought access seems like a more neutral name, since it allows reading & writing, whereas to me modify is misleading because I assumed it would always modify the ref.

I've left modify as a deprecated alias.

timbertson avatar Apr 17 '25 12:04 timbertson

I'm a bit worried about the docs for this because the vector use case mentioned isn't really accurate, we need something like #716 or #550 for vectors to be able to update in-place. This only puts the ref into a local scope, which prevents escaping the scope, nothing else as far as I can tell. Maybe a better name for this would be as-local or local-scope or something?

TimWhiting avatar May 26 '25 02:05 TimWhiting

I think those names work (though access still feels accurate to me too).

Regarding the docs, what's the core difference? IIUC it's that using modify will not end up creating two references to the value. Which would always save a refcount incr/decr, but if the underlying value is unique (likely) it'd also enable all the in-place optimisations of modifying a unique reference?

timbertson avatar May 27 '25 22:05 timbertson

Yeah, that is the core difference. Access only makes the ref seem like a local (i.e. no escaping the scope and implicit dereferencing). Under the hood it is still just a ref value, not the inner value.

TimWhiting avatar May 27 '25 23:05 TimWhiting