Rename channel types and constructor

[brson]

The current Chan::new() -> (Port, Chan) is confusing because new returns a tuple instead of a new object, 'port' and 'chan' are not intuitive, and the name 'chan' is reused for two purposes (the sender and the total channel).

Some proposed alternatives:

• Chan::open() -> (Source, Sink)
• Chan::new() -> (Source, Sink)
• Chan::new() -> (Sender, Receiver)
• Chan::new() -> (Source, Drain)
• pipe() -> (Port, Chan)

Also need to consider whether sender or receiver comes first in the tuple.

Nominating.

Discussion: https://mail.mozilla.org/pipermail/rust-dev/2014-January/007928.html

[tarcieri]

I suggest:

Chan::open() -> (Sender, Receiver)

[wycats]

I agree with with @Bascule. let (sender, receiver) = Chan::open() feels natural to me.

[wycats]

To clarify, the reason I prefer Sender and Receiver is that port/chan are words that don't carry enough meaning to disambiguate without referencing the manual.

An orthogonal, but related proposal:

let sender = do spawn |receiver| {

}

It would presumably use a new name, not spawn.

[dherman]

Huzzah for this bug! Boo for paired terminology without mnemonics.

[brendanzab]

Copying my post on the mailing list here:

The aversion to a standalone functions in this thread and in our community in general is concerning. Not everything has to be a method or associated function! There is no single thing being constructed here - both ends of the channel are being constructed at once.

Whatever names we choose for the sender and receiver ends of the pipe/channel, it would be nice to have the sender first in the tuple and the receiver last. Here is an ASCII diagram to help illustrate why I think this ordering makes sense:

channel() -> (Sender, Receiver)

Sender::send(T) >== channel ==> Receiver::recv() -> T

Not saying that Sender, Receiver or channel() are the names we should pick - just illustrating how a well designed API can help reinforce the fact that the message is ‘sent’ down one end, and ‘received’ once it pops out the other.

The other thing we must consider is how the type names of the two ends of the pipe would be reflected in client code. Sender and Receiver when combined with the send and recv method names tend to look stuttery if you use the type names for the identifiers, :

let (sender, receiver) = channel();
sender.send(x);
let y = receiver.recv();

[wycats]

@bjz it's too bad there's no Call trait (yet?).

let (send, receive) = channel();
send(x);
let y = receive();

[tikue]

My thoughts:

• I think libstd should try hard conform to Type::new -> Type, unless there's a really good reason to not conform. In this case, I think Chan::open() makes at least as much sense as Chan::new(), so I'm not a huge fan of Chan::new(). But:
• I also think @bjz makes a pretty good point that there's nothing wrong with standalone functions.
• For something so visible in Rust, it'd be nice to have a more personal touch than (Sender, Receiver).

Out of these options, my vote goes to channel() -> (Source, Sink) or channel() -> (Source, Drain).

[wycats]

I agree with @tikue that open is preferable to new. I disagree with the need to get more "personal" here. I prefer excruciatingly readable to clever or cute.

[brendanzab]

I would also add that we should pick one name out of 'stream', 'channel', or 'pipe' for the relationship between the sender and receiver, then purge the other names from the documentation. Using multiple names can be very confusing.

[tarcieri]

I like channel()

[wycats]

@bjz agreed. I would leave pipe for the Unix API. I prefer channel to stream primarily because "stream" is pretty overloaded and "channel" mostly means this concept across PLs.

[tarcieri]

I think "channel" is definitely the correct term due to its heritage in CSP:

https://en.wikipedia.org/wiki/Channel_(programming)

[wycats]

I'm also ok with channel() or Channel::open().

[brendanzab]

Yes, I would look to the terminology most in use historically for the thing that most fits with our semantics. CML, which has a messaging model extremely similar to Rust's uses the term 'channel'. http://en.wikipedia.org/wiki/Concurrent_ML

let val c : string chan = channel ()
in ... end

Note that CML's channel primitives are bidirectional, hence the single result returned by the channel function.

[brendanzab]

From 3.3.1 in Concurrent Programming in ML, Reppy writes:

Channels in CML are bidirectional; a thread that has access to a channel can both send and receive messages on it. A safer discipline would be to distinguish between input and output accesses to a channel, so that threads could be restricted to only send or receive on a channel. Another way to think of a channel is as a directional pipe, with each end represented by a value of a different type. While such a view of channels could be built into the language, in CML we can use events to provide this different style of channels as a first-class abstraction. The interface signature for directional channels is given in Listing 3.5. Values of the in_chan type can only be used to read messages, and those of the out_ch type can only be used to send messages.

(* Listing 3.5: Directional channels signature *)

signature DIR_CHAN =
    sig
        type ’a in_chan and ’a out_chan

        val channel : unit -> (’a in_chan * ’a out_chan)
        val recv    : ’a in_chan -> ’a
        val send    : (’a out_chan * ’a) -> unit

        val recvEvt : ’a in_chan -> ’a event
        val sendEvt : (’a out_chan * ’a) -> unit event
    end;