Inter-robot communication

[byorgey]

This may be still a ways off, but eventually we certainly want to be able to have inter-robot communication. This would enable lots of cool things such as remotely controlling or reprogramming robots, creating teams of robots that can dynamically coordinate among one another, etc. There is some discussion of this in #17 (comment) .

There is a lot of language design work to be done here. My initial vague thought is to look for inspiration to things like pi-calculus and session types. Probably full-on session types are too heavy-handed, though. Maybe something simple like typed broadcast channels: a value of type chan t is a channel over which values of type t can be broadcast, supporting operations like

write : forall t. chan t -> t -> cmd ()
read : forall t. chan t -> cmd (unit + t)

Channels will be private in the sense that only robots with a reference to a channel can use it. However, once we merge #303, binding the result of newChannel to a name will automatically make it available to later REPL commands and to robots built afterwards.

There are also game design issues to think about; e.g. what sort(s) of device(s) should be needed to use these features? How far should the signals travel? On the one hand it might be annoying to have to worry about signal strength; on the other hand it might be kind of cool to have to set up a network of robots serving as signal repeaters.

EDIT (14 April 2023): Here's a summary of my latest thinking.

• chan t represents a typed broadcast channel, as before.
• There is no plain newChannel operation. Rather, channels will be tied to specific media. For example there might be a way to get a channel corresponding to a cable (Use placed cables as communication channels #739) or a way to get a channel corresponding to your antenna (Give view a limited broadcast range #17), or a channel corresponding to shouting into the air (Medium-independent communication #737). Each channel value will keep track of what the criteria are for being able to use it successfully (e.g. you must still be sitting on top of the corresponding I/O cable).
  • However, perhaps there would be some device that would provide a newChannel : cmd (chan t) command.
• There will be some dynamic type checking going on under the hood, so if you get a channel for a cable with type chan int, and another robot gets a channel for the same cable with type chan bool, neither of you will be able to hear the other --- you only get messages with the type you expect.
• There is only a send : chan t -> t -> cmd unit function which will make the value available on the channel in the next tick. If you want to send for multiple ticks you can easily program your own function to call send repeatedly.
• There is only a primitive non-blocking read which listens for a value for a single tick.
  • If you aren't listening to a channel at the exact time a message is broadcast, you won't hear it.
  • If you are expecting the wrong type, you won't hear anything.
  • You can easily program your own readBlocking : chan t -> t -> cmd t which simply calls read in a loop until it gets a value.
• You can build asynchronous communication on top of this by e.g. programming a robot to listen to a channel continuously, remember whatever it hears, and then respond to requests for information later.

[byorgey]

I'm upgrading this from Nice to have to Moderate --- it seems to keep coming up! I think this is probably one of the first things we should tackle after the alpha release.