Better typing for trapped exits and monitor messages about midas HOT 5 OPEN

What is the problem with calling it twice? It could potentially change the mapping function, but I don't see a problem with that? Perhaps I'm missing something.

Maybe it isn't a problem, although I can't see a reason to change the mapping function.

This is not type safe as the msg transformer function could return a type different to that which the process accepts as a message.

You can type the spawn function to make sure they have to be the same return type.
For example this produces a compiler error

fn myfunc(foo: fn() -> a, bar: fn() -> a) {
    todo
}

fn demo() {
    myfunc(fn() { 2 }, fn() { 2.0 })
}

Does this mean the process will hold a map of functions that take pids/ports and return a message?

Basically yes, although I would have the key of the map be the reference from the monitor, it's possible to have more than one monitor point to the same pid

from midas.

Thanks for sharing! This is very cool :)

This is the same design that the gleam-experiments/otp_process library currently uses: https://github.com/gleam-experiments/otp_process/blob/02f8ba0b5b3c3c39096ad7117f9a486e6c5281eb/src/gleam/otp/process.gleam#L141

Still needs to be called only once, cannot be enforced.

What is the problem with calling it twice? It could potentially change the mapping function, but I don't see a problem with that? Perhaps I'm missing something.

Option 2

This is not type safe as the msg transformer function could return a type different to that which the process accepts as a message.

Very similar except the mapping function is passed when the monitor is created.

Does this mean the process will hold a map of functions that take pids/ports and return a message? I think we'd need to remove the function from the map once the that down message has been received to prevent a memory leak.

from midas.

I think there is an option 4.

process.spawn_link(fn(receive) {
  // continue ...
    
}, [TrapExit(fn(pid, reason) { Exit(pid, reason) })])

Then if you are not trapping exits you can just put an empty list.

process.spawn_link(fn(receive) {
  // continue ...
    
}, [])

This is much neater than the Error(Nil) as last argument.
Also other process flags and spawn options could be passed in that list.

p.s. this is my new favourite approach

from midas.

That is 100% what the my OTP process module does 😁

(Or did, I'm currently fiddling with it)

from midas.

https://github.com/gleam-lang/otp/blob/607b5a8e45727999f07438ef3f81053aa6a61cfb/test/gleam/otp/process_test.gleam#L117-L127

Looks like it was a while back, but still! I like this design.

from midas.