I don't quite get how messages and method calls interact. Could the process intercept the method call by explicitly receiving or somehow influence the process module to do something else?

Channels are a great idea! What capabilities (send on channel/receive on channel) can you forward to other processes? As Cloud Haskell explain, in distributed systems we must not allow send on channel to be forwarded.

Regarding channels, both linear channels and mailbox types for unordered interactions are interesting ideas worth looking into.

Great project!

    > I don't quite get how messages and method calls interact.

The term "message passing" is a bit confusing in this case, because it applies to both objects and actors, but both use a different approach.

When you send a message to a regular object, usually a method with the same name is called. For example, when using `process.send` the "send" method in the "process" module is called. This however can change, as objects can implement the method "unknown_message" to handle messages for which no method is explicitly defined.

In case of processes, sending a message is just that: you send a message, this gets put into a special queue, and then it's up to the receiving process to do something with it (whatever that might be). If you want to implement some kind of RPC system you'll need to see what kind of message you have, then dispatch accordingly. Inko's test suite does this using polymorphing: every message the test runner receives implements the "Command" trait, which defines a "run" method. The test runner then simply sends "run" to these command objects, letting them figure things out from there.

    > Channels are a great idea! What capabilities (send on channel/receive on
    > channel) can you forward to other processes? As Cloud Haskell explain, in
    > distributed systems we must not allow send on channel to be forwarded.

I'm not sure if I fully understand this question. A channel in Inko consists out of two objects: a Sender and a Receiver. The Sender just wraps the PID of the receiving process, the Receiver is just used for storing the type of the message at compile time, and providing some methods.

As to what you can send: everything that is compatible with the type of the channel. For example:

    import std::process

    let sender = process.channel!(Integer) lambda (receiver) {
      receiver.receive
    }

    sender.send('foo')

This will fail, because our channel only allows `Integer` values, whereas "foo" is of type `String`.

    > Regarding channels, both linear channels and mailbox types for unordered
    > interactions are interesting ideas worth looking into.

It is worth mentioning that despite the name "channel" being used for the method, it's not an actual channel data structure (e.g. like in Go). The messages are still stored in the mailbox of the receiver, just like when using `process.send`. Instead, the Sender/Receiver API is just a simple trick that allows the compiler to know what types of messages are being sent and received. I called this "channel", because after several hours of thinking I still couldn't come up with a better name.

Thanks for the details! The question about channels stems from the fact that in pi-calculus it's possible to have different processes read from the same channel - making it unsuitable for distribution. Your implementation of channels seems to be extremely similar to what I did! Keep calling it channels ;)

One thing I didn't like with the approach of storing channel messages in the mailbox is that if you use the regular receive statement you might receive a message ment for the channel. In my work I had to be very careful and use selective receive all the time. My preferred solution is to give each actor multiple inboxes so that unrelated messages don't get conflated. I haven't had time to explore this yet but if you're interested in implementing it in Inko I'll be glad to help.

    > My preferred solution is to give each actor multiple inboxes so that unrelated messages don't get conflated.

This is definitely an option, and I wouldn't be surprised if we eventually end up with something like this, though I'm not sure yet how the garbage collector would handle this.

Mailbox types for unordered interactions require manual management of mailboxes (new/free) but the type system guarantees that you can't free a mailbox with messages still in it. Garbage collection is probably possible but it seems difficult.