Two questions

[bgrundmann]

Why can I only modify a vector inside a local-var? That is why is there no function:

fun vector-set(v : vector<a>, index: int, assigned: a): vector<a>

Given perceus / reference counting this should be efficient and would allow one to implement for example a classic hash table efficiently?! (This was actually what I wanted to try as my first experiment with koka but immediately failed with this road-block).

Why is the console effect internal? That is I thought it would be neat to implement a expect testing framework (similar to https://github.com/janestreet/ppx_expect) for koka, where a test is a function with console effect, but the calling function intercepts the writes to the console to compare against the expected string. But again that seems to be impossible not for a deep reason internal to koka but let's called implementation choices.

Did I misunderstand something?

[timjs]

It would be indeed nice to have a mutable vector, but I think it needs to be a separate type, something like buffer<h,a> which is a buffer in heap h of elements a. Conversion from/to vectors would be a no-op when uniquely referenced.

[bgrundmann]

Why? I am sure this is obvious if you regularly write in Koka, but to me it is unclear why updating of an element in a vector should be different to updating an element in a struct? Or does updating an element in a struct introduce a heap effect?

[timjs]

Ah, I see what you mean: creating a function set(v, i, x) on vectors which makes a copy of v and sets the ith element to x. Only when v happens to be unique, optimise this and do it in-place.

Should be possible to add something like that as an external function I think, but I don't know the right C incantations.

[TimWhiting]

#550 is open now to solve the issue of adding set/update to vectors to mutate in place if unique.

As far as console, at some point there needs to be an effect type to track builtin effects (i.e. at some point it needs to actually go to the console). For example, I wouldn't want there to be a way to write to the console without introducing an effect.

There is no standard effect for a log though, which is what I would expect to be able to capture from a test, and which would default to logging to the console otherwise - introducing the console effect! In other words, the console effect is still important to reason about even if it is not the primary interface.

It is a good question whether the standard print / println functions should use console or a user handleable effect. I think a user handleable effect though should provide more configuration out of the box (trace levels, etc), which makes it more of a logger and log/logln would be an appropriate name for those functions. So personally, I'm fine with print / println being the "low-level" primitives. Curious about your opinions though.

[timbertson]

Yeah I agree, it's on my list to create a log / logger effect one of these days. It would want to be a bunch higher level than just "write a string", in order to support e.g. JSON logging, levels, etc.

[timbertson]

I had the same thought about intercepting console for test purposes. FYI there is this:

koka/lib/std/core/console.kk

Line 34 in 39b4bec

noinline fun print-redirect( print : (msg : string) -> console () ) : <ndet,console,st<global>> ()

(but that feels like a hack around the fact that is't not a handleable effect, which does seems like a strange choice to me too)

Also if you're looking at test frameworks, be aware that the community one lives here: https://github.com/koka-community/std/tree/main/test