move entire communication system into library

[graydon]

Ports, channels and tasks are going to sink into library features. This includes send and receive operators, as well as communication-alt expressions.

[eholk]

In a lot of ways, I like this. There's really little reason spawn shouldn't be in the library, as far as I know right now. One advantage is that it makes it easier to have different variants of spawn. We could have the simple version, and then other ones for "spawn in new thread" or "spawn on remote machine."

One concern I'd have is that we might be giving up information that the compiler has about the semantics of communication, which could inhibit some of our optimization opportunities. Also, for the moment rust is doing a deep copy of data structures for spawn arguments and messages. This may not be something we actually need to do, but if we do need it, could we still do it nicely in a library?

[brson]

I'm worried about communication alt being too verbose under this scheme. Also, can this be delayed until after the 0.1 milestone?

[graydon]

I think a couple simple schemes for comm-alt-via-a-library (say by tagging ports and channels you pass to the library call) will handle the verbosity. I'd prefer not to delay this; it really affects the feel of the language.

[eholk]

What do we have in mind for communication alt? Is it any different than this?

alt(recv(p)) {
   ...
}

[graydon]

no, that's just alt-ing on the result of a blocking receive. a comm-alt was to switch between "whichever of N communication events is ready next", a la a select loop. Which is fine: it just needs a richer function-call UI. There's lots of surface to possible event-waiting / event-notifying APIs though, which is exactly why I want it in a library, not a "ok let's do more compiler hacking to conduct the next experiment or tweak" situation.

[eholk]

All done.

04af99e
39b1607
871d131
b2dad8a
a332043
2f23405
b9f1f77
7ad1339
cc353aa
c3535f5
be73250
aa0a51a
d63f834
871013b
3fd3f35