Re: [rust-dev] Auto-borrow/deref (again, sorry)

2013-12-25 Thread Kevin Ballard
On Dec 25, 2013, at 5:17 PM, Vadim wrote: > I agree that unexpected mutation is undesirable, but: > - requiring 'mut' is orthogonal to requiring '&' sigil, IMHO, > - as currently implemented, Rust does not always require mut when callee > mutates the argument, for example: > > fn main() { >

[rust-dev] Auto-borrow/deref (again, sorry)

2013-12-25 Thread Vadim
I agree that unexpected mutation is undesirable, but: - requiring 'mut' is orthogonal to requiring '&' sigil, IMHO, - as currently implemented, Rust does not always require mut when callee mutates the argument, for example: fn main() { let mut i: int = 0; foo(&mut i); println!("{}", i)

Re: [rust-dev] Unbounded channels: Good idea/bad idea?

2013-12-25 Thread Kevin Ballard
On Dec 24, 2013, at 10:23 PM, Daniel Micay wrote: >> 3. Having a bound of 1 by default. The default should allow for parallelism. > > A bound of 1 by default seems pretty stupid. I've never understood why > Go does this... it belongs in a separate type. Go actually has a default bound of 0. Whe

Re: [rust-dev] How to send a closure in a task

2013-12-25 Thread Philippe Delrieu
Thank you for your help. I test extern "Rust" fn(u64, T) and it works when I use a declared function. I didn't manage to make it works with a closure. For the 'static |u64, &T| I have the same error : cannot capture variable of type `'static |u64, &T|`, which does not fulfill `Send`, in a bo

Re: [rust-dev] Unbounded channels: Good idea/bad idea?

2013-12-25 Thread Tony Arcieri
> On Dec 25, 2013, at 12:08 PM, james wrote: > Really? It just decides to start messaging for no reason and blows up, after > no external stimulus? Not even a timer? Well, if that's what you meant, then your point is valid but a bit silly, because useful systems will generally have non-message

Re: [rust-dev] Unbounded channels: Good idea/bad idea?

2013-12-25 Thread james
On 25/12/2013 18:55, Tony Arcieri wrote: On Wed, Dec 25, 2013 at 2:14 AM, james > wrote: Can I point out that flow control isn't necessarily just back to the immediate producer? It is relatively unusual to have a system that spontaneously exp

Re: [rust-dev] Unbounded channels: Good idea/bad idea?

2013-12-25 Thread Tony Arcieri
On Wed, Dec 25, 2013 at 2:14 AM, james wrote: > Can I point out that flow control isn't necessarily just back to the > immediate producer? > > It is relatively unusual to have a system that spontaneously explodes > through > internal messaging. This isn't true at all. I've helped many people de

Re: [rust-dev] Unbounded channels: Good idea/bad idea?

2013-12-25 Thread Carter Schonwald
I'm not sure if that's how ghc channels work. I seem to recall that the main ones are using STM, though I think there's an MVAr one. There's some differences in semantics for the two. On Wednesday, December 25, 2013, Benjamin Herr wrote: > On Tue, 2013-12-24 at 18:48 -0800, Patrick Walton wrot

Re: [rust-dev] Unbounded channels: Good idea/bad idea?

2013-12-25 Thread Benjamin Herr
On Tue, 2013-12-24 at 18:48 -0800, Patrick Walton wrote: > Haskell may be a nice thing to look at here: the unbounded channel is > the primitive, and bounded channels are built on top of unbounded ones > using an `MVar` to rate limit. Such a thing could be easily built in > Rust using a channel

Re: [rust-dev] Unbounded channels: Good idea/bad idea?

2013-12-25 Thread james
On 25/12/2013 01:45, Daniel Micay wrote: Unbounded channels don't provide a way to write robust systems without layering on application-level message passing and book-keeping. Can I point out that flow control isn't necessarily just back to the immediate producer? It is relatively unusual to h