From loebel.marvin at gmail.com Sun Dec 1 03:06:01 2013 From: loebel.marvin at gmail.com (=?ISO-8859-1?Q?Marvin_L=F6bel?=) Date: Sun, 01 Dec 2013 12:06:01 +0100 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <529ACC40.2020705@mozilla.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <372D35C9-5DEB-4669-9859-1693DFD2ACBA@sb.org> <529ACC40.2020705@mozilla.com> Message-ID: <529B1819.7040601@gmail.com> On 12/01/2013 06:42 AM, Patrick Walton wrote: > On 11/30/13 6:49 PM, Corey Richardson wrote: >> I'll admit, I don't find the "confusing" argument very convincing. I >> just think `box` looks better than `~`. > > I'm warming up to this idea -- `box 10` does make more sense than `new > 10`. > > Patrick Thinking about it, `box` indeed seems like a good compromise to me: - It is as short as `new`, and more verbose than `~`, which is good. - It is a infrequently used word in source code. - It is syntactically used like `new` of other languages, which makes it better recognizable as such. - But it has a completely different semantic than, say, `C++`s `new`, justifying the different name. - The box metaphor might also make documentation about custom smart pointers, and the deref operator easier. From dteller at mozilla.com Sun Dec 1 03:11:46 2013 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Sun, 01 Dec 2013 12:11:46 +0100 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <529ACC40.2020705@mozilla.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <372D35C9-5DEB-4669-9859-1693DFD2ACBA@sb.org> <529ACC40.2020705@mozilla.com> Message-ID: <529B1972.8050902@mozilla.com> I like it. Cheers, David On 12/1/13 6:42 AM, Patrick Walton wrote: > I'm warming up to this idea -- `box 10` does make more sense than `new 10`. > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- David Rajchenbach-Teller, PhD Performance Team, Mozilla From asb at asbradbury.org Sun Dec 1 03:19:46 2013 From: asb at asbradbury.org (Alex Bradbury) Date: Sun, 1 Dec 2013 11:19:46 +0000 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <372D35C9-5DEB-4669-9859-1693DFD2ACBA@sb.org> <529ACC40.2020705@mozilla.com> Message-ID: On 1 December 2013 06:01, Benjamin Striegel wrote: > Eh, I'm as fine with `box` as I am with `new`. Does seem a bit like jargon, > though. Though maybe it will herald a return to the days when we really > played up the "shipping container" flavor. Crates and cargo, anyone? :) I think it's reasonable to expect people new to Rust (being an advanced systems-level language) to spend 15-20 minutes reading a tutorial. Given that, I think the target for syntax or keywords is that they're meaningful to people who have learnt the basic principles of Rust. I think that 'box' is much more meaningful than 'new' in that context, and rather more descriptive of the purpose. Alex From gaetan at xeberon.net Sun Dec 1 03:43:29 2013 From: gaetan at xeberon.net (Gaetan) Date: Sun, 1 Dec 2013 12:43:29 +0100 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <529B1972.8050902@mozilla.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <372D35C9-5DEB-4669-9859-1693DFD2ACBA@sb.org> <529ACC40.2020705@mozilla.com> <529B1972.8050902@mozilla.com> Message-ID: "box" as a keyword/reserved word is great, semantically speaking. And it is logically linked to the box concept introduced by the language. Le 1 d?c. 2013 12:11, "David Rajchenbach-Teller" a ?crit : > I like it. > > Cheers, > David > > On 12/1/13 6:42 AM, Patrick Walton wrote: > > > I'm warming up to this idea -- `box 10` does make more sense than `new > 10`. > > > > Patrick > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.spir at gmail.com Sun Dec 1 05:04:45 2013 From: denis.spir at gmail.com (spir) Date: Sun, 01 Dec 2013 14:04:45 +0100 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <529A963E.5030101@babelmonkeys.de> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> Message-ID: <529B33ED.6080807@gmail.com> On 12/01/2013 02:51 AM, Florian Zeitz wrote: > If I may chime in here. > I agree with Kevin that the different semantics of `new` are more likely > to create confusion, than alleviate it. > > Personally I would suggest calling this operator `box`, since it "boxes" > its argument into a newly allocated memory box. > > After all, these are different semantics from C++'s `new` (and also Go's > `make` AFAICT), therefore, presuming that a sigil is not a sufficient > indicator of a non-stack allocation, using an unprecedented keyword > seems the way to go to me. +++ to all 3 points Denis From denis.spir at gmail.com Sun Dec 1 05:54:16 2013 From: denis.spir at gmail.com (spir) Date: Sun, 01 Dec 2013 14:54:16 +0100 Subject: [rust-dev] do In-Reply-To: References: Message-ID: <529B3F88.9010204@gmail.com> On 12/01/2013 04:35 AM, Brendan Zabarauskas wrote: > On 30 Nov 2013, at 5:34 pm, Oren Ben-Kiki wrote: > >> I find `do` syntax form is vital for DSL-ish code. Getting rid of it makes a lot of code look downright ugly. I'd rather it used a more Ruby-ish notation though, I find that putting the `do` far away from the `{ ... }` doesn't read well. `foo(....) do |...| { ... }` would have made more sense for me (think of `do` as a macro-ish binary operation injecting the proc into the function on the left). But the current form is acceptable > > This really is an important point. I would recommend folks look at Shoes (http://shoesrb.com/) for an example of how Ruby?s block syntax can help create beautiful APIs. Ruby has no macros, has it? Denis From tkuehn at cmu.edu Sun Dec 1 06:06:26 2013 From: tkuehn at cmu.edu (Tim Kuehn) Date: Sun, 1 Dec 2013 09:06:26 -0500 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <529B33ED.6080807@gmail.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: On Sun, Dec 1, 2013 at 8:04 AM, spir wrote: > On 12/01/2013 02:51 AM, Florian Zeitz wrote: > >> If I may chime in here. >> I agree with Kevin that the different semantics of `new` are more likely >> to create confusion, than alleviate it. >> >> Personally I would suggest calling this operator `box`, since it "boxes" >> its argument into a newly allocated memory box. >> >> After all, these are different semantics from C++'s `new` (and also Go's >> `make` AFAICT), therefore, presuming that a sigil is not a sufficient >> indicator of a non-stack allocation, using an unprecedented keyword >> seems the way to go to me. >> > > +++ to all 3 points > > Denis > I, too, am in favor of the `box` proposal. Short, intuitive, not already commonly used. What's not to like? Cheers, Tim _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiffany at stormbit.net Sun Dec 1 06:31:01 2013 From: tiffany at stormbit.net (Tiffany Bennett) Date: Sun, 1 Dec 2013 09:31:01 -0500 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: I agree with the `box` name, it's far less jarring than `new (1+1)`. On Sun, Dec 1, 2013 at 9:06 AM, Tim Kuehn wrote: > On Sun, Dec 1, 2013 at 8:04 AM, spir wrote: > >> On 12/01/2013 02:51 AM, Florian Zeitz wrote: >> >>> If I may chime in here. >>> I agree with Kevin that the different semantics of `new` are more likely >>> to create confusion, than alleviate it. >>> >>> Personally I would suggest calling this operator `box`, since it "boxes" >>> its argument into a newly allocated memory box. >>> >>> After all, these are different semantics from C++'s `new` (and also Go's >>> `make` AFAICT), therefore, presuming that a sigil is not a sufficient >>> indicator of a non-stack allocation, using an unprecedented keyword >>> seems the way to go to me. >>> >> >> +++ to all 3 points >> >> Denis >> > > > I, too, am in favor of the `box` proposal. Short, intuitive, not > already commonly used. What's not to like? > > Cheers, > Tim > > > > > > > _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadimcn at gmail.com Sun Dec 1 07:42:35 2013 From: vadimcn at gmail.com (Vadim) Date: Sun, 1 Dec 2013 09:42:35 -0600 Subject: [rust-dev] do In-Reply-To: <3f2ecdb6-e0f5-43b0-85bf-81a1d4c2cb5f@email.android.com> References: <1385821232.12948.12.camel@vigil> <529A281E.2070508@mozilla.com> <529A2C53.90001@mozilla.com> <6D2F0314-68F4-4AA9-BE83-7F00F35E569E@sb.org> <529A5D94.6090901@mozilla.com> <3f2ecdb6-e0f5-43b0-85bf-81a1d4c2cb5f@email.android.com> Message-ID: <-8934270828636593044@unknownmsgid> Once fn()'s should consume their environment, perhaps it should be simply "self", where Self is non-copyable, so it gets moved out? On Nov 30, 2013, at 4:21 PM, Patrick Walton wrote: It's also not clear to me how "&once fn" can decompose into a trait in the future. The goal in the future is to make "fn()" a type of trait, to allow for C++-like zero-indirection closures. The different types of functions that we have today correspond to different "self" parameters: "|A|->B" corresponds to "&mut self" and "proc()" corresponds to "~self". But I don't see where "&once fn" fits in. Perhaps the right thing is to gate "&once fn" on by-value anonymous closures. I think once functions may be able to be made to work as function trait bounds. But implementing "&once fn" right now seems to close off our ability to have closures with the same efficiency as C++11 in the future, unless there's something I'm missing. Patrick Patrick Walton wrote: > > On 11/30/13 12:04 PM, Oren Ben-Kiki wrote: > >> Just to mention in passing - there's a related principle that converting >> a block to a closure shouldn't change its semantics. This obviously >> doesn't fully work because of return/break/continue; that said, if a >> block without such flow control constructs is wrapped into a closure, >> you'd expect it to just work. It doesn't, because to work it would have >> to be a once-called-stack-allocated lambda, which Rust doesn't have (I >> don't get the reason for that either :-) > > > If you decompose into a lambda plus the tupled set of upvars which it's > moving out of, then this respects TCP. > > Patrick > > ------------------------------ > > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.delrieu at free.fr Sun Dec 1 09:28:52 2013 From: philippe.delrieu at free.fr (Philippe Delrieu) Date: Sun, 01 Dec 2013 18:28:52 +0100 Subject: [rust-dev] Problem to use Encodable as fn parameter In-Reply-To: <5298916A.8040105@gmail.com> References: <52972F3D.6010901@free.fr> <52984FE1.80505@free.fr> <529880BA.2090006@free.fr> <52988F48.6010407@free.fr> <5298916A.8040105@gmail.com> Message-ID: <529B71D4.9000603@free.fr> I see the PR has been approved to I try to implements the method 'pub fn buffer_encode>(to_encode_object: &T) -> ~[u8]' and I have this error : "error: wrong number of lifetime parameters: expected 1 but found 0" and indicate the Encoder type. I have another question. I try to understand the modification on json.rs and function declaration has changed from : impl serialize::Encoder for Encoder to: impl<'self> serialize::Encoder for Encoder<'self> or pub fn init<'a>(wr: &'a mut io::Writer) -> Encoder<'a> instead of pub fn new(wr: &mut io::Writer) -> Encoder Could you explain me the difference if you don't mind. Philippe Le 29/11/2013 14:06, Huon Wilson a ?crit : > Yes; wait for Erick to submit the PR that fixes extra::json to use > &mut Writer rather than @mut Writer, so that one can write something like > > pub fn buffer_encode>(to_encode_object: &T) -> > ~[u8] { > let mut m = MemWriter::new(); > { // I think this scope is necessary to restrict the borrows > let mut encoder = Encoder(&mut m as &mut Writer); > to_encode_object.encode(&mut encoder); > } > m.inner() > } > > One is then just moving the `~[u8]` around without copying all the > elements. > > Also, `str_encode` shouldn't need to do any additional copies, even > right now, since the `std::str::from_utf8_owned` function exists. > (`from_utf8` is bad with its implicit and normally unnecessary copy, > I've got https://github.com/mozilla/rust/pull/10701 open that removes > that function for that reason.) > > > (Tangentially (and a genuine question), do we really need these > functions in extra::json (assuming this is part of the plan)? How > often does one need to encode to a buffer or string, rather than to > stdout, a file or network socket, which can be done by writing > directly to the corresponding writers.) > > Huon > > > On 29/11/13 23:57, Philippe Delrieu wrote: >> I try to implement the two methods and I have a problem with the copy >> of memory. >> The first attempt : >> >> pub fn buffer_encode>(to_encode_object: &T) -> >> ~[u8] { >> //Serialize the object in a string using a writer >> let m = @mut MemWriter::new(); >> let mut encoder = Encoder(m as @mut Writer); >> to_encode_object.encode(&mut encoder); >> let buff:&~[u8] = m.inner_ref(); >> (buff.clone()) >> } >> >> pub fn str_encode>(to_encode_object: &T) -> ~str { >> let buff:~[u8] = buffer_encode(to_encode_object); >> str::from_utf8(*buff) >> } >> >> When I call str_encode I copy at least two times the content of the >> MemWriter buffer (one inside clone and one inside from_utf8). >> If I implements str_encode like that >> >> pub fn str_encode>(to_encode_object: &T) -> ~str { >> let m = @mut MemWriter::new(); >> let mut encoder = Encoder(m as @mut Writer); >> to_encode_object.encode(&mut encoder); >> let buff:&~[u8] = m.inner_ref(); >> str::from_utf8(*buff) >> } >> >> I'll do at least one copy (one less than the other impl) but the code >> is copied. >> >> Is there a better way to manage pointer of memory across function calls? >> >> Philippe >> >> Le 29/11/2013 12:55, Philippe Delrieu a ?crit : >>> I made a remark about that on the GitHub pull request where the idea >>> was proposed. I'm agree with you. It's simplier to return a str or >>> perhaps a [u8] if it's use in a stream purpose. >>> I'm not very fan of creating a MemWriter and return it. >>> >>> I'll modify to add two functions: >>> pub fn str_encode>(to_encode_object: &T) -> ~str >>> pub fn buffer_encode>(to_encode_object: &T) -> >>> ~[u8] >>> >>> and remove the other. >>> >>> Any remaqs? >>> >>> Philippe >>> >>> >>> Le 29/11/2013 10:44, Gaetan a ?crit : >>>> >>>> I would prefere this function returns a str. >>>> >>>> Le 29 nov. 2013 09:27, "Philippe Delrieu" >>> > a ?crit : >>>> >>>> Thank you for the help. I've try this signature and I had an >>>> compile error. I thought it came from the signature but the >>>> problem when from the call. >>>> It works now. >>>> >>>> For the return type @mut MemWriter I work on the json doc and >>>> some example of use. I can make the change. I didn't find the >>>> issue about it. Did you create it? >>>> >>>> Philippe >>>> >>>> Le 28/11/2013 22:27, Erick Tryzelaar a ?crit : >>>>> Good afternoon Phillippe, >>>>> >>>>> Here's how to do it, assuming you're using rust 0.8 and the >>>>> json library: >>>>> >>>>> ``` >>>>> #[feature(managed_boxes)]; >>>>> >>>>> extern mod extra; >>>>> >>>>> use std::io::mem::MemWriter; >>>>> use extra::serialize::{Encoder, Encodable}; >>>>> use extra::json; >>>>> >>>>> pub fn memory_encode< >>>>> T: Encodable >>>>> >(to_encode_object: &T) -> @mut MemWriter { >>>>> //Serialize the object in a string using a writer >>>>> let m = @mut MemWriter::new(); >>>>> let mut encoder = json::Encoder(m as @mut Writer); >>>>> to_encode_object.encode(&mut encoder); >>>>> m >>>>> } >>>>> >>>>> fn main() { >>>>> } >>>>> ``` >>>>> >>>>> Regarding the trouble returning a `MemWriter` instead of a >>>>> `@mut MemWriter`, the easiest thing would be to fix library to >>>>> use `&mut ...` instead of `@mut ...`. I'll put in a PR to do that. >>>>> >>>>> >>>>> >>>>> On Thu, Nov 28, 2013 at 3:55 AM, Philippe Delrieu >>>>> > >>>>> wrote: >>>>> >>>>> I try to develop a function that take a Encodable >>>>> parameter but I have the error wrong number of type >>>>> arguments: expected 1 but found 0 >>>>> >>>>> pub fn memory_encode(to_encode_object: >>>>> &serialize::Encodable) -> @mut MemWriter { >>>>> //Serialize the object in a string using a writer >>>>> let m = @mut MemWriter::new(); >>>>> let mut encoder = Encoder(m as @mut Writer); >>>>> to_encode_object.encode(&mut encoder); >>>>> m >>>>> } >>>>> >>>>> The encodable trait is : >>>>> pub trait Encodable { >>>>> fn encode(&self, s: &mut S); >>>>> } >>>>> >>>>> I try this definition >>>>> memory_encode>(to_encode_object: >>>>> &T) -> @mut MemWriter >>>>> >>>>> But I can't use the method with a struct that implement >>>>> Encodable. The error : mismatched types: expected `&` >>>>> but found .. >>>>> >>>>> I have another question : >>>>> I would like to return a MemWriter and not a @mut >>>>> MemWriter . I didn't find a way to convert the @mut to ~ >>>>> >>>>> Philippe Delrieu >>>>> _______________________________________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Sun Dec 1 11:22:14 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Sun, 01 Dec 2013 11:22:14 -0800 Subject: [rust-dev] do In-Reply-To: <-8934270828636593044@unknownmsgid> References: <1385821232.12948.12.camel@vigil> <529A281E.2070508@mozilla.com> <529A2C53.90001@mozilla.com> <6D2F0314-68F4-4AA9-BE83-7F00F35E569E@sb.org> <529A5D94.6090901@mozilla.com> <3f2ecdb6-e0f5-43b0-85bf-81a1d4c2cb5f@email.android.com> <-8934270828636593044@unknownmsgid> Message-ID: <529B8C66.1010804@mozilla.com> On 12/1/13 7:42 AM, Vadim wrote: > Once fn()'s should consume their environment, perhaps it should be > simply "self", where Self is non-copyable, so it gets moved out? Doesn't work unless we have unboxed closures, as you can't call a method that takes `self` on `&T`. Patrick From ptalbot at hyc.io Sun Dec 1 12:14:22 2013 From: ptalbot at hyc.io (Pierre Talbot) Date: Sun, 01 Dec 2013 21:14:22 +0100 Subject: [rust-dev] Ideas of small projects or improvements In-Reply-To: References: <529A3174.8060701@hyc.io> Message-ID: <529B989E.9080509@hyc.io> The for-loop and the nested function declaration are both interesting and I'll let you know which one I choose after further investigation in the Rust compiler. If some of you have other ideas, please do not hesitate. Best regards, Pierre Talbot On 11/30/2013 08:24 PM, Benjamin Striegel wrote: > Currently our `for` loops are implemented strangely. In essence, right > now a `for` loop is just syntax sugar that gets expanded during the > parsing stage. This was easy to implement, but it means that our error > messages around `for` loops are strange and it limits our ability to > do more intelligent things, like so: > > for i in [1,2,3] { // currently we can't do this, you need to > write out `[1,2,3].iter()` > > If you could implement `for` loops in the "proper" way, it would be a > great boon to us. However, I'm not the one who really knows exactly > what the "proper" way is. :) And I wasn't able to find an issue in the > bug tracker for this with any details. Perhaps Daniel Micay (strcat) > could elaborate. > > > On Sat, Nov 30, 2013 at 1:41 PM, Pierre Talbot > wrote: > > Hello folks, > > I'm a French student finishing his study this year and a teacher > gave us a project to finish by the end of the year which is to > modify (or add) a small feature to an existing interpreter (or > compiler, language,...) such as a primitive or a control structure. > I'm pretty new to Rust and I wonder if you have some ideas, some > works that could possibly be useful to Rust, even if extremely > small. My objective is to get into Rust with this homework and > then work further on Rust later. > I can guess how much is hard to understand a compiler and start > working on it, and that's basically why I'm asking you for an > idea. I already worked on open-source projects (mainly in C++) so > I don't have much "outside lessons" to take (such as learning git). > > Do you have suggestions that could fit well for this kind of project? > > Best regards, > Pierre Talbot. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From hatahet at gmail.com Sun Dec 1 13:02:43 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Sun, 1 Dec 2013 13:02:43 -0800 Subject: [rust-dev] Ideas of small projects or improvements In-Reply-To: <529B989E.9080509@hyc.io> References: <529A3174.8060701@hyc.io> <529B989E.9080509@hyc.io> Message-ID: Isn't there a possibility that vector syntax is going to change at some point? -- Ziad On Sun, Dec 1, 2013 at 12:14 PM, Pierre Talbot wrote: > The for-loop and the nested function declaration are both interesting and > I'll let you know which one I choose after further investigation in the > Rust compiler. > > If some of you have other ideas, please do not hesitate. > > Best regards, > Pierre Talbot > > > On 11/30/2013 08:24 PM, Benjamin Striegel wrote: > >> Currently our `for` loops are implemented strangely. In essence, right >> now a `for` loop is just syntax sugar that gets expanded during the parsing >> stage. This was easy to implement, but it means that our error messages >> around `for` loops are strange and it limits our ability to do more >> intelligent things, like so: >> >> for i in [1,2,3] { // currently we can't do this, you need to write >> out `[1,2,3].iter()` >> >> If you could implement `for` loops in the "proper" way, it would be a >> great boon to us. However, I'm not the one who really knows exactly what >> the "proper" way is. :) And I wasn't able to find an issue in the bug >> tracker for this with any details. Perhaps Daniel Micay (strcat) could >> elaborate. >> >> >> On Sat, Nov 30, 2013 at 1:41 PM, Pierre Talbot > ptalbot at hyc.io>> wrote: >> >> Hello folks, >> >> I'm a French student finishing his study this year and a teacher >> gave us a project to finish by the end of the year which is to >> modify (or add) a small feature to an existing interpreter (or >> compiler, language,...) such as a primitive or a control structure. >> I'm pretty new to Rust and I wonder if you have some ideas, some >> works that could possibly be useful to Rust, even if extremely >> small. My objective is to get into Rust with this homework and >> then work further on Rust later. >> I can guess how much is hard to understand a compiler and start >> working on it, and that's basically why I'm asking you for an >> idea. I already worked on open-source projects (mainly in C++) so >> I don't have much "outside lessons" to take (such as learning git). >> >> Do you have suggestions that could fit well for this kind of project? >> >> Best regards, >> Pierre Talbot. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jurily at gmail.com Sun Dec 1 13:23:52 2013 From: jurily at gmail.com (=?ISO-8859-1?Q?Gy=F6rgy_Andrasek?=) Date: Sun, 01 Dec 2013 22:23:52 +0100 Subject: [rust-dev] Ideas of small projects or improvements In-Reply-To: References: <529A3174.8060701@hyc.io> <529B989E.9080509@hyc.io> Message-ID: <529BA8E8.2060503@gmail.com> On 12/01/2013 10:02 PM, Ziad Hatahet wrote: > Isn't there a possibility that vector syntax is going to change at some > point? I believe the plan is to turn [] into a generic container syntax, and expose Vec as the vector type. No idea where I read that though. From ptalbot at hyc.io Sun Dec 1 13:33:34 2013 From: ptalbot at hyc.io (Pierre Talbot) Date: Sun, 01 Dec 2013 22:33:34 +0100 Subject: [rust-dev] Ideas of small projects or improvements In-Reply-To: <529BA8E8.2060503@gmail.com> References: <529A3174.8060701@hyc.io> <529B989E.9080509@hyc.io> <529BA8E8.2060503@gmail.com> Message-ID: <529BAB2E.6010603@hyc.io> This doesn't seem to be a small project :-) By the way, I'm not sure if this is a good idea in Rust, but we might provide two free functions begin and end taking sequence and returning iterators. Anything that can be understood in term of sequence would just need to have an overload of these functions and the for-based loop transformation would be easy to change. This idea just come from my experience in C++ and I'd be happy to know why it wouldn't apply in Rust. On 12/01/2013 10:23 PM, Gy?rgy Andrasek wrote: > On 12/01/2013 10:02 PM, Ziad Hatahet wrote: >> Isn't there a possibility that vector syntax is going to change at some >> point? > > I believe the plan is to turn [] into a generic container syntax, and > expose Vec as the vector type. No idea where I read that though. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From danielmicay at gmail.com Sun Dec 1 13:43:15 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 1 Dec 2013 16:43:15 -0500 Subject: [rust-dev] Ideas of small projects or improvements In-Reply-To: <529BAB2E.6010603@hyc.io> References: <529A3174.8060701@hyc.io> <529B989E.9080509@hyc.io> <529BA8E8.2060503@gmail.com> <529BAB2E.6010603@hyc.io> Message-ID: On Sun, Dec 1, 2013 at 4:33 PM, Pierre Talbot wrote: > This doesn't seem to be a small project :-) By the way, I'm not sure if this > is a good idea in Rust, but we might provide two free functions begin and > end taking sequence and returning iterators. Anything that can be understood > in term of sequence would just need to have an overload of these functions > and the for-based loop transformation would be easy to change. This idea > just come from my experience in C++ and I'd be happy to know why it wouldn't > apply in Rust. I don't understand why this would be a good thing. Ranges are a more modern implementation of iterators and are much more easily composed. Ranges are also trivially memory safe, and I doubt that split current/end iterators can provide memory safety with only references. From vadimcn at gmail.com Sun Dec 1 14:43:00 2013 From: vadimcn at gmail.com (Vadim) Date: Sun, 1 Dec 2013 16:43:00 -0600 Subject: [rust-dev] do In-Reply-To: <529B8C66.1010804@mozilla.com> References: <1385821232.12948.12.camel@vigil> <529A281E.2070508@mozilla.com> <529A2C53.90001@mozilla.com> <6D2F0314-68F4-4AA9-BE83-7F00F35E569E@sb.org> <529A5D94.6090901@mozilla.com> <3f2ecdb6-e0f5-43b0-85bf-81a1d4c2cb5f@email.android.com> <-8934270828636593044@unknownmsgid> <529B8C66.1010804@mozilla.com> Message-ID: <5914291575612352126@unknownmsgid> Not sure what you mean by "`self` on `&T`". I thought traits can take self by-value? On Dec 1, 2013, at 1:22 PM, Patrick Walton wrote: > On 12/1/13 7:42 AM, Vadim wrote: >> Once fn()'s should consume their environment, perhaps it should be >> simply "self", where Self is non-copyable, so it gets moved out? > > Doesn't work unless we have unboxed closures, as you can't call a method that takes `self` on `&T`. > > Patrick > From ecreed at cs.washington.edu Mon Dec 2 00:43:52 2013 From: ecreed at cs.washington.edu (Eric Reed) Date: Mon, 2 Dec 2013 00:43:52 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: I think the 'new(place) expr' or 'box(place) expr' is pretty confusing syntax. To me, it's not at all clear that "new(varA) varB" means "eval varB and put it into varA" instead of "eval varA and put it into varB". I'd much prefer syntax that makes it very clear which is the expression and which is the place. Personally, I like ~ so I'd like "~expr in place", but if people absolutely insist on scrapping ~ then I'd suggest "put expr in place". In either case, I think keeping ~ as sugar for allocating on the exchange heap would be nice (i.e. "~expr" is sugar for "~expr in Unique" or "put expr in Unique"). I guess we could use "new" or "box" instead of "put", but I like "put" over either. On Sun, Dec 1, 2013 at 6:31 AM, Tiffany Bennett wrote: > I agree with the `box` name, it's far less jarring than `new (1+1)`. > > > On Sun, Dec 1, 2013 at 9:06 AM, Tim Kuehn wrote: > >> On Sun, Dec 1, 2013 at 8:04 AM, spir wrote: >> >>> On 12/01/2013 02:51 AM, Florian Zeitz wrote: >>> >>>> If I may chime in here. >>>> I agree with Kevin that the different semantics of `new` are more likely >>>> to create confusion, than alleviate it. >>>> >>>> Personally I would suggest calling this operator `box`, since it "boxes" >>>> its argument into a newly allocated memory box. >>>> >>>> After all, these are different semantics from C++'s `new` (and also Go's >>>> `make` AFAICT), therefore, presuming that a sigil is not a sufficient >>>> indicator of a non-stack allocation, using an unprecedented keyword >>>> seems the way to go to me. >>>> >>> >>> +++ to all 3 points >>> >>> Denis >>> >> >> >> I, too, am in favor of the `box` proposal. Short, intuitive, not >> already commonly used. What's not to like? >> >> Cheers, >> Tim >> >> >> >> >> >> >> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Mon Dec 2 00:56:48 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Mon, 2 Dec 2013 00:56:48 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: On Mon, Dec 2, 2013 at 12:43 AM, Eric Reed wrote: > In either case, I think keeping ~ as sugar for allocating on the exchange > heap would be nice (i.e. "~expr" is sugar for "~expr in Unique" or "put > expr in Unique"). > `box expr in place` reads nicely too. I don't know about any ambiguity in the syntax though. -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From asb at asbradbury.org Mon Dec 2 01:00:35 2013 From: asb at asbradbury.org (Alex Bradbury) Date: Mon, 2 Dec 2013 09:00:35 +0000 Subject: [rust-dev] do In-Reply-To: References: <529AACCB.9060101@mozilla.com> <8C23930B-9603-48D2-8B7E-495DD32D2B13@sb.org> Message-ID: On 1 December 2013 03:54, Daniel Micay wrote: > I don't understand the point of `do` beyond making zero-parameter > closures look a bit better. If it doesn't even do that, why bother? If > an editor isn't indenting it properly, that's an editor issue. As far > as I can tell, the vim indent file now handles it fine. I agree, I feel do should be considered for removal - I feel the amount of sugar it provides is minimal yet it complicates the language unnecessarily. Supposing that Rust did not have the `do` syntax already, I tend to think there would be resistance to adding it for these reasons. Is there currently an issue open regarding the future of `do`? Alex From gaetan at xeberon.net Mon Dec 2 01:16:08 2013 From: gaetan at xeberon.net (Gaetan) Date: Mon, 2 Dec 2013 10:16:08 +0100 Subject: [rust-dev] do In-Reply-To: References: <529AACCB.9060101@mozilla.com> <8C23930B-9603-48D2-8B7E-495DD32D2B13@sb.org> Message-ID: if "do" makes the code more readable or more "beautiful", I higly recommend keeping this sugar syntax. If there are corner cases where do doesn't do the job, the developer should not use it in these cases. It's still the same debat, when GIMP had this ugly multi panels system, developers was saying it is a window manager issue to handle them correctly. Yet, the GIMP software was a nightmare to use on almost everybody's desktop. Now they solved with a single window application, it is much more acceptable. It will be the same here. If you rely on special feature of the editor to indent properly. if is was only curly brace, most editor would do indentation properly, but here you have || and other exotic syntax most editor doesn't understand until a proper extension is written (which can take year for some editors). I personnally will always find much more readable (and maintainable): do function { someotherFunction() }; than function(|| someotherFunction()); ----- Gaetan 2013/12/2 Alex Bradbury > On 1 December 2013 03:54, Daniel Micay wrote: > > I don't understand the point of `do` beyond making zero-parameter > > closures look a bit better. If it doesn't even do that, why bother? If > > an editor isn't indenting it properly, that's an editor issue. As far > > as I can tell, the vim indent file now handles it fine. > > I agree, I feel do should be considered for removal - I feel the > amount of sugar it provides is minimal yet it complicates the language > unnecessarily. Supposing that Rust did not have the `do` syntax > already, I tend to think there would be resistance to adding it for > these reasons. Is there currently an issue open regarding the future > of `do`? > > Alex > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecreed at cs.washington.edu Mon Dec 2 01:25:32 2013 From: ecreed at cs.washington.edu (Eric Reed) Date: Mon, 2 Dec 2013 01:25:32 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: I don't think it introduces any ambiguity. The optional "in" is similar to the optional "else" in "if". I'm pretty sure this grammar would suffice: alloc_expr : "~" expr in_tail ? ; in_tail : "in" expr ; The expr of in_tail would need to be considered a 'place' (some sort of trait I assume) by the typechecker. Ending in_tail with an expr shouldn't be a problem (lambda_expr does it). The parser can unambiguously tell if there is an in_tail present by simply checking for the "in" keyword. On Mon, Dec 2, 2013 at 12:56 AM, Ziad Hatahet wrote: > On Mon, Dec 2, 2013 at 12:43 AM, Eric Reed wrote: > >> In either case, I think keeping ~ as sugar for allocating on the exchange >> heap would be nice (i.e. "~expr" is sugar for "~expr in Unique" or "put >> expr in Unique"). >> > > `box expr in place` reads nicely too. I don't know about any ambiguity in > the syntax though. > > -- > Ziad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From com.liigo at gmail.com Mon Dec 2 02:06:07 2013 From: com.liigo at gmail.com (Liigo Zhuang) Date: Mon, 2 Dec 2013 18:06:07 +0800 Subject: [rust-dev] This Week in Rust In-Reply-To: References: Message-ID: great work 2013/12/1 Corey Richardson > Welcome to another issue of *This Week in Rust*, a weekly newsletter > summarizing Rust's progress and community activity. As always, if you have > something you'd like to be featured, just [send me an > email](mailto:corey at octayn.net?subject=This Week in Rust Suggestion). > > Last week was very slow, but this week more than makes up for it I think! > Static linking landed, and there's been some nice cleanup of error messages > and various APIs. > > # What's cooking on master? > > 59 PRs were merged this week. > > ## Breaking Changes > > - Names of methods creating iterators have [changed > drastically](https://github.com/mozilla/rust/pull/10622) to remove the > `_iter` suffix. This reflects that iterators are a primary focus of APIs. > The PR description has all of the changes summarized. > - We now have [static linking > support](https://github.com/mozilla/rust/pull/10528)! It does, however, > involve some changes with how the `link` attribute works. The error > messages > should guide you to the fixes. > - In preparation for the placement new changes, the `Path` constructor has > been [renamed from `new` to > `init`](https://github.com/mozilla/rust/pull/10697),. > - Some overly-permissive borrow checking for `&mut &mut` [has been > fixed](https://github.com/mozilla/rust/pull/10519). This is fairly > obscure, > most code shouldn't have hit it. > - The parser is [more strict](https://github.com/mozilla/rust/pull/10642) > about what it accepts as a doc comment. Now, only `///` and `/**` are > counted as introducing doc comments (previously, `////` and `/***` would > also introduce a doc comment). > - `std::{uint, int}::{min, max}` [have been > removed](https://github.com/mozilla/rust/pull/10719). They were > identical to > the functions in `std::cmp`, so use those instead. > - `extra::json` [has been rid of @ > boxes](https://github.com/mozilla/rust/pull/10727), and now uses > idiomatic > constructor names. > - The `type_id` intrinsic [now uses a language item as its return > value](https://github.com/mozilla/rust/pull/10722). > - Some [cleanup](https://github.com/mozilla/rust/pull/10662) has been > done to > `std::rt::thread`, which is an interface to native threads (rather than > tasks). > - `do` blocks are [no longer > allowed](https://github.com/mozilla/rust/pull/10581) in non-`proc` > contexts. > This means that `do` can not be used with a function whose last argument > is > not a `proc`. A fairly large [thread on the mailing > list]( > https://mail.mozilla.org/pipermail/rust-dev/2013-November/006999.html) > is ongoing about this change. > - `LittleLock` now [uses RAII](https://github.com/mozilla/rust/pull/10660 > ). > - C-like enums are [now represented as an > integer](https://github.com/mozilla/rust/pull/10652) rather than a > struct, > at the LLVM level. This affects ABI. > - Linked failure [has been > removed](https://github.com/mozilla/rust/pull/10603) from the runtime. > - `extra::term` [no longer uses `@mut > Writer`](https://github.com/mozilla/rust/pull/10637), instead taking the > writer to use by value. > > ## Other changes > > - `RefCell`, previously known as `Mut`, [has finally > landed](https://github.com/mozilla/rust/pull/10514), for all your > dynamic > borrow checking needs. > - A lint for unknown attributes [has finally been > added](https://github.com/mozilla/rust/pull/10316). The compiler will > now > warn when it sees an attribute it doesn't recognize. > - A lock-free [Chase-Lev > deque]( > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.1097&rep=rep1&type=pdf > ) > has [been added to the runtime]( > https://github.com/mozilla/rust/pull/10678). > - The shootout-spectralnorm benchmark [has been > resurrected](https://github.com/mozilla/rust/pull/10704). > - Unknown feature gates [are now > linted](https://github.com/mozilla/rust/pull/10680), rather than being a > hard failure. > - The AST is [now frozen](https://github.com/mozilla/rust/pull/10693)! > - `GenericPort` [now has an > iterator](https://github.com/mozilla/rust/pull/10688) over the messages > it > receives. > - `NodeId`, `CrateNum`, `Name`, and `Mrk` (types in libsyntax) [have been > shrunk to 32 bits](https://github.com/mozilla/rust/pull/10670). > - The restriction on macros expanding to a single item [has been > lifted](https://github.com/mozilla/rust/pull/10649). This obviates the > need > for macros hackily expanding to a module containing the desired items. Do > note that this only works when the macro is in "item position", or where > an > item is expected. There is an > [issue](https://github.com/mozilla/rust/issues/10681) open for lifting > this > restriction. > - A `thread_local` attribute [has been > added](https://github.com/mozilla/rust/pull/10312), which exposes a > platform's native TLS, a la C11/C++11 `thread_local`. > - Cross compilation to win64 (via mingw-w64) [is now > supported](https://github.com/mozilla/rust/pull/10578). There were also > a > [bunch of fixes](https://github.com/mozilla/rust/pull/10631) on real > win64. > - The parser gives a [better error > message](https://github.com/mozilla/rust/pull/10641) when it encounters > an > unclosed delimiter it didn't expect. > - There is a [better error > message](https://github.com/mozilla/rust/pull/10475) when a module name > is > used as a type (the motivating example being `impl SomeTrait for > some_module`). > - JSON decoding [now gives better > errors](https://github.com/mozilla/rust/pull/10625). > - Linker optimizations are [now > used](https://github.com/mozilla/rust/pull/10620) on Linux. > > ## New contributors > > Our first-time contributors this week are: > > - Andreas Ots > - Eric Biggers > - Jannis Harder > - Kiet Tran > > # Weekly Meeting > > The [weekly > meeting](https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-11-26) > discussed bootstrap times, the `thread_local` PR, mutexes, and the GC. In > particular, it was decided that we should have nightlies. > > # This Week in Servo > > Servo is a web browser engine written in Rust and is one of the primary > test > cases for the Rust language. > > This was a short week due to the US Thanksgiving holiday, but there were > still > 17 landed PRs this week. > > ## Notable additions > - Hyunjune Kim and Sammy Kim landed some border style extensions in > [#1276](http://github.com/mozilla/servo/pull/1322). > - Youngmin Yoo, Seonghyun Kim, and Jaemin Moon landed overflow:hidden in > [#1298](http://github.com/mozilla/servo/pull/1298). > - Isabelle Carter landed changing the unrendered portion of content to use > the > doc's background color in [#1210]( > http://github.com/mozilla/servo/pull/1210). > - Patrick Walton has been experimenting with some very promising parallel > layout work, which he described in a > [message]( > https://groups.google.com/forum/#!topic/mozilla.dev.servo/1nKmBvFewIs) > to the mailing list. > > ## Meetings > > This week's [meeting]( > https://github.com/mozilla/servo/wiki/Meeting-2013-11-25) > covered the poor situation with Nvidia support on Linux, fleshed out the > string > interning plan during CSS selector parsing/matching, and went into some > Servo > and Rust-related build issues. > > # Announcements etc > > Do note that all the links are pulled directly from the > [subreddit](https://reddit.com/r/rust). > > - [Matrix Multiply Performance in > Rust]( > http://www.reddit.com/r/rust/comments/1rf8rz/matrix_multiply_performance_in_rust/ > ) > - [nrays](https://github.com/sebcrozet/nrays) - a 3d/4d raytracer > - [SprocketNES: Practical Systems Programming in > Rust]( > https://air.mozilla.org/sprocketnes-practical-systems-programming-in-rust/ > ). > Contrary to the title, this is actually a recording of the presentations > at > the Bay Area meetup. > - [uutils](https://github.com/uutils/coreutils) - an attempt at writing > universal (as in cross-platform) CLI utils in Rust > - [lbac](https://github.com/cmr/lets-build-a-compiler) - a Rust port of > Jack > Crenshaw's "Let's Build a Compiler" > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeti789 at web.de Mon Dec 2 02:12:39 2013 From: jeti789 at web.de (jeti789 at web.de) Date: Mon, 2 Dec 2013 11:12:39 +0100 (CET) Subject: [rust-dev] Can traits define instance vars? Message-ID: An HTML attachment was scrubbed... URL: From ecreed at cs.washington.edu Mon Dec 2 02:31:55 2013 From: ecreed at cs.washington.edu (Eric Reed) Date: Mon, 2 Dec 2013 02:31:55 -0800 Subject: [rust-dev] Can traits define instance vars? In-Reply-To: References: Message-ID: Hi Oliver, Glad you're liking Rust so far :) Currently traits can only have methods (functions that have a self parameter) and associated functions (functions without a self parameter). There's a proposal to add inheritance on structs to Rust, which would allow a trait to extend a struct and gain access to its fields. This (very) long mailing list threadis the most recent discussion I'm aware of. There are a couple ideas in there about how to get similar behavior using just existing Rust constructs (I'm still biased towards the solution I gave in there). I'm not aware of any plans for a rust-users forum. Maybe spinning a rust-users mailing list off from rust-dev would make sense? We already did a similar thing with our IRC channels. Eric On Mon, Dec 2, 2013 at 2:12 AM, wrote: > Hello, > > I lately had a look at Rust and really liked it in many ways. Rust has > really everything I'm missing in Go ;-). There is something about traits I > would like to ask I can't see from the manual. Question is whether you > define instance variables in traits or abstract variables like Ceylon and > Kotlin have them. Abstract traits vars in Kotlin look like this (sample > code taken from here: > http://blog.jetbrains.com/kotlin/2011/08/multiple-inheritance-part-2-possible-directions > ): > > trait Trait { > val property : Int // abstract > fun foo() { > print(property) > } > } > class C() : Trait { > override val property : Int = 239 > } > > Can something like this be done for traits in Rust as well? > > Then I would like to ask whether you are planning to have some Rust forum > for users. The question I was asking in this mail on rust-dev really > doesn't belong into the dev mailing list. So something like a google > Rust-users newsgroup would be a good thing to have. I know several people > that are interested in Rush. Think it would give Rust a little push if a > Rust-user forum would exist. > > Regards, Oliver > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Mon Dec 2 02:32:50 2013 From: kevin at sb.org (Kevin Ballard) Date: Mon, 2 Dec 2013 02:32:50 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: I think `box expr in place` is unnecessarily verbose. I also don't think `box(place) expr` will be confusing in practice, because it will presumably look something like `box(Gc) expr`, which should be pretty obvious that Gc is how it's being boxed, not what's being boxed. -Kevin > On Dec 2, 2013, at 12:43 AM, Eric Reed wrote: > > I think the 'new(place) expr' or 'box(place) expr' is pretty confusing syntax. To me, it's not at all clear that "new(varA) varB" means "eval varB and put it into varA" instead of "eval varA and put it into varB". > I'd much prefer syntax that makes it very clear which is the expression and which is the place. Personally, I like ~ so I'd like "~expr in place", but if people absolutely insist on scrapping ~ then I'd suggest "put expr in place". > In either case, I think keeping ~ as sugar for allocating on the exchange heap would be nice (i.e. "~expr" is sugar for "~expr in Unique" or "put expr in Unique"). > I guess we could use "new" or "box" instead of "put", but I like "put" over either. > > > >> On Sun, Dec 1, 2013 at 6:31 AM, Tiffany Bennett wrote: >> I agree with the `box` name, it's far less jarring than `new (1+1)`. >> >> >>> On Sun, Dec 1, 2013 at 9:06 AM, Tim Kuehn wrote: >>>> On Sun, Dec 1, 2013 at 8:04 AM, spir wrote: >>> >>>>> On 12/01/2013 02:51 AM, Florian Zeitz wrote: >>>>> If I may chime in here. >>>>> I agree with Kevin that the different semantics of `new` are more likely >>>>> to create confusion, than alleviate it. >>>>> >>>>> Personally I would suggest calling this operator `box`, since it "boxes" >>>>> its argument into a newly allocated memory box. >>>>> >>>>> After all, these are different semantics from C++'s `new` (and also Go's >>>>> `make` AFAICT), therefore, presuming that a sigil is not a sufficient >>>>> indicator of a non-stack allocation, using an unprecedented keyword >>>>> seems the way to go to me. >>>> >>>> +++ to all 3 points >>>> >>>> Denis >>> >>> >>> I, too, am in favor of the `box` proposal. Short, intuitive, not >>> already commonly used. What's not to like? >>> >>> Cheers, >>> Tim >>> >>> >>> >>> >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Mon Dec 2 02:57:02 2013 From: kevin at sb.org (Kevin Ballard) Date: Mon, 2 Dec 2013 02:57:02 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` -Kevin Ballard From ecreed at cs.washington.edu Mon Dec 2 03:09:42 2013 From: ecreed at cs.washington.edu (Eric Reed) Date: Mon, 2 Dec 2013 03:09:42 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: This is my new favorite idea, especially expr at place. It's concise. It reads "expr at place", which is exactly what it does. It goes along with Rust's putting the type after the value. "expr in place" could be good too. On Mon, Dec 2, 2013 at 2:57 AM, Kevin Ballard wrote: > With @ going away another possibility is to leave ~ as the normal > allocation operator and to use @ as the placement operator. So ~expr stays > the same and placement looks either like `@place expr` or `expr at place` > > -Kevin Ballard > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.spir at gmail.com Mon Dec 2 04:57:56 2013 From: denis.spir at gmail.com (spir) Date: Mon, 02 Dec 2013 13:57:56 +0100 Subject: [rust-dev] Can traits define instance vars? In-Reply-To: References: Message-ID: <529C83D4.4000200@gmail.com> On 12/02/2013 11:12 AM, jeti789 at web.de wrote: > Hello, > I lately had a look at Rust and really liked it in many ways. Rust has really > everything I'm missing in Go ;-). There is something about traits I would like > to ask I can't see from the manual. Question is whether you define instance > variables in traits or abstract variables like Ceylon and Kotlin have them. > Abstract traits vars in Kotlin look like this (sample code taken from here: > http://blog.jetbrains.com/kotlin/2011/08/multiple-inheritance-part-2-possible-directions): > trait Trait { > val property : Int // abstract > fun foo() { > print(property) > } > } > class C() : Trait { > override val property : Int = 239 > } > Can something like this be done for traits in Rust as well? > Then I would like to ask whether you are planning to have some Rust forum for > users. The question I was asking in this mail on rust-dev really doesn't belong > into the dev mailing list. So something like a google Rust-users newsgroup would > be a good thing to have. I know several people that are interested in Rush. > Think it would give Rust a little push if a Rust-user forum would exist. > Regards, Oliver I would love it. Of the 2 cases of custom traits I have defined do far in Rust, one is only about 3 instance vars (thus ends up empty), the other about 1 vars and 1 method (thus holds only the latter). I find traits weird without vars, and annoying since the compiler does not know that the conforming types _do_ have such vars (thus one is forced to down-cast for no other reason that vars are absent from the trait def, or do i miss a point?). This, in addition to control of actual conformity of types to declared traits. Denis From denis.spir at gmail.com Mon Dec 2 05:01:41 2013 From: denis.spir at gmail.com (spir) Date: Mon, 02 Dec 2013 14:01:41 +0100 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: <529C84B5.20405@gmail.com> On 12/02/2013 09:43 AM, Eric Reed wrote: > I think the 'new(place) expr' or 'box(place) expr' is pretty confusing > syntax. To me, it's not at all clear that "new(varA) varB" means "eval varB > and put it into varA" instead of "eval varA and put it into varB". > I'd much prefer syntax that makes it very clear which is the expression and > which is the place. Personally, I like ~ so I'd like "~expr in place", but > if people absolutely insist on scrapping ~ then I'd suggest "put expr in > place". > In either case, I think keeping ~ as sugar for allocating on the exchange > heap would be nice (i.e. "~expr" is sugar for "~expr in Unique" or "put > expr in Unique"). > I guess we could use "new" or "box" instead of "put", but I like "put" over > either. What about: box(place, expr) box(expr, place) # better for me box expr in/to place # pure syntactic magic ? The latter may seem weird, but anyway box or new or whatever aren't functions in the ordinary sense. Denis From denis.spir at gmail.com Mon Dec 2 05:07:13 2013 From: denis.spir at gmail.com (spir) Date: Mon, 02 Dec 2013 14:07:13 +0100 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: <529C8601.1060004@gmail.com> On 12/02/2013 11:57 AM, Kevin Ballard wrote: > With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` I like that, with expr at place. Does this give: let foo = ~ bar; let placed_foo = bar @ place; ? Yet another solution, just for fun, using the fact that pointers are supposed to "point to": let foo = -> bar; let placed_foo = bar -> place; Denis From pnkfelix at mozilla.com Mon Dec 2 05:49:55 2013 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Mon, 02 Dec 2013 14:49:55 +0100 Subject: [rust-dev] Error casting to trait: "value may contain borrowed pointers" In-Reply-To: References: Message-ID: <529C9003.10302@mozilla.com> rust-dev- In general, we need to ensure that for an expression ` as ` that any borrowed pointers in the type of are not obscured [1] by the cast. A collection of conditions sufficient to enforce this are listed in a comment in librustc/middle/kind.rs that I think is apropos here: https://github.com/mozilla/rust/blob/master/src/librustc/middle/kind.rs#L488 However, there are probably other conditions that would also suffice that we might add to that set. In particular, I do not see anything immediately wrong with your example; the type-expression `&'a V` should ensure that `V` does not contain any lifetimes that are shorter than 'a, and therefore it should be safe to cast `v: &'a V` to a `&'a T`. I have filed this as issue #10766 [2]. Cheers, -Felix [1] https://github.com/mozilla/rust/issues/5723 [2] https://github.com/mozilla/rust/issues/10766 On 30/11/2013 23:22, Christian Ohler wrote: > Hi all, > > I'm trying to learn rust and ran into an error message I don't > understand, and would appreciate some help. This code: > > trait T {} > > fn f<'a, V: T>(v: &'a V) -> &'a T { > v as &'a T > } > > > is rejected with this error message: > > trait-cast.rs:4:4: 4:5 error: value may contain borrowed pointers; add > `'static` bound > trait-cast.rs:4 v as &'a T > > > I'm trying to upcast from V to T so that I can put v in a container of > element type T (in code not shown here). The suggestion to add a > 'static bound doesn't sound like what I'm looking for. > > What is the concern about borrowed pointers here? What would an > implementation of T and a caller of f look like to lead to a safety > problem? > > I'm using a version of rust that is a few days old. > > Thanks, > Christian. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- irc: pnkfelix on irc.mozilla.org email: {fklock, pnkfelix}@mozilla.com From qwertie256 at gmail.com Mon Dec 2 08:21:19 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Mon, 2 Dec 2013 09:21:19 -0700 Subject: [rust-dev] Rust forum Message-ID: Hey, why not set up a Discourse forum? That would be so. much. better. than a mailing list. As an OSS dev I've been itching to get one myself, but don't have time or much money to set it up. For Mozilla, though? No problem I'm sure. http://www.discourse.org/ Google: discourse hosting. http://www.google.com/search?q=discourse+hosting From: Eric Reed > ... > I'm not aware of any plans for a rust-users forum. Maybe spinning a > rust-users mailing list off from rust-dev would make sense? We already did > a similar thing with our IRC channels. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sapin at exyr.org Mon Dec 2 08:26:51 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Mon, 02 Dec 2013 16:26:51 +0000 Subject: [rust-dev] Rust forum In-Reply-To: References: Message-ID: <529CB4CB.6010903@exyr.org> On 02/12/2013 16:21, David Piepgrass wrote: > That would be so. much. better. than a mailing list. Hi. Could you expand on this? I don?t necessarily disagree, but as the one proposing change it?s up to you to convince everyone else :) -- Simon Sapin From pnathan at vandals.uidaho.edu Mon Dec 2 08:29:56 2013 From: pnathan at vandals.uidaho.edu (Paul Nathan) Date: Mon, 2 Dec 2013 08:29:56 -0800 Subject: [rust-dev] Rust forum In-Reply-To: References: Message-ID: <529CB584.9000009@vandals.uidaho.edu> On 12/2/13 8:21 AM, David Piepgrass wrote: > Hey, why not set up a Discourse forum? That would be so. much. better. > than a mailing list. As an OSS dev I've been itching to get one myself, > but don't have time or much money to set it up. For Mozilla, though? No > problem I'm sure. > > http://www.discourse.org/ > Google: discourse hosting. > http://www.google.com/search?q=discourse+hosting > > > From: Eric Reed > > ... > I'm not aware of any plans for a rust-users forum. Maybe spinning a > rust-users mailing list off from rust-dev would make sense? We > already did > a similar thing with our IRC channels. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > FYI, I've used a Discourse forum, and I've found it rather obnoxious. Much prefer the PHPBB or OSQA approach. Mailing lists are, IMO, better (e.g., gpg works, attachments work, direct messaging comes built in). A rust-users mailing list would be nice. -- Regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 946 bytes Desc: OpenPGP digital signature URL: From pcwalton at mozilla.com Mon Dec 2 09:06:23 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Mon, 02 Dec 2013 09:06:23 -0800 Subject: [rust-dev] do In-Reply-To: References: <529AACCB.9060101@mozilla.com> <8C23930B-9603-48D2-8B7E-495DD32D2B13@sb.org> Message-ID: <529CBE0F.1080507@mozilla.com> On 12/2/13 1:16 AM, Gaetan wrote: > if "do" makes the code more readable or more "beautiful", I higly > recommend keeping this sugar syntax. If there are corner cases where do > doesn't do the job, the developer should not use it in these cases. The problem here is the closure inference, especially when custom smart pointers are concerned. Do you want the "do" syntax to start invoking arbitrary custom smart pointer constructors based on the type? Patrick From kevin at sb.org Mon Dec 2 10:15:31 2013 From: kevin at sb.org (Kevin Ballard) Date: Mon, 2 Dec 2013 10:15:31 -0800 Subject: [rust-dev] Rust forum In-Reply-To: <529CB584.9000009@vandals.uidaho.edu> References: <529CB584.9000009@vandals.uidaho.edu> Message-ID: On Dec 2, 2013, at 8:29 AM, Paul Nathan wrote: > On 12/2/13 8:21 AM, David Piepgrass wrote: >> Hey, why not set up a Discourse forum? That would be so. much. better. >> than a mailing list. As an OSS dev I've been itching to get one myself, >> but don't have time or much money to set it up. For Mozilla, though? No >> problem I'm sure. >> >> http://www.discourse.org/ >> Google: discourse hosting. >> http://www.google.com/search?q=discourse+hosting >> >> >> From: Eric Reed > > >> ... >> I'm not aware of any plans for a rust-users forum. Maybe spinning a >> rust-users mailing list off from rust-dev would make sense? We >> already did >> a similar thing with our IRC channels. >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > FYI, I've used a Discourse forum, and I've found it rather obnoxious. > Much prefer the PHPBB or OSQA approach. > > Mailing lists are, IMO, better (e.g., gpg works, attachments work, > direct messaging comes built in). > > A rust-users mailing list would be nice. Personally, I?ve never met a forum that I cared for. Mailing lists are nice. I second the idea of a rust-users ML. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Mon Dec 2 10:18:25 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 2 Dec 2013 13:18:25 -0500 Subject: [rust-dev] Type system thoughts In-Reply-To: References: Message-ID: <20131202181825.GG21938@Mr-Bennet> On Fri, Nov 15, 2013 at 05:05:28PM +0100, G?bor Lehel wrote: > The next few are going to be about higher- (or just different-) kinded > generics. To avoid confusion, I'm going to use "built-in trait" to mean > things like `Freeze` and `Send`, and "kind" to mean what it does everywhere > else in the non-Rustic world. OK, I read a bit more. I've been working on a blog post about "HKR" (higher-kinded Rust) and you've been elaborating on some of the same themes as I was thinking about (naturally enough). All makes sense. > One question with regards to higher-kinded traits is what to do about > methods and `self`. What syntax to use? Does it even make sense? For > syntax, I see two possibilities (snipping from the `fmap` signature): > - `self: &Self` > - `&self` I was leaning towards the former, but the latter does make sense too and would help to guide users into a more limited set of available options, which might be helpful. > trait Foldable for type Self { > fn fold(&self, init: &T, folder: |&T, &T| -> T) -> T; > } > > Then `&Foldable` is a trait object hiding any foldable container of > ints (for example `~[int]`). In the absence of an erased keyword, I think that higher-kinded traits and objects are simply incompatible. The situation is not as simple as you made it out, as the trait may itself have generic parameters of higher-kind. I think the thing to do, if you wanted an object type, would be to have an "adapter" trait: > trait Foldable1 { > fn fold(&self, init: &T, folder: |&T, &T| -> T) -> T; > } > > impl Foldable1 for T { > fn fold(&self, init: &T, folder: |&T, &T| -> T) -> T { > Foldable::fold(self, init, folder) > } > } > The other is the potential to abstract over traits. GHC does this with the > `ConstraintKinds` extension. (According to people who have implemented > Haskell compilers, it's actually easier to implement it than not to![1] > Which is pretty crazy.) I'm not sure this would be true for Rust, but perhaps. > There's two further issues that higher-kinded generics raise... This is as far as I got in this round. More later. :) Niko From niko at alum.mit.edu Mon Dec 2 10:19:31 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 2 Dec 2013 13:19:31 -0500 Subject: [rust-dev] RFC: Put Unicode identifiers behind a feature gate In-Reply-To: <528EE360.5070504@mozilla.com> References: <528EE360.5070504@mozilla.com> Message-ID: <20131202181931.GH21938@Mr-Bennet> I'm fine with this, but I wonder: will we ever have more opinion or information than we have now? Can we just survey what e.g. ES6 does and copy them? On Thu, Nov 21, 2013 at 08:53:52PM -0800, Patrick Walton wrote: > There are several issues in the backwards-compatible milestone > related to Unicode identifiers: > > #4928: XID_Start/XID_Continue might not be correct > #2253: Do NKFC normalization in lexer > > Given the extreme lack of use of Unicode identifiers and the fact > that we have much more pressing issues for 1.0, I propose putting > support for identifiers that don't match > /^(?:[A-Za-z][A-Za-z0-9]*|_[A-Za-z0-9]+)$/ behind a feature gate. > > Thoughts? > > Patrick > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From pwalton at mozilla.com Mon Dec 2 10:23:55 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 02 Dec 2013 10:23:55 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <529C8601.1060004@gmail.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> Message-ID: <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> Anything with @ feels like it goes too close to pointer sigils for my taste. Patrick spir wrote: >On 12/02/2013 11:57 AM, Kevin Ballard wrote: >> With @ going away another possibility is to leave ~ as the normal >allocation operator and to use @ as the placement operator. So ~expr >stays the same and placement looks either like `@place expr` or >`expr at place` > >I like that, with expr at place. Does this give: > let foo = ~ bar; > let placed_foo = bar @ place; >? > >Yet another solution, just for fun, using the fact that pointers are >supposed to >"point to": > > let foo = -> bar; > let placed_foo = bar -> place; > >Denis >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Mon Dec 2 10:45:01 2013 From: kevin at sb.org (Kevin Ballard) Date: Mon, 2 Dec 2013 10:45:01 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> Message-ID: <0C0089F8-C528-4056-9926-06BFEB15C49D@sb.org> What do you mean? This suggestion uses @ as an operator, not as a sigil. -Kevin On Dec 2, 2013, at 10:23 AM, Patrick Walton wrote: > Anything with @ feels like it goes too close to pointer sigils for my taste. > > Patrick > > spir wrote: > On 12/02/2013 11:57 AM, Kevin Ballard wrote: > With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` > > I like that, with expr at place. Does this give: > let foo = ~ bar; > let placed_foo = bar @ place; > ? > > Yet another solution, just for fun, using the fact that pointers are supposed to > "point to": > > let foo = -> bar; > let placed_foo = bar -> place; > > Denis > > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Mon Dec 2 10:46:32 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Mon, 2 Dec 2013 10:46:32 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> Message-ID: Is there any way we can use a method and move semantics for this? This feels pretty natural to me: let foo = gc_allocator.box(bar); On Mon, Dec 2, 2013 at 10:23 AM, Patrick Walton wrote: > Anything with @ feels like it goes too close to pointer sigils for my > taste. > > Patrick > > spir wrote: >> >> On 12/02/2013 11:57 AM, Kevin Ballard wrote: >> >>> With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` >> >> >> I like that, with expr at place. Does this give: >> let foo = ~ bar; >> let placed_foo = bar @ place; >> ? >> >> Yet another solution, just for fun, using the fact that pointers are supposed to >> "point to": >> >> let foo = -> bar; >> let placed_foo = bar -> place; >> >> Denis >> ------------------------------ >> >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecreed at cs.washington.edu Mon Dec 2 10:49:50 2013 From: ecreed at cs.washington.edu (Eric Reed) Date: Mon, 2 Dec 2013 10:49:50 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> Message-ID: But it's nothing like a pointer sigil. @ doesn't appear in the types at all. It's just the placement allocation operator. On Mon, Dec 2, 2013 at 10:23 AM, Patrick Walton wrote: > Anything with @ feels like it goes too close to pointer sigils for my > taste. > > Patrick > > spir wrote: >> >> On 12/02/2013 11:57 AM, Kevin Ballard wrote: >> >>> With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` >> >> >> I like that, with expr at place. Does this give: >> let foo = ~ bar; >> let placed_foo = bar @ place; >> ? >> >> Yet another solution, just for fun, using the fact that pointers are supposed to >> "point to": >> >> let foo = -> bar; >> let placed_foo = bar -> place; >> >> Denis >> ------------------------------ >> >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.spir at gmail.com Mon Dec 2 10:52:24 2013 From: denis.spir at gmail.com (spir) Date: Mon, 02 Dec 2013 19:52:24 +0100 Subject: [rust-dev] Rust forum In-Reply-To: References: <529CB584.9000009@vandals.uidaho.edu> Message-ID: <529CD6E8.2030707@gmail.com> On 12/02/2013 07:15 PM, Kevin Ballard wrote: > Personally, I?ve never met a forum that I cared for. Mailing lists are nice. > > I second the idea of a rust-users ML. Same for me. denis From ecreed at cs.washington.edu Mon Dec 2 11:01:08 2013 From: ecreed at cs.washington.edu (Eric Reed) Date: Mon, 2 Dec 2013 11:01:08 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> Message-ID: I think the idea was to have the syntax desugar into method calls just like other existing operators. There'd be a trait like: trait Box { fn box(val: T) -> Self } and something like "box expr in place" would desugar into "place::box(expr)". One question this poses is why are we requiring the "place" to be specified all the time? Why not let type inference handle deciding the "place" most of the time? On Mon, Dec 2, 2013 at 10:46 AM, Erick Tryzelaar wrote: > Is there any way we can use a method and move semantics for this? This > feels pretty natural to me: > > let foo = gc_allocator.box(bar); > > > On Mon, Dec 2, 2013 at 10:23 AM, Patrick Walton wrote: > >> Anything with @ feels like it goes too close to pointer sigils for my >> taste. >> >> Patrick >> >> spir wrote: >>> >>> On 12/02/2013 11:57 AM, Kevin Ballard wrote: >>> >>>> With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` >>> >>> >>> >>> I like that, with expr at place. Does this give: >>> let foo = ~ bar; >>> let placed_foo = bar @ place; >>> ? >>> >>> Yet another solution, just for fun, using the fact that pointers are supposed to >>> "point to": >>> >>> >>> let foo = -> bar; >>> let placed_foo = bar -> place; >>> >>> Denis >>> ------------------------------ >>> >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> _______________________________________________ >> >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Mon Dec 2 11:32:01 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 02 Dec 2013 11:32:01 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <0C0089F8-C528-4056-9926-06BFEB15C49D@sb.org> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <3639 7828-7a84-4f51-acd2-81c02d985659@email.android.com> <0C0089F8-C528-4056-9926-06BFEB15C49D@sb.org> Message-ID: <464f8221-341a-490f-84d0-229c33c21e7f@email.android.com> Still too punctuation heavy. Kevin Ballard wrote: >What do you mean? This suggestion uses @ as an operator, not as a >sigil. > >-Kevin > >On Dec 2, 2013, at 10:23 AM, Patrick Walton >wrote: > >> Anything with @ feels like it goes too close to pointer sigils for my >taste. >> >> Patrick >> >> spir wrote: >> On 12/02/2013 11:57 AM, Kevin Ballard wrote: >> With @ going away another possibility is to leave ~ as the normal >allocation operator and to use @ as the placement operator. So ~expr >stays the same and placement looks either like `@place expr` or >`expr at place` >> >> I like that, with expr at place. Does this give: >> let foo = ~ bar; >> let placed_foo = bar @ place; >> ? >> >> Yet another solution, just for fun, using the fact that pointers are >supposed to >> "point to": >> >> let foo = -> bar; >> let placed_foo = bar -> place; >> >> Denis >> >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Mon Dec 2 11:33:31 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 02 Dec 2013 11:33:31 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> Message-ID: <5019bcae-0463-4d30-8734-6dd851939aa4@email.android.com> That would require an unnecessary move. It needs to be built into the language. Eric Reed wrote: >I think the idea was to have the syntax desugar into method calls just >like >other existing operators. >There'd be a trait like: > >trait Box { > fn box(val: T) -> Self >} > >and something like "box expr in place" would desugar into >"place::box(expr)". > >One question this poses is why are we requiring the "place" to be >specified >all the time? >Why not let type inference handle deciding the "place" most of the >time? > > >On Mon, Dec 2, 2013 at 10:46 AM, Erick Tryzelaar >wrote: > >> Is there any way we can use a method and move semantics for this? >This >> feels pretty natural to me: >> >> let foo = gc_allocator.box(bar); >> >> >> On Mon, Dec 2, 2013 at 10:23 AM, Patrick Walton >wrote: >> >>> Anything with @ feels like it goes too close to pointer sigils for >my >>> taste. >>> >>> Patrick >>> >>> spir wrote: >>>> >>>> On 12/02/2013 11:57 AM, Kevin Ballard wrote: >>>> >>>>> With @ going away another possibility is to leave ~ as the normal >allocation operator and to use @ as the placement operator. So ~expr >stays the same and placement looks either like `@place expr` or >`expr at place` >>>> >>>> >>>> >>>> I like that, with expr at place. Does this give: >>>> let foo = ~ bar; >>>> let placed_foo = bar @ place; >>>> ? >>>> >>>> Yet another solution, just for fun, using the fact that pointers >are supposed to >>>> "point to": >>>> >>>> >>>> let foo = -> bar; >>>> let placed_foo = bar -> place; >>>> >>>> Denis >>>> ------------------------------ >>>> >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>> >>> _______________________________________________ >>> >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Mon Dec 2 11:37:12 2013 From: comexk at gmail.com (comex) Date: Mon, 2 Dec 2013 14:37:12 -0500 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <5019bcae-0463-4d30-8734-6dd851939aa4@email.android.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> <5019bcae-0463-4d30-8734-6dd851939aa4@email.android.com> Message-ID: On Mon, Dec 2, 2013 at 2:33 PM, Patrick Walton wrote: > That would require an unnecessary move. It needs to be built into the > language. Devil's advocate - aren't such unnecessary moves really easy for LLVM to optimize? From pwalton at mozilla.com Mon Dec 2 11:38:06 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 02 Dec 2013 11:38:06 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <464f8221-341a-490f-84d0-229c33c21e7f@email.android.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <3639 7828-7a84-4f51-acd2-81c02d985659@email.android.com> <0C0089F8-C528-4056-9926-06BFEB15C49D@sb.org> <464f8221-341a-490f-84d0-229c33c21e7f@email.android.com> Message-ID: <89af42c8-754a-4643-bc53-637e026bd87d@email.android.com> Besides, unless you remove the unique default (which I think would be too verbose) the default allocator reduces to a pointer sigil. Patrick Walton wrote: >Still too punctuation heavy. > >Kevin Ballard wrote: >>What do you mean? This suggestion uses @ as an operator, not as a >>sigil. >> >>-Kevin >> >>On Dec 2, 2013, at 10:23 AM, Patrick Walton >>wrote: >> >>> Anything with @ feels like it goes too close to pointer sigils for >my >>taste. >>> >>> Patrick >>> >>> spir wrote: >>> On 12/02/2013 11:57 AM, Kevin Ballard wrote: >>> With @ going away another possibility is to leave ~ as the normal >>allocation operator and to use @ as the placement operator. So ~expr >>stays the same and placement looks either like `@place expr` or >>`expr at place` >>> >>> I like that, with expr at place. Does this give: >>> let foo = ~ bar; >>> let placed_foo = bar @ place; >>> ? >>> >>> Yet another solution, just for fun, using the fact that pointers are >>supposed to >>> "point to": >>> >>> let foo = -> bar; >>> let placed_foo = bar -> place; >>> >>> Denis >>> >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev > >-- >Sent from my Android phone with K-9 Mail. Please excuse my brevity. > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Mon Dec 2 11:39:04 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 02 Dec 2013 11:39:04 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> <5019bcae-0463-4d30-8734-6dd851939aa4@email.android.com> Message-ID: Only if you SROA and inline the constructor, I think. comex wrote: >On Mon, Dec 2, 2013 at 2:33 PM, Patrick Walton >wrote: >> That would require an unnecessary move. It needs to be built into the >> language. > >Devil's advocate - aren't such unnecessary moves really easy for LLVM >to optimize? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Mon Dec 2 11:40:51 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Mon, 2 Dec 2013 14:40:51 -0500 Subject: [rust-dev] Rust forum In-Reply-To: References: Message-ID: I'm not sure that discussion forums are the best alternative to the typical "foo-users" mailing list. Topics are generally less about discussion and more about getting a quick answer to a problem; IRC is okay for this at the moment, but once Rust stabilizes I'd much prefer just using StackOverflow to host these sorts of questions. (For the moment, however, asking questions on SO just makes more work for us once the language actually does stabilize, since we'll need to go through and make sure all the answers are still relevant.) It's also not like this is an exclusive choice. We could have a rust-users list as well as a discussion forum. It's just that we'd need to figure out what to actually use the forum for that other outlets don't already do well (e.g. reddit.com/r/rust is a pretty good link aggregator). On Mon, Dec 2, 2013 at 11:21 AM, David Piepgrass wrote: > Hey, why not set up a Discourse forum? That would be so. much. better. > than a mailing list. As an OSS dev I've been itching to get one myself, but > don't have time or much money to set it up. For Mozilla, though? No problem > I'm sure. > > http://www.discourse.org/ > Google: discourse hosting. > http://www.google.com/search?q=discourse+hosting > > > From: Eric Reed >> ... >> I'm not aware of any plans for a rust-users forum. Maybe spinning a >> rust-users mailing list off from rust-dev would make sense? We already did >> a similar thing with our IRC channels. >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Mon Dec 2 12:04:04 2013 From: kevin at sb.org (Kevin Ballard) Date: Mon, 2 Dec 2013 12:04:04 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <89af42c8-754a-4643-bc53-637e026bd87d@email.android.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <3639 7828-7a84-4f51-acd2-81c02d985659@email.android.com> <0C0089F8-C528-4056-9926-06BFEB15C49D@sb.org> <464f8221-341a-490f-84d0-229c33c21e7f@email.android.com> <89af42c8-754a-4643-bc53-637e026bd87d@email.android.com> Message-ID: ~ would still be the unique default. @ would require a place (because there's no placement without a place). Just because C++ uses the same operator for regular allocation and for placement doesn't mean we have to do the same. As it's been pointed out already, C++'s use of `new` for placement is kind of quite strange, since it doesn't actually allocate anything. As for "too punctuation heavy", why the hate on punctuation? Operators have a long history of use in programming languages to great effect. I don't get why operators are now suddenly bad. User-overloadable operators are contentious, certainly, but this isn't an overloadable operator. -Kevin On Dec 2, 2013, at 11:38 AM, Patrick Walton wrote: > Besides, unless you remove the unique default (which I think would be too verbose) the default allocator reduces to a pointer sigil. > > Patrick Walton wrote: > Still too punctuation heavy. > > Kevin Ballard wrote: > What do you mean? This suggestion uses @ as an operator, not as a sigil. > > -Kevin > > On Dec 2, 2013, at 10:23 AM, Patrick Walton wrote: > >> Anything with @ feels like it goes too close to pointer sigils for my taste. >> >> Patrick >> >> spir wrote: >> On 12/02/2013 11:57 AM, Kevin Ballard wrote: >> With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` >> >> I like that, with expr at place. Does this give: >> let foo = ~ bar; >> let placed_foo = bar @ place; >> ? >> >> Yet another solution, just for fun, using the fact that pointers are supposed to >> "point to": >> >> let foo = -> bar; >> let placed_foo = bar -> place; >> >> Denis >> >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecreed at cs.washington.edu Mon Dec 2 13:31:24 2013 From: ecreed at cs.washington.edu (Eric Reed) Date: Mon, 2 Dec 2013 13:31:24 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <0C0089F8-C528-4056-9926-06BFEB15C49D@sb.org> <464f8221-341a-490f-84d0-229c33c21e7f@email.android.com> <89af42c8-754a-4643-bc53-637e026bd87d@email.android.com> Message-ID: And @ even makes sense for what it's doing (placing something at somewhere) when compared with most operators. On Mon, Dec 2, 2013 at 12:04 PM, Kevin Ballard wrote: > ~ would still be the unique default. @ would require a place (because > there's no placement without a place). Just because C++ uses the same > operator for regular allocation and for placement doesn't mean we have to > do the same. As it's been pointed out already, C++'s use of `new` for > placement is kind of quite strange, since it doesn't actually allocate > anything. > > As for "too punctuation heavy", why the hate on punctuation? Operators > have a long history of use in programming languages to great effect. I > don't get why operators are now suddenly bad. User-overloadable operators > are contentious, certainly, but this isn't an overloadable operator. > > -Kevin > > On Dec 2, 2013, at 11:38 AM, Patrick Walton wrote: > > Besides, unless you remove the unique default (which I think would be too > verbose) the default allocator reduces to a pointer sigil. > > Patrick Walton wrote: >> >> Still too punctuation heavy. >> >> Kevin Ballard wrote: >>> >>> What do you mean? This suggestion uses @ as an operator, not as a sigil. >>> >>> -Kevin >>> >>> On Dec 2, 2013, at 10:23 AM, Patrick Walton wrote: >>> >>> Anything with @ feels like it goes too close to pointer sigils for my >>> taste. >>> >>> Patrick >>> >>> spir wrote: >>>> >>>> On 12/02/2013 11:57 AM, Kevin Ballard wrote: >>>> >>>>> With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` >>>> >>>> >>>> I like that, with expr at place. Does this give: >>>> let foo = ~ bar; >>>> let placed_foo = bar @ place; >>>> ? >>>> >>>> Yet another solution, just for fun, using the fact that pointers are supposed to >>>> "point to": >>>> >>>> let foo = -> bar; >>>> let placed_foo = bar -> place; >>>> >>>> Denis >>>> ------------------------------ >>>> >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >>> >> > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at kevincantu.org Mon Dec 2 20:31:39 2013 From: me at kevincantu.org (Kevin Cantu) Date: Mon, 2 Dec 2013 20:31:39 -0800 Subject: [rust-dev] RFC: Put Unicode identifiers behind a feature gate In-Reply-To: <20131202181931.GH21938@Mr-Bennet> References: <528EE360.5070504@mozilla.com> <20131202181931.GH21938@Mr-Bennet> Message-ID: When I started my old Rust PPA (now superseded), the first user to email me was an engineer from China who was getting ready to give a talk introducing Rust to a programming user group in Gu?ngzh?u bigger than any of the Rust-specific meetups we've ever had yet in the San Francisco Bay area. There are a ton of people who don't do their best work in English: our ASCII world is quite small, despite how loud people like me happen to talk. Excluding foreign language users when we don't have to would be a huge mistake. Gating this for now only works if we aren't later going to try to sacrifice this awesome feature to the elder gods of backwards compatibility... Kevin From corey at octayn.net Mon Dec 2 21:05:20 2013 From: corey at octayn.net (Corey Richardson) Date: Tue, 3 Dec 2013 00:05:20 -0500 Subject: [rust-dev] RFC: Put Unicode identifiers behind a feature gate In-Reply-To: References: <528EE360.5070504@mozilla.com> <20131202181931.GH21938@Mr-Bennet> Message-ID: The compiler still handles it, and there are still tests for it. I think it's more of a "not 1.0 priority", than anything else. On Mon, Dec 2, 2013 at 11:31 PM, Kevin Cantu wrote: > When I started my old Rust PPA (now superseded), the first user to > email me was an engineer from China who was getting ready to give a > talk introducing Rust to a programming user group in Gu?ngzh?u bigger > than any of the Rust-specific meetups we've ever had yet in the San > Francisco Bay area. > > There are a ton of people who don't do their best work in English: our > ASCII world is quite small, despite how loud people like me happen to > talk. Excluding foreign language users when we don't have to would be > a huge mistake. > > Gating this for now only works if we aren't later going to try to > sacrifice this awesome feature to the elder gods of backwards > compatibility... > > > Kevin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From qwertie256 at gmail.com Mon Dec 2 21:45:37 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Mon, 2 Dec 2013 22:45:37 -0700 Subject: [rust-dev] Rust forum Message-ID: On 02/12/2013 16:21, David Piepgrass wrote: > > That would be so. much. better. than a mailing list. > > Hi. Could you expand on this? I don?t necessarily disagree, but as the > one proposing change it?s up to you to convince everyone else :) > > -- > Simon Sapin > Okay, well, I've never liked mailing lists at all, because: 1. In non-digest mode, My inbox gets flooded. 2. In digest mode, it's quite inconvenient to write a reply, having to cut out all the messages that I don't want to reply to and manually edit the subject line. Also, unrelated messages are grouped together while threads are broken apart, making discussions harder to follow. 3. In email I don't get a threaded view. If I go to mailing list archives to see a threaded view, I can't reply. 4. I have to manually watch for replies to my messages or to threads I'm following. If someone mentions my name (not that they would), I won't be notified. In contrast, Discourse has a variety of email notification options. I don't know if those options are enough to please everybody, but you can probably configure it to notify you about all posts, which makes it essentially equivalent to a mailing list. It supports reply by email, so those that prefer a mailing list can still pretend it's a mailing list. Currently I'm getting an shrunk digest of Discourse Meta--by email I only get a subset of all messages, auto-selected by Discourse, whatever it thinks is interesting. That's good for me: I really don't want to see every message. Plus, a mailing list offers less privacy as it mandates publishing your email address. That's not a big deal for me personally, but do you really want to require that from every Rust user? (btw, if I'm wrong about any of the above points, I promise there are lots of other netizens out there who have the same misconception(s), so many of them will avoid mailing lists. The fact that y'all are talking to me on a mailing list suggests that the disadvantages of a mailing list are not a big deal *to you*, but as for those who aren't participating, you can't conclude *they* prefer mailing lists.) And like mailing lists, Discourse also supports private messages. I don't understand why Paul mentioned GPG. You want to encrypt messages to a public mailing list? You can sign messages, but surely almost no one actually checks the signature, and I'd be surprised if Discourse didn't offer some built-in evidence of identity (surely it's not like email in letting you spoof the sender name easily?). I heard discourse supports attachments, just that you may have to go to the forum to attach or download them (rather than by email). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecreed at cs.washington.edu Mon Dec 2 22:35:34 2013 From: ecreed at cs.washington.edu (Eric Reed) Date: Mon, 2 Dec 2013 22:35:34 -0800 Subject: [rust-dev] Rust forum In-Reply-To: References: Message-ID: Well there's always r/rust/ . It usually works pretty well. On Mon, Dec 2, 2013 at 9:45 PM, David Piepgrass wrote: > On 02/12/2013 16:21, David Piepgrass wrote: > >> > That would be so. much. better. than a mailing list. >> >> Hi. Could you expand on this? I don?t necessarily disagree, but as the >> one proposing change it?s up to you to convince everyone else :) >> >> -- >> Simon Sapin >> > > Okay, well, I've never liked mailing lists at all, because: > > 1. In non-digest mode, My inbox gets flooded. > 2. In digest mode, it's quite inconvenient to write a reply, having to cut > out all the messages that I don't want to reply to and manually edit the > subject line. Also, unrelated messages are grouped together while threads > are broken apart, making discussions harder to follow. > 3. In email I don't get a threaded view. If I go to mailing list archives > to see a threaded view, I can't reply. > 4. I have to manually watch for replies to my messages or to threads I'm > following. If someone mentions my name (not that they would), I won't be > notified. > > In contrast, Discourse has a variety of email notification options. I > don't know if those options are enough to please everybody, but you can > probably configure it to notify you about all posts, which makes it > essentially equivalent to a mailing list. It supports reply by email, so > those that prefer a mailing list can still pretend it's a mailing list. > Currently I'm getting an shrunk digest of Discourse Meta--by email I only > get a subset of all messages, auto-selected by Discourse, whatever it > thinks is interesting. That's good for me: I really don't want to see every > message. > > Plus, a mailing list offers less privacy as it mandates publishing your > email address. That's not a big deal for me personally, but do you really > want to require that from every Rust user? > > (btw, if I'm wrong about any of the above points, I promise there are lots > of other netizens out there who have the same misconception(s), so many of > them will avoid mailing lists. The fact that y'all are talking to me on a > mailing list suggests that the disadvantages of a mailing list are not a > big deal *to you*, but as for those who aren't participating, you can't > conclude *they* prefer mailing lists.) > > And like mailing lists, Discourse also supports private messages. > > I don't understand why Paul mentioned GPG. You want to encrypt messages to > a public mailing list? You can sign messages, but surely almost no one > actually checks the signature, and I'd be surprised if Discourse didn't > offer some built-in evidence of identity (surely it's not like email in > letting you spoof the sender name easily?). > > I heard discourse supports attachments, just that you may have to go to > the forum to attach or download them (rather than by email). > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From val at markovic.io Tue Dec 3 00:34:37 2013 From: val at markovic.io (Val Markovic) Date: Tue, 3 Dec 2013 00:34:37 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> <5019bcae-0463-4d30-8734-6dd851939aa4@email.android.com> Message-ID: This is an interesting thread. A few points: - "box" makes a lot more sense than "new"; as others have pointed out, the latter maps to a different concept in C++ which makes it familiar in the worst way. - "Foo::init" is terrible, agreed, but "Foo::new" is less than ideal as well. "Foo::create" might be better. Just read this aloud: "this function news a value." What? That makes no sense. "This function creates a value." Much better, isn't it? Point being, it should be a verb. JavaScript does it with Object.create, so there's precedent. - placement new might be common in Servo and browser engines, but it's not that common in most C++. After 10 years and 200k+ LOC of C++ across many, many different programs and paradigms I've yet to use it once. Sure, that's just one person's experience but others seem to be echoing the same sentiment. I'm not saying let's not have placement new, just that we shouldn't put on an undeserved pedestal. On Dec 2, 2013 11:39 AM, "Patrick Walton" wrote: > > Only if you SROA and inline the constructor, I think. > > > comex wrote: >> >> On Mon, Dec 2, 2013 at 2:33 PM, Patrick Walton wrote: >>> >>> That would require an unnecessary move. It needs to be built into the >>> language. >> >> >> Devil's advocate - aren't such unnecessary moves really easy for LLVM >> to optimize? > > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Tue Dec 3 00:41:17 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 03 Dec 2013 00:41:17 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> <5019bcae-0463-4d30-8734-6dd851939aa4@email.android.com> Message-ID: <529D992D.4070803@mozilla.com> On 12/3/13 12:34 AM, Val Markovic wrote: > This is an interesting thread. A few points: > > - "box" makes a lot more sense than "new"; as others have pointed out, > the latter maps to a different concept in C++ which makes it familiar in > the worst way. > - "Foo::init" is terrible, agreed, but "Foo::new" is less than ideal as > well. "Foo::create" might be better. Just read this aloud: "this > function news a value." What? That makes no sense. "This function > creates a value." Much better, isn't it? Point being, it should be a > verb. JavaScript does it with Object.create, so there's precedent. > - placement new might be common in Servo and browser engines, but it's > not that common in most C++. After 10 years and 200k+ LOC of C++ across > many, many different programs and paradigms I've yet to use it once. > Sure, that's just one person's experience but others seem to be echoing > the same sentiment. I'm not saying let's not have placement new, just > that we shouldn't put on an undeserved pedestal. Rust and C++ are different. You don't use placement `new` for `shared_ptr` in C++; however, you will use placement `new` (or `box`) for `RC` in Rust (the equivalent). For this reason I suspect that placement `new` will be much commoner in Rust than in C++. Patrick From jeti789 at web.de Tue Dec 3 00:43:14 2013 From: jeti789 at web.de (jeti789 at web.de) Date: Tue, 3 Dec 2013 09:43:14 +0100 (CET) Subject: [rust-dev] Rust forum In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From remifontan at yahoo.fr Tue Dec 3 01:09:10 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Tue, 3 Dec 2013 22:09:10 +1300 Subject: [rust-dev] method overloading and generic Message-ID: Hi, I think I already asked this question in the past and I'm not very sure what was the answer and whether it is still applicable wirh rust 0.8. I'm implementing the double dispatch method overloading such that I can add 2 struct together and a float to a struct. let data = SomeData{a:1.0} + 2.0; let data2 = SomeData{a:100.0} + data; I would like to implement the add for every type of float. I asked whether I could write something like this: impl SomeDataRhs for T { fn add_to(&self, lhs:&SomeData) -> SomeData { SomeData{a:lhs.a + cast(*self)} } } it does not compile right now with rust 0.8 I get error messages as follow test2.rs:39:0: 43:1 error: conflicting implementations for trait `SomeDataRhs` test2.rs:39 impl SomeDataRhs for SomeData { test2.rs:40 fn add_to(&self, lhs:&SomeData) -> SomeData { test2.rs:41 SomeData{a:lhs.a + self.a} test2.rs:42 } test2.rs:43 } test2.rs:33:0: 37:1 note: note conflicting implementation here test2.rs:33 impl SomeDataRhs for T { test2.rs:34 fn add_to(&self, lhs:&SomeData) -> SomeData { test2.rs:35 SomeData{a:lhs.a + cast(*self)} test2.rs:36 } Would you know whether what I try to do is possible. I was recommended to use macro for that, I don't mind to eventually go this way but I would rather do it the proper way if there is one. here's the full code of my test: extern mod std; use std::num::cast; struct SomeData { a:float } trait SomeDataRhs { fn add_to(&self, lhs:&SomeData) -> SomeData; } impl Add for SomeData { fn add(&self, rhs:&T) -> SomeData { rhs.add_to(self) } } // --------------- // implementations // impl SomeDataRhs for float { // fn add_to(&self, lhs:&SomeData) -> SomeData { // SomeData{a:lhs.a + *self} // } // } // impl SomeDataRhs for f64 { // fn add_to(&self, lhs:&SomeData) -> SomeData { // SomeData{a:lhs.a + cast(*self)} // } // } impl SomeDataRhs for T { fn add_to(&self, lhs:&SomeData) -> SomeData { SomeData{a:lhs.a + cast(*self)} } } impl SomeDataRhs for SomeData { fn add_to(&self, lhs:&SomeData) -> SomeData { SomeData{a:lhs.a + self.a} } } #[test] fn test_sandbox() { let mut data = SomeData{a:1.0} + 2.0; println!("result: {}", data.a); let mut data2 = SomeData{a:100.0} + data; data = data + data2; println!("result: {}", data.a); } cheers, R?mi -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecreed at cs.washington.edu Tue Dec 3 02:50:39 2013 From: ecreed at cs.washington.edu (Eric Reed) Date: Tue, 3 Dec 2013 02:50:39 -0800 Subject: [rust-dev] method overloading and generic In-Reply-To: References: Message-ID: I think you're running into issue #8075which has to do with generic impls conflicting with all the other impls present. The typechecker tries to ensure that impls are coherent, i.e. that impls do not overlap (otherwise the compiler wouldn't know which one to use). Unfortunately, the coherence check isn't very smart right now and if there's a generic impl around then it assumes it could conflict with everything (and consequently forbids any other impls). The specific problem here is that the coherence checker doesn't realize that SomeData does not impl Float. Without knowing that, the checker sees two possible impls for SomeData and rejects the code. If you replace "impl SomeDataRhs for T" with "impl SomeDataRhs for f64", then it'll work fine. You can add an impl for f32 as well (FYI "float" is already removed in HEAD). Unfortunately, I don't know of a good general solution that will support all types implementing Float (i.e. what the generic impl is doing). On Tue, Dec 3, 2013 at 1:09 AM, R?mi Fontan wrote: > Hi, > > I think I already asked this question in the past and I'm not very sure > what was the answer and whether it is still applicable wirh rust 0.8. > > I'm implementing the double dispatch method overloading such that I can > add 2 struct together and a float to a struct. > > let data = SomeData{a:1.0} + 2.0; > let data2 = SomeData{a:100.0} + data; > > I would like to implement the add for every type of float. I asked whether > I could write something like this: > > impl SomeDataRhs for T { > fn add_to(&self, lhs:&SomeData) -> SomeData { > SomeData{a:lhs.a + cast(*self)} > } > } > > it does not compile right now with rust 0.8 > I get error messages as follow > > test2.rs:39:0: 43:1 error: conflicting implementations for trait > `SomeDataRhs` > > test2.rs:39 impl SomeDataRhs for SomeData { > > test2.rs:40 fn add_to(&self, lhs:&SomeData) -> SomeData { > > test2.rs:41 SomeData{a:lhs.a + self.a} > > test2.rs:42 } > > test2.rs:43 } > > test2.rs:33:0: 37:1 note: note conflicting implementation here > > test2.rs:33 impl SomeDataRhs for T { > > test2.rs:34 fn add_to(&self, lhs:&SomeData) -> SomeData { > > test2.rs:35 SomeData{a:lhs.a + cast(*self)} > > test2.rs:36 } > > Would you know whether what I try to do is possible. I was recommended to > use macro for that, I don't mind to eventually go this way but I would > rather do it the proper way if there is one. > > here's the full code of my test: > extern mod std; > use std::num::cast; > > > struct SomeData { a:float } > > trait SomeDataRhs { > fn add_to(&self, lhs:&SomeData) -> SomeData; > } > > impl Add for SomeData { > > fn add(&self, rhs:&T) -> SomeData { > rhs.add_to(self) > } > } > > // --------------- > // implementations > > // impl SomeDataRhs for float { > // fn add_to(&self, lhs:&SomeData) -> SomeData { > // SomeData{a:lhs.a + *self} > // } > // } > > // impl SomeDataRhs for f64 { > // fn add_to(&self, lhs:&SomeData) -> SomeData { > // SomeData{a:lhs.a + cast(*self)} > // } > // } > > impl SomeDataRhs for T { > fn add_to(&self, lhs:&SomeData) -> SomeData { > SomeData{a:lhs.a + cast(*self)} > } > } > > impl SomeDataRhs for SomeData { > fn add_to(&self, lhs:&SomeData) -> SomeData { > SomeData{a:lhs.a + self.a} > } > } > > > #[test] > fn test_sandbox() { > > let mut data = SomeData{a:1.0} + 2.0; > println!("result: {}", data.a); > > let mut data2 = SomeData{a:100.0} + data; > data = data + data2; > println!("result: {}", data.a); > > } > > > > cheers, > > R?mi > > > -- > R?mi Fontan : remifontan at yahoo.fr > mobile: +64 21 855 351 > 93 Otaki Street, Miramar 6022 > Wellington, New Zealand > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From troplin at bluewin.ch Tue Dec 3 04:03:36 2013 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Tue, 3 Dec 2013 12:03:36 +0000 (UTC) Subject: [rust-dev] Rust forum References: Message-ID: <658484505407764383.648605troplin-bluewin.ch@news.gmane.org> David Piepgrass wrote: > Okay, well, I've never liked mailing lists at all, because: > > 1. In non-digest mode, My inbox gets flooded. > 2. In digest mode, it's quite inconvenient to write a reply, having to > cut out all the messages that I don't want to reply to and manually edit > the subject line. Also, unrelated messages are grouped together while > threads are broken apart, making discussions harder to follow. > 3. In email I don't get a threaded view. If I go to mailing list archives > to see a threaded view, I can't reply. Just use NNTP (gmane.comp.lang.rust.devel on news.gmane.org). Most newsreader support threaded view (Thunderbird does). You can configure the mailing list s.t. mails are not actually delivered to your email address even if you are registered. But looking at your email address you are already using gmane. Tobi From gaetan at xeberon.net Tue Dec 3 05:46:00 2013 From: gaetan at xeberon.net (Gaetan) Date: Tue, 3 Dec 2013 14:46:00 +0100 Subject: [rust-dev] Rust forum In-Reply-To: <658484505407764383.648605troplin-bluewin.ch@news.gmane.org> References: <658484505407764383.648605troplin-bluewin.ch@news.gmane.org> Message-ID: I'm in favor of a properly managed stackoverflow section. stackoverflow does a marvelous job for finding issue someone else has already been confronted before. I never liked forums, search features are always buggy, category are too restrictives, ... mailing list is good for what it does: emails. That's all. ----- Gaetan 2013/12/3 Tobias M?ller > David Piepgrass wrote: > > Okay, well, I've never liked mailing lists at all, because: > > > > 1. In non-digest mode, My inbox gets flooded. > > 2. In digest mode, it's quite inconvenient to write a reply, having to > > cut out all the messages that I don't want to reply to and manually edit > > the subject line. Also, unrelated messages are grouped together while > > threads are broken apart, making discussions harder to follow. > > 3. In email I don't get a threaded view. If I go to mailing list archives > > to see a threaded view, I can't reply. > > Just use NNTP (gmane.comp.lang.rust.devel on news.gmane.org). Most > newsreader support threaded view (Thunderbird does). You can configure the > mailing list s.t. mails are not actually delivered to your email address > even if you are registered. > > But looking at your email address you are already using gmane. > > Tobi > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Tue Dec 3 06:02:59 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 3 Dec 2013 09:02:59 -0500 Subject: [rust-dev] Rust forum In-Reply-To: References: Message-ID: > The idea of an online user forum would be that people with an interest in Rust can read in the user forum which is easier to peruse than some mail list archive. Asking and getting answers seems to work more fluently. I agree with the principle, but we have yet to identify what users would actually want to peruse in a discussion forum. For questions, we have StackOverflow. For keeping up with the cool projects that the community is working on, we have reddit. Piggybacking on established platforms will lead to easier discoverability and broader readership. Which isn't to say that a discussion forum won't be warranted sometime in the future, but for now we're getting along quite well with the free alternatives provided by the broader web. On Tue, Dec 3, 2013 at 3:43 AM, wrote: > The idea of an online user forum would be that people with an interest > in Rust can read in the user forum which is easier to peruse than some mail > list archive. Asking and getting answers seems to work more fluently. > > There is really hell going on on the Go users forum: > https://groups.google.com/forum/?hl=de#!forum/golang-nuts An online forum > seems to intensivy people's interest in some language. But it's certainly > your language and your decision what you want to do. > > Regards, Oliver > > *Gesendet:* Dienstag, 03. Dezember 2013 um 07:35 Uhr > *Von:* "Eric Reed" > *An:* "David Piepgrass" > *Cc:* "rust-dev at mozilla.org" > *Betreff:* Re: [rust-dev] Rust forum > Well there's always r/rust/ . It usually > works pretty well. > > On Mon, Dec 2, 2013 at 9:45 PM, David Piepgrass wrote: >> >> On 02/12/2013 16:21, David Piepgrass wrote: >> >>> > That would be so. much. better. than a mailing list. >>> >>> Hi. Could you expand on this? I don?t necessarily disagree, but as the >>> one proposing change it?s up to you to convince everyone else :) >>> >>> -- >>> Simon Sapin >> >> >> Okay, well, I've never liked mailing lists at all, because: >> >> 1. In non-digest mode, My inbox gets flooded. >> 2. In digest mode, it's quite inconvenient to write a reply, having to >> cut out all the messages that I don't want to reply to and manually edit >> the subject line. Also, unrelated messages are grouped together while >> threads are broken apart, making discussions harder to follow. >> 3. In email I don't get a threaded view. If I go to mailing list archives >> to see a threaded view, I can't reply. >> 4. I have to manually watch for replies to my messages or to threads I'm >> following. If someone mentions my name (not that they would), I won't be >> notified. >> >> In contrast, Discourse has a variety of email notification options. I >> don't know if those options are enough to please everybody, but you can >> probably configure it to notify you about all posts, which makes it >> essentially equivalent to a mailing list. It supports reply by email, so >> those that prefer a mailing list can still pretend it's a mailing list. >> Currently I'm getting an shrunk digest of Discourse Meta--by email I only >> get a subset of all messages, auto-selected by Discourse, whatever it >> thinks is interesting. That's good for me: I really don't want to see every >> message. >> >> Plus, a mailing list offers less privacy as it mandates publishing your >> email address. That's not a big deal for me personally, but do you really >> want to require that from every Rust user? >> >> (btw, if I'm wrong about any of the above points, I promise there are >> lots of other netizens out there who have the same misconception(s), so >> many of them will avoid mailing lists. The fact that y'all are talking to >> me on a mailing list suggests that the disadvantages of a mailing list are >> not a big deal *to you*, but as for those who aren't participating, you >> can't conclude *they* prefer mailing lists.) >> >> And like mailing lists, Discourse also supports private messages. >> >> I don't understand why Paul mentioned GPG. You want to encrypt messages >> to a public mailing list? You can sign messages, but surely almost no one >> actually checks the signature, and I'd be surprised if Discourse didn't >> offer some built-in evidence of identity (surely it's not like email in >> letting you spoof the sender name easily?). >> >> I heard discourse supports attachments, just that you may have to go to >> the forum to attach or download them (rather than by email). >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiffany at stormbit.net Tue Dec 3 06:27:28 2013 From: tiffany at stormbit.net (Tiffany Bennett) Date: Tue, 3 Dec 2013 09:27:28 -0500 Subject: [rust-dev] Rust forum In-Reply-To: References: Message-ID: On Tue, Dec 3, 2013 at 12:45 AM, David Piepgrass wrote: > 1. In non-digest mode, My inbox gets flooded. > 3. In email I don't get a threaded view. If I go to mailing list archives > to see a threaded view, I can't reply. > 4. I have to manually watch for replies to my messages or to threads I'm > following. If someone mentions my name (not that they would), I won't be > notified. > You should consider getting a better email client. GMail handles mailing lists pretty poorly, and even it does better than that. > In contrast, Discourse has a variety of email notification options. I > don't know if those options are enough to please everybody, but you can > probably configure it to notify you about all posts, which makes it > essentially equivalent to a mailing list. It supports reply by email, so > those that prefer a mailing list can still pretend it's a mailing list. > Currently I'm getting an shrunk digest of Discourse Meta--by email I only > get a subset of all messages, auto-selected by Discourse, whatever it > thinks is interesting. That's good for me: I really don't want to see every > message. > Do you think it allows you to reply via email like github does? You've made a number of good points, I must say. > Plus, a mailing list offers less privacy as it mandates publishing your > email address. That's not a big deal for me personally, but do you really > want to require that from every Rust user? > > (btw, if I'm wrong about any of the above points, I promise there are lots > of other netizens out there who have the same misconception(s), so many of > them will avoid mailing lists. The fact that y'all are talking to me on a > mailing list suggests that the disadvantages of a mailing list are not a > big deal *to you*, but as for those who aren't participating, you can't > conclude *they* prefer mailing lists.) > > And like mailing lists, Discourse also supports private messages. > > I don't understand why Paul mentioned GPG. You want to encrypt messages to > a public mailing list? You can sign messages, but surely almost no one > actually checks the signature, and I'd be surprised if Discourse didn't > offer some built-in evidence of identity (surely it's not like email in > letting you spoof the sender name easily?). > > I heard discourse supports attachments, just that you may have to go to > the forum to attach or download them (rather than by email). > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelwoerister at posteo.de Mon Dec 2 03:11:24 2013 From: michaelwoerister at posteo.de (Michael Woerister) Date: Mon, 02 Dec 2013 12:11:24 +0100 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> Message-ID: <529C6ADC.1090402@posteo.de> +1 for `expr @ place` On 02.12.2013 11:57, Kevin Ballard wrote: > With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` > > -Kevin Ballard > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From danielmicay at gmail.com Tue Dec 3 09:13:43 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 3 Dec 2013 12:13:43 -0500 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <529D992D.4070803@mozilla.com> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C8601.1060004@gmail.com> <36397828-7a84-4f51-acd2-81c02d985659@email.android.com> <5019bcae-0463-4d30-8734-6dd851939aa4@email.android.com> <529D992D.4070803@mozilla.com> Message-ID: On Tue, Dec 3, 2013 at 3:41 AM, Patrick Walton wrote: > On 12/3/13 12:34 AM, Val Markovic wrote: >> >> This is an interesting thread. A few points: >> >> - "box" makes a lot more sense than "new"; as others have pointed out, >> the latter maps to a different concept in C++ which makes it familiar in >> the worst way. >> - "Foo::init" is terrible, agreed, but "Foo::new" is less than ideal as >> well. "Foo::create" might be better. Just read this aloud: "this >> function news a value." What? That makes no sense. "This function >> creates a value." Much better, isn't it? Point being, it should be a >> verb. JavaScript does it with Object.create, so there's precedent. >> - placement new might be common in Servo and browser engines, but it's >> not that common in most C++. After 10 years and 200k+ LOC of C++ across >> many, many different programs and paradigms I've yet to use it once. >> Sure, that's just one person's experience but others seem to be echoing >> the same sentiment. I'm not saying let's not have placement new, just >> that we shouldn't put on an undeserved pedestal. > > > Rust and C++ are different. You don't use placement `new` for `shared_ptr` > in C++; however, you will use placement `new` (or `box`) for `RC` in Rust > (the equivalent). For this reason I suspect that placement `new` will be > much commoner in Rust than in C++. > > Patrick To expand on this, C++ has functions like `make_shared` (C++11), `make_unique` (C++14) and even container methods to build an object in-place without a move (`emplace`, `emplace_back`, etc.). From ben.striegel at gmail.com Tue Dec 3 09:16:21 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 3 Dec 2013 12:16:21 -0500 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: <529C6ADC.1090402@posteo.de> References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C6ADC.1090402@posteo.de> Message-ID: If `expr @ place` suffices then you'd think that re-using `in` keyword as per `expr in place` would also work, but I believe we rejected that for technical reasons in past discussions. And if those technical reasons no longer apply, I'd like to motion that `in` looks way better than `@` there. :) On Mon, Dec 2, 2013 at 6:11 AM, Michael Woerister < michaelwoerister at posteo.de> wrote: > +1 for `expr @ place` > > > On 02.12.2013 11:57, Kevin Ballard wrote: > >> With @ going away another possibility is to leave ~ as the normal >> allocation operator and to use @ as the placement operator. So ~expr stays >> the same and placement looks either like `@place expr` or `expr at place` >> >> -Kevin Ballard >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redbrain at gcc.gnu.org Tue Dec 3 09:22:07 2013 From: redbrain at gcc.gnu.org (Philip Herron) Date: Tue, 3 Dec 2013 17:22:07 +0000 Subject: [rust-dev] Rust front-end to GCC Message-ID: Hey all Some of you may have noticed the gccrs branch on the git mirror. Since PyCon IE 2013 i gave a talk on my Python Front-end pet project and heard about rust by a few people and i never really looked at it before until then but i've kind of been hooked since. So to learn the language i've been writing this front-end to GCC. Only really a a month or so on and off work in between work. Currently it compiles alot of rust already in fairly little effort on my side GCC is doing loads of the heavy lifting. Currently it compiles most of the basic stuff such as a struct an impl block while loop, functions expressions calling methods passing arguments etc. Currently focusing on getting the typing working correctly to support & and ~ and look at how templates might work as well as need to implement break and return. There is still a lot of work but i would really like to share it and see what people think. Personally i think rust will target GCC very well and be a good addition (if / when it works). I really want to try and give back to this community who have been very good to me in learning over the last few years with GSOC. To get a jist of what i am compiling in my tests are something like: fn fib1 (n:int) -> int { if (n <= 1) { 1 } else { n * fib1 (n - 1) } } fn fib2 (n:int) -> int { let mut i = 1; let mut result = 1; while (i <= n) { result = result * i; i = i + 1; } result } fn main () { fib1 (10); fib2 (10); } Or struct mytype { x : int } impl mytype { fn test (self) -> int { println ("yyoyoyo"); test2 (1) } } fn main () { let x = mytype { x : 1 }; let z = x.x; let y = x.test (); let a = test2 (y); } fn test2 (x : int) -> int { let z = x; 1 + z } Theses are both pretty abstract test cases but were the ones i just made work a while ago. Lots more work to do on it but i feel these 2 test cases working is kind of a mile stone for me. I will start a wiki page on the project and the code i work on is at http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gccrs and i have it on github first mostly for travis CI and so i can do a bunch of commits and rebase etc http://github.com/redbrain/gccrs Thanks --Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Tue Dec 3 09:45:43 2013 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 03 Dec 2013 09:45:43 -0800 Subject: [rust-dev] Rust forum In-Reply-To: References: Message-ID: <529E18C7.40403@mozilla.com> On 12/03/2013 06:02 AM, Benjamin Striegel wrote: > > The idea of an online user forum would be that people with an > interest in Rust can read in the user forum which is easier to peruse > than some mail list archive. Asking and getting answers seems to work > more fluently. > > I agree with the principle, but we have yet to identify what users > would actually want to peruse in a discussion forum. For questions, we > have StackOverflow. For keeping up with the cool projects that the > community is working on, we have reddit. Piggybacking on established > platforms will lead to easier discoverability and broader readership. I also believe that we should lean heavily on external resources wherever possible. Maintaining our own infrastructure is very time consuming and we've already got a lot. We could put more focus on stackoverflow by linking it from the wiki and encouraging community members to curate it better (I know I haven't looked at it in a long time). Currently, I'm more in favor of adding a rust-users mailing list than setting up a web forum, but there are pros and cons to each approach: * creating another *type* of venue for general discussion runs the risk of dividing the user base * mailing lists are easy to create and administer at Mozilla * web forums can be much easier to moderate, and we've had a few incidents on the mailing list recently * mailing lists are simple to archive and maintaining a record of Rust's development is imortant to me * if we did set up a forum, it seems like we should shut down the mailing list to avoid dividing the user base, which feels kind of unfortunate simply because having a mailing list is a matter of pride > > Which isn't to say that a discussion forum won't be warranted sometime > in the future, but for now we're getting along quite well with the > free alternatives provided by the broader web. > > > On Tue, Dec 3, 2013 at 3:43 AM, > wrote: > > The idea of an online user forum would be that people with an > interest in Rust can read in the user forum which is easier to > peruse than some mail list archive. Asking and getting answers > seems to work more fluently. > There is really hell going on on the Go users forum: > https://groups.google.com/forum/?hl=de#!forum/golang-nuts > An > online forum seems to intensivy people's interest in some > language. But it's certainly your language and your decision what > you want to do. > > Regards, Oliver > *Gesendet:* Dienstag, 03. Dezember 2013 um 07:35 Uhr > *Von:* "Eric Reed" > > *An:* "David Piepgrass" > > *Cc:* "rust-dev at mozilla.org " > > > *Betreff:* Re: [rust-dev] Rust forum > Well there's always r/rust/ . It > usually works pretty well. > On Mon, Dec 2, 2013 at 9:45 PM, David Piepgrass > > wrote: > > On 02/12/2013 16:21, David Piepgrass wrote: > > > That would be so. much. better. than a mailing list. > Hi. Could you expand on this? I don?t necessarily > disagree, but as the > one proposing change it?s up to you to convince everyone > else :) > > -- > Simon Sapin > > Okay, well, I've never liked mailing lists at all, because: > 1. In non-digest mode, My inbox gets flooded. > 2. In digest mode, it's quite inconvenient to write a reply, > having to cut out all the messages that I don't want to reply > to and manually edit the subject line. Also, unrelated > messages are grouped together while threads are broken apart, > making discussions harder to follow. > 3. In email I don't get a threaded view. If I go to mailing > list archives to see a threaded view, I can't reply. > 4. I have to manually watch for replies to my messages or to > threads I'm following. If someone mentions my name (not that > they would), I won't be notified. > In contrast, Discourse has a variety of email notification > options. I don't know if those options are enough to please > everybody, but you can probably configure it to notify you > about all posts, which makes it essentially equivalent to a > mailing list. It supports reply by email, so those that prefer > a mailing list can still pretend it's a mailing list. > Currently I'm getting an shrunk digest of Discourse Meta--by > email I only get a subset of all messages, auto-selected by > Discourse, whatever it thinks is interesting. That's good for > me: I really don't want to see every message. > Plus, a mailing list offers less privacy as it mandates > publishing your email address. That's not a big deal for me > personally, but do you really want to require that from every > Rust user? > (btw, if I'm wrong about any of the above points, I promise > there are lots of other netizens out there who have the same > misconception(s), so many of them will avoid mailing lists. > The fact that y'all are talking to me on a mailing list > suggests that the disadvantages of a mailing list are not a > big deal *to you*, but as for those who aren't participating, > you can't conclude *they* prefer mailing lists.) > And like mailing lists, Discourse also supports private messages. > I don't understand why Paul mentioned GPG. You want to encrypt > messages to a public mailing list? You can sign messages, but > surely almost no one actually checks the signature, and I'd be > surprised if Discourse didn't offer some built-in evidence of > identity (surely it's not like email in letting you spoof the > sender name easily?). > I heard discourse supports attachments, just that you may have > to go to the forum to attach or download them (rather than by > email). > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue Dec 3 09:54:05 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 3 Dec 2013 12:54:05 -0500 Subject: [rust-dev] Rust front-end to GCC In-Reply-To: References: Message-ID: On Tue, Dec 3, 2013 at 12:22 PM, Philip Herron wrote: > Hey all > > Some of you may have noticed the gccrs branch on the git mirror. Since PyCon > IE 2013 i gave a talk on my Python Front-end pet project and heard about > rust by a few people and i never really looked at it before until then but > i've kind of been hooked since. > > So to learn the language i've been writing this front-end to GCC. Only > really a a month or so on and off work in between work. Currently it > compiles alot of rust already in fairly little effort on my side GCC is > doing loads of the heavy lifting. > > Currently it compiles most of the basic stuff such as a struct an impl block > while loop, functions expressions calling methods passing arguments etc. > Currently focusing on getting the typing working correctly to support & and > ~ and look at how templates might work as well as need to implement break > and return. > > There is still a lot of work but i would really like to share it and see > what people think. Personally i think rust will target GCC very well and be > a good addition (if / when it works). I really want to try and give back to > this community who have been very good to me in learning over the last few > years with GSOC. > > To get a jist of what i am compiling in my tests are something like: > > fn fib1 (n:int) -> int { > if (n <= 1) { 1 } > else { n * fib1 (n - 1) } > } > > fn fib2 (n:int) -> int { > let mut i = 1; > let mut result = 1; > while (i <= n) { > result = result * i; > i = i + 1; > } > result > } > > fn main () { > fib1 (10); > fib2 (10); > } > > Or > > struct mytype { > x : int > } > > impl mytype { > fn test (self) -> int { > println ("yyoyoyo"); > test2 (1) > } > } > > fn main () { > let x = mytype { x : 1 }; > let z = x.x; > let y = x.test (); > let a = test2 (y); > } > > fn test2 (x : int) -> int { > let z = x; > 1 + z > } > > Theses are both pretty abstract test cases but were the ones i just made > work a while ago. Lots more work to do on it but i feel these 2 test cases > working is kind of a mile stone for me. > > I will start a wiki page on the project and the code i work on is at > http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gccrs and i have > it on github first mostly for travis CI and so i can do a bunch of commits > and rebase etc http://github.com/redbrain/gccrs > > Thanks > > --Phil I think another backend would be very valuable, but not another implementation of the rest of the compiler. I would expect a gcc backend to be based on libsyntax/librustc with an alternate backend for `trans` and `back`. Implementing a fully compatible compiler with a full parser/macros, metadata, type-checking, borrow checking, liveness checking, type inference, privacy/reachability, etc. doesn't seem feasible. The upstream compiler already has hundreds of issues to fix in these areas. From ben.striegel at gmail.com Tue Dec 3 09:58:13 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 3 Dec 2013 12:58:13 -0500 Subject: [rust-dev] Rust front-end to GCC In-Reply-To: References: Message-ID: This is very cool! But, I agree with Daniel. If there's any way that we can reduce the duplication of effort, we should. This is especially true given that we don't have anything close to an accurate written specification to help keep two implementations in sync. On Tue, Dec 3, 2013 at 12:54 PM, Daniel Micay wrote: > On Tue, Dec 3, 2013 at 12:22 PM, Philip Herron > wrote: > > Hey all > > > > Some of you may have noticed the gccrs branch on the git mirror. Since > PyCon > > IE 2013 i gave a talk on my Python Front-end pet project and heard about > > rust by a few people and i never really looked at it before until then > but > > i've kind of been hooked since. > > > > So to learn the language i've been writing this front-end to GCC. Only > > really a a month or so on and off work in between work. Currently it > > compiles alot of rust already in fairly little effort on my side GCC is > > doing loads of the heavy lifting. > > > > Currently it compiles most of the basic stuff such as a struct an impl > block > > while loop, functions expressions calling methods passing arguments etc. > > Currently focusing on getting the typing working correctly to support & > and > > ~ and look at how templates might work as well as need to implement break > > and return. > > > > There is still a lot of work but i would really like to share it and see > > what people think. Personally i think rust will target GCC very well and > be > > a good addition (if / when it works). I really want to try and give back > to > > this community who have been very good to me in learning over the last > few > > years with GSOC. > > > > To get a jist of what i am compiling in my tests are something like: > > > > fn fib1 (n:int) -> int { > > if (n <= 1) { 1 } > > else { n * fib1 (n - 1) } > > } > > > > fn fib2 (n:int) -> int { > > let mut i = 1; > > let mut result = 1; > > while (i <= n) { > > result = result * i; > > i = i + 1; > > } > > result > > } > > > > fn main () { > > fib1 (10); > > fib2 (10); > > } > > > > Or > > > > struct mytype { > > x : int > > } > > > > impl mytype { > > fn test (self) -> int { > > println ("yyoyoyo"); > > test2 (1) > > } > > } > > > > fn main () { > > let x = mytype { x : 1 }; > > let z = x.x; > > let y = x.test (); > > let a = test2 (y); > > } > > > > fn test2 (x : int) -> int { > > let z = x; > > 1 + z > > } > > > > Theses are both pretty abstract test cases but were the ones i just made > > work a while ago. Lots more work to do on it but i feel these 2 test > cases > > working is kind of a mile stone for me. > > > > I will start a wiki page on the project and the code i work on is at > > http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gccrs and i > have > > it on github first mostly for travis CI and so i can do a bunch of > commits > > and rebase etc http://github.com/redbrain/gccrs > > > > Thanks > > > > --Phil > > I think another backend would be very valuable, but not another > implementation of the rest of the compiler. I would expect a gcc > backend to be based on libsyntax/librustc with an alternate backend > for `trans` and `back`. > > Implementing a fully compatible compiler with a full parser/macros, > metadata, type-checking, borrow checking, liveness checking, type > inference, privacy/reachability, etc. doesn't seem feasible. The > upstream compiler already has hundreds of issues to fix in these > areas. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Tue Dec 3 10:01:34 2013 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 03 Dec 2013 19:01:34 +0100 Subject: [rust-dev] Rust forum In-Reply-To: <529E18C7.40403@mozilla.com> References: <529E18C7.40403@mozilla.com> Message-ID: On 2013-12-03 18:45, Brian Anderson wrote: > On 12/03/2013 06:02 AM, Benjamin Striegel wrote: >> > The idea of an online user forum would be that people with an >> interest in Rust can read in the user forum which is easier to peruse >> than some mail list archive. Asking and getting answers seems to work >> more fluently. >> >> I agree with the principle, but we have yet to identify what users >> would actually want to peruse in a discussion forum. For questions, we >> have StackOverflow. For keeping up with the cool projects that the >> community is working on, we have reddit. Piggybacking on established >> platforms will lead to easier discoverability and broader readership. > > I also believe that we should lean heavily on external resources > wherever possible. Maintaining our own infrastructure is very time > consuming and we've already got a lot. We could put more focus on > stackoverflow by linking it from the wiki and encouraging community > members to curate it better (I know I haven't looked at it in a long time). > > Currently, I'm more in favor of adding a rust-users mailing list than > setting up a web forum, but there are pros and cons to each approach: > > * creating another *type* of venue for general discussion runs the risk > of dividing the user base > * mailing lists are easy to create and administer at Mozilla > * web forums can be much easier to moderate, and we've had a few > incidents on the mailing list recently > * mailing lists are simple to archive and maintaining a record of Rust's > development is imortant to me > * if we did set up a forum, it seems like we should shut down the > mailing list to avoid dividing the user base, which feels kind of > unfortunate simply because having a mailing list is a matter of pride > An additional point in favor of mailing lists is that web forums cannot be accessed through a standard API (such as NNTP) which means that they cannot be accessed through the incredibly useful GMANE.org NNTP<->mailing list two-way gateway. Regards, From kevin at sb.org Tue Dec 3 10:11:51 2013 From: kevin at sb.org (Kevin Ballard) Date: Tue, 3 Dec 2013 10:11:51 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C6ADC.1090402@posteo.de> Message-ID: <93D56D6C-F2BB-4F10-9029-5151D317C9DF@sb.org> I?m curious what the technical reasons are, because I?m not sure why it wouldn?t work (it?s just an operator, after all). In any case, I prefer @ for aesthetic reasons. Also, this operator should probably bind pretty tightly (e.g. 1 * 2 at Gc would place the 2 not the 1*2), but it?s often confusing to have word operators bind tightly. For example, I think `as` binds reasonably tightly, but I still can?t remember its exact precedence. -Kevin On Dec 3, 2013, at 9:16 AM, Benjamin Striegel wrote: > If `expr @ place` suffices then you'd think that re-using `in` keyword as per `expr in place` would also work, but I believe we rejected that for technical reasons in past discussions. And if those technical reasons no longer apply, I'd like to motion that `in` looks way better than `@` there. :) > > > On Mon, Dec 2, 2013 at 6:11 AM, Michael Woerister wrote: > +1 for `expr @ place` > > > On 02.12.2013 11:57, Kevin Ballard wrote: > With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` > > -Kevin Ballard > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Tue Dec 3 10:11:51 2013 From: kevin at sb.org (Kevin Ballard) Date: Tue, 3 Dec 2013 10:11:51 -0800 Subject: [rust-dev] Placement new and the loss of `new` to keywords In-Reply-To: References: <8076B659-67E3-4442-B489-0595BEF3CA6C@sb.org> <694bd18f-3dac-408f-8f6f-46ae6ec697ae@email.android.com> <6F45565C-1EE3-43BB-86D8-905416EDD9CA@sb.org> <3fad7b41-efa8-4e25-9243-e1b96f40938b@email.android.com> <5299AAD4.6090304@mozilla.com> <9E88A001-B3BD-4615-B6F5-91D4DCF91BD9@sb.org> <529A5EA4.6050607@mozilla.com> <17ff76e7-56e4-47c6-94dd-bef653add100@email.android.com> <529A963E.5030101@babelmonkeys.de> <529B33ED.6080807@gmail.com> <529C6ADC.1090402@posteo.de> Message-ID: <93D56D6C-F2BB-4F10-9029-5151D317C9DF@sb.org> I?m curious what the technical reasons are, because I?m not sure why it wouldn?t work (it?s just an operator, after all). In any case, I prefer @ for aesthetic reasons. Also, this operator should probably bind pretty tightly (e.g. 1 * 2 at Gc would place the 2 not the 1*2), but it?s often confusing to have word operators bind tightly. For example, I think `as` binds reasonably tightly, but I still can?t remember its exact precedence. -Kevin On Dec 3, 2013, at 9:16 AM, Benjamin Striegel wrote: > If `expr @ place` suffices then you'd think that re-using `in` keyword as per `expr in place` would also work, but I believe we rejected that for technical reasons in past discussions. And if those technical reasons no longer apply, I'd like to motion that `in` looks way better than `@` there. :) > > > On Mon, Dec 2, 2013 at 6:11 AM, Michael Woerister wrote: > +1 for `expr @ place` > > > On 02.12.2013 11:57, Kevin Ballard wrote: > With @ going away another possibility is to leave ~ as the normal allocation operator and to use @ as the placement operator. So ~expr stays the same and placement looks either like `@place expr` or `expr at place` > > -Kevin Ballard > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From val at markovic.io Tue Dec 3 11:02:50 2013 From: val at markovic.io (Val Markovic) Date: Tue, 3 Dec 2013 11:02:50 -0800 Subject: [rust-dev] Rust front-end to GCC In-Reply-To: References: Message-ID: Agreed with Daniel. The D approach would be best. They one frontend and then dmd (frontend + proprietary backend), ldc (frontend + llvm) and gdc (frontend + gcc backends) use that. This would be the best for the Rust ecosystem, users and developers of the various compilers; there's no duplication of efforts and critically, very few compiler-specific bugs. One can reasonably assume that any code written for dmd will work with ldc and gdc. Multiple independent compilers would require a common, detailed spec to reach any level of interoperability. That comes with its own costs and complexities and IMO I don't think they're worth it. On Tue, Dec 3, 2013 at 9:58 AM, Benjamin Striegel wrote: > This is very cool! But, I agree with Daniel. If there's any way that we > can reduce the duplication of effort, we should. This is especially true > given that we don't have anything close to an accurate written > specification to help keep two implementations in sync. > > > On Tue, Dec 3, 2013 at 12:54 PM, Daniel Micay wrote: > >> On Tue, Dec 3, 2013 at 12:22 PM, Philip Herron >> wrote: >> > Hey all >> > >> > Some of you may have noticed the gccrs branch on the git mirror. Since >> PyCon >> > IE 2013 i gave a talk on my Python Front-end pet project and heard about >> > rust by a few people and i never really looked at it before until then >> but >> > i've kind of been hooked since. >> > >> > So to learn the language i've been writing this front-end to GCC. Only >> > really a a month or so on and off work in between work. Currently it >> > compiles alot of rust already in fairly little effort on my side GCC is >> > doing loads of the heavy lifting. >> > >> > Currently it compiles most of the basic stuff such as a struct an impl >> block >> > while loop, functions expressions calling methods passing arguments etc. >> > Currently focusing on getting the typing working correctly to support & >> and >> > ~ and look at how templates might work as well as need to implement >> break >> > and return. >> > >> > There is still a lot of work but i would really like to share it and see >> > what people think. Personally i think rust will target GCC very well >> and be >> > a good addition (if / when it works). I really want to try and give >> back to >> > this community who have been very good to me in learning over the last >> few >> > years with GSOC. >> > >> > To get a jist of what i am compiling in my tests are something like: >> > >> > fn fib1 (n:int) -> int { >> > if (n <= 1) { 1 } >> > else { n * fib1 (n - 1) } >> > } >> > >> > fn fib2 (n:int) -> int { >> > let mut i = 1; >> > let mut result = 1; >> > while (i <= n) { >> > result = result * i; >> > i = i + 1; >> > } >> > result >> > } >> > >> > fn main () { >> > fib1 (10); >> > fib2 (10); >> > } >> > >> > Or >> > >> > struct mytype { >> > x : int >> > } >> > >> > impl mytype { >> > fn test (self) -> int { >> > println ("yyoyoyo"); >> > test2 (1) >> > } >> > } >> > >> > fn main () { >> > let x = mytype { x : 1 }; >> > let z = x.x; >> > let y = x.test (); >> > let a = test2 (y); >> > } >> > >> > fn test2 (x : int) -> int { >> > let z = x; >> > 1 + z >> > } >> > >> > Theses are both pretty abstract test cases but were the ones i just made >> > work a while ago. Lots more work to do on it but i feel these 2 test >> cases >> > working is kind of a mile stone for me. >> > >> > I will start a wiki page on the project and the code i work on is at >> > http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gccrs and i >> have >> > it on github first mostly for travis CI and so i can do a bunch of >> commits >> > and rebase etc http://github.com/redbrain/gccrs >> > >> > Thanks >> > >> > --Phil >> >> I think another backend would be very valuable, but not another >> implementation of the rest of the compiler. I would expect a gcc >> backend to be based on libsyntax/librustc with an alternate backend >> for `trans` and `back`. >> >> Implementing a fully compatible compiler with a full parser/macros, >> metadata, type-checking, borrow checking, liveness checking, type >> inference, privacy/reachability, etc. doesn't seem feasible. The >> upstream compiler already has hundreds of issues to fix in these >> areas. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slabode at aim.com Tue Dec 3 11:44:37 2013 From: slabode at aim.com (SiegeLord) Date: Tue, 03 Dec 2013 14:44:37 -0500 Subject: [rust-dev] Practical usage of rustpkg Message-ID: <529E34A5.2070700@aim.com> So I've been thinking for awhile about how one would actually use rustpkg. Let me first outline my use case. I have a library and a program that uses that library, both of which I host on GitHub. One of the features of the rustpkg system is that I should be able to write this to refer to the library in my program: extern mod lib = "package_id"; Unfortunately, there is no obvious thing to put into the 'package_id' slot. There are two options: First, I could use "github.com/SiegeLord/library" as my package_id. This is problematic, as it would require one of these sub-optimal courses of action: - Stick the source of the library into workspace/src/library where I would actually develop and then use a duplicate package in the workspace/src/github.com/SiegeLord/library that would be created by rustpkg (the program is located in workspace/src/program). Somehow this duplicate package will be synced to the actual package: either through pushing to GitHub and then pulling somehow via rustpkg (this is less than ideal, as I may want to test WIP changes without committing them elsewhere/I may have no internet connection e.g. when traveling), or some manual, local git operation. - Stick the source of the library into workspace/src/github.com/SiegeLord/library and develop the library there. There is no duplication, but it really seems bizarre to me to locate a project in a directory named like that. Also, I'd be a bit paranoid about rustpkg not realizing that I never want to communicate with GitHub and having it accidentally overwriting my local changes. The second option is to use "library" as the package id. This allows me to locate my library in a logical location (workspace/src/library), but it prevents other users of my program from building it automatically. Essentially what they'll have to do is to manually check out the library repository inside their workspaces so as to create the workspace/src/library directory on their system: the `extern mod` syntax will not work otherwise. I don't think any of these options are ideal. I don't want to suggest solutions to these issues because I'm not sure how things are supposed to be used/what the planned design is. Does anybody use rustpkg seriously today? Is everybody making workspaces with a github.com/ directory where they develop their software? -SL From jurily at gmail.com Tue Dec 3 11:52:20 2013 From: jurily at gmail.com (=?ISO-8859-1?Q?Gy=F6rgy_Andrasek?=) Date: Tue, 03 Dec 2013 20:52:20 +0100 Subject: [rust-dev] Rust forum In-Reply-To: References: <658484505407764383.648605troplin-bluewin.ch@news.gmane.org> Message-ID: <529E3674.2070103@gmail.com> On 12/03/2013 02:46 PM, Gaetan wrote: > I'm in favor of a properly managed stackoverflow section. > > stackoverflow does a marvelous job for finding issue someone else has > already been confronted before. I never liked forums, search features > are always buggy, category are too restrictives, ... > > mailing list is good for what it does: emails. That's all. SO can be awesome iff we update the questions and answers regularly as the language changes. Finding an answer for 0.3 is not helpful. Provided we can do that, it should also solve our need for better tutorials. Maintaining it needs to be a full project though, unless you want to end up like http://stackoverflow.com/tags/go, where most questions haven't been updated since the day after the Google announcement. From qwertie256 at gmail.com Tue Dec 3 12:07:48 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Tue, 3 Dec 2013 13:07:48 -0700 Subject: [rust-dev] Rust forum Message-ID: > > David Piepgrass wrote: > > > Okay, well, I've never liked mailing lists at all, because: > > > > > > 1. In non-digest mode, My inbox gets flooded. > > > 2. In digest mode, it's quite inconvenient to write a reply, having to > > > cut out all the messages that I don't want to reply to and manually > edit > > > the subject line. Also, unrelated messages are grouped together while > > > threads are broken apart, making discussions harder to follow. > > > 3. In email I don't get a threaded view. If I go to mailing list > archives > > > to see a threaded view, I can't reply. > > > > Just use NNTP (gmane.comp.lang.rust.devel on news.gmane.org). Most > > newsreader support threaded view (Thunderbird does). You can configure > the > > mailing list s.t. mails are not actually delivered to your email address > > even if you are registered. > > > > But looking at your email address you are already using gmane. > > I'm using gmail; I have never used gmane and know nothing about it. I also don't have or use an email client or a newsreader. And there are lots of people like me. If gmane is the preferred way to interact with this mailing list, users clicking on the mailing list link: https://mail.mozilla.org/listinfo/rust-dev should be pointed at gmane specifically. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at sb.org Tue Dec 3 12:11:36 2013 From: kevin at sb.org (Kevin Ballard) Date: Tue, 3 Dec 2013 12:11:36 -0800 Subject: [rust-dev] Rust forum In-Reply-To: References: Message-ID: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> On Dec 3, 2013, at 12:07 PM, David Piepgrass wrote: > > David Piepgrass wrote: > > > Okay, well, I've never liked mailing lists at all, because: > > > > > > 1. In non-digest mode, My inbox gets flooded. > > > 2. In digest mode, it's quite inconvenient to write a reply, having to > > > cut out all the messages that I don't want to reply to and manually edit > > > the subject line. Also, unrelated messages are grouped together while > > > threads are broken apart, making discussions harder to follow. > > > 3. In email I don't get a threaded view. If I go to mailing list archives > > > to see a threaded view, I can't reply. > > > > Just use NNTP (gmane.comp.lang.rust.devel on news.gmane.org). Most > > newsreader support threaded view (Thunderbird does). You can configure the > > mailing list s.t. mails are not actually delivered to your email address > > even if you are registered. > > > > But looking at your email address you are already using gmane. > > I'm using gmail; I have never used gmane and know nothing about it. I also don't have or use an email client or a newsreader. And there are lots of people like me. Gmail has the ability to file mailing list messages into a label and out of the inbox. I recommend doing this for any mailing list that has more than one post per day. You can then click on the label to peruse the list. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From slabode at aim.com Tue Dec 3 12:21:45 2013 From: slabode at aim.com (SiegeLord) Date: Tue, 03 Dec 2013 15:21:45 -0500 Subject: [rust-dev] Rust front-end to GCC In-Reply-To: References: Message-ID: <529E3D59.9060707@aim.com> On 12/03/2013 02:02 PM, Val Markovic wrote: > Agreed with Daniel. The D approach would be best. They one frontend and > then dmd (frontend + proprietary backend), ldc (frontend + llvm) and gdc > (frontend + gcc backends) use that. This would be the best for the Rust > ecosystem, users and developers of the various compilers; there's no > duplication of efforts and critically, very few compiler-specific bugs. > One can reasonably assume that any code written for dmd will work with > ldc and gdc. LDC and GDC do not use the same frontend by choice, but because historically every attempt to create a new D frontend has failed to bear fruit (SDC and DIL) in part because of a lack of a concrete specification and the resultant lack of clarity of how exactly some code should work. The reliance (over-reliance in my opinion) on the DMD frontend resulted in a lack of focus on creating a good language specification which to this day results in debates about what exactly constitutes a language change and what constitutes a bug fix. > Multiple independent compilers would require a common, detailed spec to > reach any level of interoperability. That comes with its own costs and > complexities and IMO I don't think they're worth it. A new frontend implementation can motivate and help the writing of the spec to begin with, assuming Philip is willing to keep implementation notes as he goes along. -SL From thadguidry at gmail.com Tue Dec 3 12:32:23 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Tue, 3 Dec 2013 14:32:23 -0600 Subject: [rust-dev] Rust forum In-Reply-To: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: Kevin is correct. Where the real issue is that of knowing the capabilities of your particular mail client and maximizing it to gain forum-like features. Many folks use or prefer an online mail client that offers threading, labels, archival search, etc. Which are all the same features of a forum that is proposed. My suggestion would be instead of jumping to a forum... simply learn about or find a more full featured mail client if you can. If you cannot, then perhaps Gmane could benefit you in the same way. Users benefit from the developers list and vice-versa... splitting us apart would not be a wise choice. -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From martindemello at gmail.com Tue Dec 3 12:41:55 2013 From: martindemello at gmail.com (Martin DeMello) Date: Tue, 3 Dec 2013 12:41:55 -0800 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry wrote: > Users benefit from the developers list and vice-versa... splitting us > apart would not be a wise choice. > the only downside is that people are reluctant to ask newbie user questions on a list where people are talking about hacking on the compiler. martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.spir at gmail.com Tue Dec 3 13:14:16 2013 From: denis.spir at gmail.com (spir) Date: Tue, 03 Dec 2013 22:14:16 +0100 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: <529E49A8.80901@gmail.com> On 12/03/2013 09:41 PM, Martin DeMello wrote: > On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry wrote: > >> Users benefit from the developers list and vice-versa... splitting us >> apart would not be a wise choice. >> > > the only downside is that people are reluctant to ask newbie user questions > on a list where people are talking about hacking on the compiler. Very true. Denis From gaetan at xeberon.net Tue Dec 3 13:58:19 2013 From: gaetan at xeberon.net (Gaetan) Date: Tue, 3 Dec 2013 22:58:19 +0100 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: Sorry but that is a pretty bad answer. You cannot tell people to change their favorite email client just for rust-dev. You cannot do the same with you client, just because each one will have to set its own set of rules to tag, ... Gmail is a pretty good client, but you have to remember the golden rules of email: email is forgotten once it is read. And you cannot search on emails you havent received... Self hosted forum is good, a good rust management in stack overflow is much better. If you know better sites, why not making some experiment and then vote for the better one. G. Le 3 d?c. 2013 21:32, "Thad Guidry" a ?crit : > Kevin is correct. > > Where the real issue is that of knowing the capabilities of your > particular mail client and maximizing it to gain forum-like features. > > Many folks use or prefer an online mail client that offers threading, > labels, archival search, etc. Which are all the same features of a forum > that is proposed. > > My suggestion would be instead of jumping to a forum... simply learn about > or find a more full featured mail client if you can. > If you cannot, then perhaps Gmane could benefit you in the same way. > > Users benefit from the developers list and vice-versa... splitting us > apart would not be a wise choice. > -- > -Thad > +ThadGuidry > Thad on LinkedIn > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martindemello at gmail.com Tue Dec 3 14:01:05 2013 From: martindemello at gmail.com (Martin DeMello) Date: Tue, 3 Dec 2013 14:01:05 -0800 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: keeping up with email is a lot easier than pretty much everything else, though. the solution to keeping old messages around is mirroring the mailing list to a searchable archive, not moving to a forum en masse and sacrificing ease-of-conversation for ease-of-recall. martin On Tue, Dec 3, 2013 at 1:58 PM, Gaetan wrote: > Sorry but that is a pretty bad answer. You cannot tell people to change > their favorite email client just for rust-dev. > > You cannot do the same with you client, just because each one will have to > set its own set of rules to tag, ... > > Gmail is a pretty good client, but you have to remember the golden rules > of email: email is forgotten once it is read. And you cannot search on > emails you havent received... > > Self hosted forum is good, a good rust management in stack overflow is > much better. If you know better sites, why not making some experiment and > then vote for the better one. > > G. > Le 3 d?c. 2013 21:32, "Thad Guidry" a ?crit : > >> Kevin is correct. >> >> Where the real issue is that of knowing the capabilities of your >> particular mail client and maximizing it to gain forum-like features. >> >> Many folks use or prefer an online mail client that offers threading, >> labels, archival search, etc. Which are all the same features of a forum >> that is proposed. >> >> My suggestion would be instead of jumping to a forum... simply learn >> about or find a more full featured mail client if you can. >> If you cannot, then perhaps Gmane could benefit you in the same way. >> >> Users benefit from the developers list and vice-versa... splitting us >> apart would not be a wise choice. >> -- >> -Thad >> +ThadGuidry >> Thad on LinkedIn >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Tue Dec 3 14:20:27 2013 From: gaetan at xeberon.net (Gaetan) Date: Tue, 3 Dec 2013 23:20:27 +0100 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: I also agree to split in rust-user for newbee question, but i hope good programmers will go a bit on this ml... Le 3 d?c. 2013 21:42, "Martin DeMello" a ?crit : > On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry wrote: > >> Users benefit from the developers list and vice-versa... splitting us >> apart would not be a wise choice. >> > > the only downside is that people are reluctant to ask newbie user > questions on a list where people are talking about hacking on the compiler. > > martin > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thadguidry at gmail.com Tue Dec 3 14:22:10 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Tue, 3 Dec 2013 16:22:10 -0600 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: Agreed with Martin. It is my Opinion, but it might not be a good answer for you. If the problem space is having a searchable mailing list archive... I think we already have that in place, Right Brian ? On Tue, Dec 3, 2013 at 4:01 PM, Martin DeMello wrote: > keeping up with email is a lot easier than pretty much everything else, > though. the solution to keeping old messages around is mirroring the > mailing list to a searchable archive, not moving to a forum en masse and > sacrificing ease-of-conversation for ease-of-recall. > > martin > > > On Tue, Dec 3, 2013 at 1:58 PM, Gaetan wrote: > >> Sorry but that is a pretty bad answer. You cannot tell people to change >> their favorite email client just for rust-dev. >> >> You cannot do the same with you client, just because each one will have >> to set its own set of rules to tag, ... >> >> Gmail is a pretty good client, but you have to remember the golden rules >> of email: email is forgotten once it is read. And you cannot search on >> emails you havent received... >> >> Self hosted forum is good, a good rust management in stack overflow is >> much better. If you know better sites, why not making some experiment and >> then vote for the better one. >> >> G. >> Le 3 d?c. 2013 21:32, "Thad Guidry" a ?crit : >> >>> Kevin is correct. >>> >>> Where the real issue is that of knowing the capabilities of your >>> particular mail client and maximizing it to gain forum-like features. >>> >>> Many folks use or prefer an online mail client that offers threading, >>> labels, archival search, etc. Which are all the same features of a forum >>> that is proposed. >>> >>> My suggestion would be instead of jumping to a forum... simply learn >>> about or find a more full featured mail client if you can. >>> If you cannot, then perhaps Gmane could benefit you in the same way. >>> >>> Users benefit from the developers list and vice-versa... splitting us >>> apart would not be a wise choice. >>> -- >>> -Thad >>> +ThadGuidry >>> Thad on LinkedIn >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From martindemello at gmail.com Tue Dec 3 14:32:21 2013 From: martindemello at gmail.com (Martin DeMello) Date: Tue, 3 Dec 2013 14:32:21 -0800 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: In practice this has worked out well for the ocaml community - there's an ocaml-beginners mailing list that gets a small amount of traffic, but very quick responses from a lot of the more experienced people on the list. martin On Tue, Dec 3, 2013 at 2:20 PM, Gaetan wrote: > I also agree to split in rust-user for newbee question, but i hope good > programmers will go a bit on this ml... > Le 3 d?c. 2013 21:42, "Martin DeMello" a ?crit : > >> On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry wrote: >> >>> Users benefit from the developers list and vice-versa... splitting us >>> apart would not be a wise choice. >>> >> >> the only downside is that people are reluctant to ask newbie user >> questions on a list where people are talking about hacking on the compiler. >> >> martin >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Tue Dec 3 16:19:34 2013 From: corey at octayn.net (Corey Richardson) Date: Tue, 3 Dec 2013 19:19:34 -0500 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: Very well for the Python community, too; there's a python-tutor list whose sole focus is helping newbies effectively. On Tue, Dec 3, 2013 at 5:32 PM, Martin DeMello wrote: > In practice this has worked out well for the ocaml community - there's an > ocaml-beginners mailing list that gets a small amount of traffic, but very > quick responses from a lot of the more experienced people on the list. > > martin > > > On Tue, Dec 3, 2013 at 2:20 PM, Gaetan wrote: >> >> I also agree to split in rust-user for newbee question, but i hope good >> programmers will go a bit on this ml... >> >> Le 3 d?c. 2013 21:42, "Martin DeMello" a ?crit : >>> >>> On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry >>> wrote: >>>> >>>> Users benefit from the developers list and vice-versa... splitting us >>>> apart would not be a wise choice. >>> >>> >>> the only downside is that people are reluctant to ask newbie user >>> questions on a list where people are talking about hacking on the compiler. >>> >>> martin >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From val at markovic.io Tue Dec 3 16:20:01 2013 From: val at markovic.io (Val Markovic) Date: Tue, 3 Dec 2013 16:20:01 -0800 Subject: [rust-dev] Ideas of small projects or improvements In-Reply-To: References: <529A3174.8060701@hyc.io> <529B989E.9080509@hyc.io> <529BA8E8.2060503@gmail.com> <529BAB2E.6010603@hyc.io> Message-ID: On Sun, Dec 1, 2013 at 1:43 PM, Daniel Micay wrote: > Ranges are a more > modern implementation of iterators and are much more easily composed. > Ranges are also trivially memory safe, and I doubt that split > current/end iterators can provide memory safety with only references. > Agreed with Daniel. The C++ community has by and large reached the conclusion that ranges are a much better idea than iterators. Boost.Range is commonly recommended. There's also talk about getting ranges into the C++ standard; see N3350for an example. Let's not make the same mistake in Rust that C++ is now struggling to fix. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From com.liigo at gmail.com Tue Dec 3 16:23:15 2013 From: com.liigo at gmail.com (Liigo Zhuang) Date: Wed, 4 Dec 2013 08:23:15 +0800 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: +1 ? 2013?12?4? ??5:58?"Gaetan" ??? > Sorry but that is a pretty bad answer. You cannot tell people to change > their favorite email client just for rust-dev. > > You cannot do the same with you client, just because each one will have to > set its own set of rules to tag, ... > > Gmail is a pretty good client, but you have to remember the golden rules > of email: email is forgotten once it is read. And you cannot search on > emails you havent received... > > Self hosted forum is good, a good rust management in stack overflow is > much better. If you know better sites, why not making some experiment and > then vote for the better one. > > G. > Le 3 d?c. 2013 21:32, "Thad Guidry" a ?crit : > >> Kevin is correct. >> >> Where the real issue is that of knowing the capabilities of your >> particular mail client and maximizing it to gain forum-like features. >> >> Many folks use or prefer an online mail client that offers threading, >> labels, archival search, etc. Which are all the same features of a forum >> that is proposed. >> >> My suggestion would be instead of jumping to a forum... simply learn >> about or find a more full featured mail client if you can. >> If you cannot, then perhaps Gmane could benefit you in the same way. >> >> Users benefit from the developers list and vice-versa... splitting us >> apart would not be a wise choice. >> -- >> -Thad >> +ThadGuidry >> Thad on LinkedIn >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at redivi.com Tue Dec 3 16:38:46 2013 From: bob at redivi.com (Bob Ippolito) Date: Tue, 3 Dec 2013 16:38:46 -0800 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: Haskell has haskell-beginners, which also seems to be working. On Tue, Dec 3, 2013 at 4:19 PM, Corey Richardson wrote: > Very well for the Python community, too; there's a python-tutor list > whose sole focus is helping newbies effectively. > > On Tue, Dec 3, 2013 at 5:32 PM, Martin DeMello > wrote: > > In practice this has worked out well for the ocaml community - there's an > > ocaml-beginners mailing list that gets a small amount of traffic, but > very > > quick responses from a lot of the more experienced people on the list. > > > > martin > > > > > > On Tue, Dec 3, 2013 at 2:20 PM, Gaetan wrote: > >> > >> I also agree to split in rust-user for newbee question, but i hope good > >> programmers will go a bit on this ml... > >> > >> Le 3 d?c. 2013 21:42, "Martin DeMello" a > ?crit : > >>> > >>> On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry > >>> wrote: > >>>> > >>>> Users benefit from the developers list and vice-versa... splitting us > >>>> apart would not be a wise choice. > >>> > >>> > >>> the only downside is that people are reluctant to ask newbie user > >>> questions on a list where people are talking about hacking on the > compiler. > >>> > >>> martin > >>> > >>> _______________________________________________ > >>> Rust-dev mailing list > >>> Rust-dev at mozilla.org > >>> https://mail.mozilla.org/listinfo/rust-dev > >>> > > > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Tue Dec 3 17:23:21 2013 From: comexk at gmail.com (comex) Date: Tue, 3 Dec 2013 20:23:21 -0500 Subject: [rust-dev] Rust forum In-Reply-To: References: Message-ID: On Tue, Dec 3, 2013 at 3:07 PM, David Piepgrass wrote: > I'm using gmail In Gmail, putting messages from the list in their own label and skipping the inbox is just a matter of 'More -> Filter messages like these' and a few clicks; Gmail displays messages in a flat conversation view rather than true nested threading, but Discourse does the same. So I don't really understand your points... From banderson at mozilla.com Tue Dec 3 17:36:49 2013 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 03 Dec 2013 17:36:49 -0800 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: <529E8731.5000004@mozilla.com> On 12/03/2013 02:22 PM, Thad Guidry wrote: > Agreed with Martin. > > It is my Opinion, but it might not be a good answer for you. > > If the problem space is having a searchable mailing list archive... I > think we already have that in place, Right Brian ? I actually don't know how to search the rust-dev archives without Google's help... > > > > On Tue, Dec 3, 2013 at 4:01 PM, Martin DeMello > > wrote: > > keeping up with email is a lot easier than pretty much everything > else, though. the solution to keeping old messages around is > mirroring the mailing list to a searchable archive, not moving to > a forum en masse and sacrificing ease-of-conversation for > ease-of-recall. > > martin > > > On Tue, Dec 3, 2013 at 1:58 PM, Gaetan > wrote: > > Sorry but that is a pretty bad answer. You cannot tell people > to change their favorite email client just for rust-dev. > > You cannot do the same with you client, just because each one > will have to set its own set of rules to tag, ... > > Gmail is a pretty good client, but you have to remember the > golden rules of email: email is forgotten once it is read. And > you cannot search on emails you havent received... > > Self hosted forum is good, a good rust management in stack > overflow is much better. If you know better sites, why not > making some experiment and then vote for the better one. > > G. > > Le 3 d?c. 2013 21:32, "Thad Guidry" > a ?crit : > > Kevin is correct. > > Where the real issue is that of knowing the capabilities > of your particular mail client and maximizing it to gain > forum-like features. > > Many folks use or prefer an online mail client that offers > threading, labels, archival search, etc. Which are all > the same features of a forum that is proposed. > > My suggestion would be instead of jumping to a forum... > simply learn about or find a more full featured mail > client if you can. > If you cannot, then perhaps Gmane could benefit you in the > same way. > > Users benefit from the developers list and vice-versa... > splitting us apart would not be a wise choice. > -- > -Thad > +ThadGuidry > Thad on LinkedIn > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -- > -Thad > +ThadGuidry > Thad on LinkedIn > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at kevincantu.org Tue Dec 3 17:57:23 2013 From: me at kevincantu.org (Kevin Cantu) Date: Tue, 3 Dec 2013 17:57:23 -0800 Subject: [rust-dev] Rust forum In-Reply-To: <529E8731.5000004@mozilla.com> References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> <529E8731.5000004@mozilla.com> Message-ID: I've never used a message board which I could search without Google's help, either. ArsTechnica's search was chronically broken for like a decade, for example. :D Kevin On Tue, Dec 3, 2013 at 5:36 PM, Brian Anderson wrote: > On 12/03/2013 02:22 PM, Thad Guidry wrote: > > Agreed with Martin. > > It is my Opinion, but it might not be a good answer for you. > > If the problem space is having a searchable mailing list archive... I think > we already have that in place, Right Brian ? > > > I actually don't know how to search the rust-dev archives without Google's > help... > > > > > > > On Tue, Dec 3, 2013 at 4:01 PM, Martin DeMello > wrote: >> >> keeping up with email is a lot easier than pretty much everything else, >> though. the solution to keeping old messages around is mirroring the mailing >> list to a searchable archive, not moving to a forum en masse and sacrificing >> ease-of-conversation for ease-of-recall. >> >> martin >> >> >> On Tue, Dec 3, 2013 at 1:58 PM, Gaetan wrote: >>> >>> Sorry but that is a pretty bad answer. You cannot tell people to change >>> their favorite email client just for rust-dev. >>> >>> You cannot do the same with you client, just because each one will have >>> to set its own set of rules to tag, ... >>> >>> Gmail is a pretty good client, but you have to remember the golden rules >>> of email: email is forgotten once it is read. And you cannot search on >>> emails you havent received... >>> >>> Self hosted forum is good, a good rust management in stack overflow is >>> much better. If you know better sites, why not making some experiment and >>> then vote for the better one. >>> >>> G. >>> >>> Le 3 d?c. 2013 21:32, "Thad Guidry" a ?crit : >>>> >>>> Kevin is correct. >>>> >>>> Where the real issue is that of knowing the capabilities of your >>>> particular mail client and maximizing it to gain forum-like features. >>>> >>>> Many folks use or prefer an online mail client that offers threading, >>>> labels, archival search, etc. Which are all the same features of a forum >>>> that is proposed. >>>> >>>> My suggestion would be instead of jumping to a forum... simply learn >>>> about or find a more full featured mail client if you can. >>>> If you cannot, then perhaps Gmane could benefit you in the same way. >>>> >>>> Users benefit from the developers list and vice-versa... splitting us >>>> apart would not be a wise choice. >>>> -- >>>> -Thad >>>> +ThadGuidry >>>> Thad on LinkedIn >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> > > > > -- > -Thad > +ThadGuidry > Thad on LinkedIn > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From ben.striegel at gmail.com Tue Dec 3 19:11:51 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 3 Dec 2013 22:11:51 -0500 Subject: [rust-dev] How to search the mailing list archives Message-ID: Apparently even Brian doesn't know how to do this, so I figured I'd share this tip. The rust-dev mailing list is archived here: http://thread.gmane.org/gmane.comp.lang.rust.devel/ Use the search box at the bottom to search through the mailing list's archives since the beginning of time. When you click on a result, you will end up on a page like this: http://article.gmane.org/gmane.comp.lang.rust.devel/6778/match=dst ...which is pretty terrible from a navigation standpoint. But in that URL you can manually change the "article" bit on the front to "thread", to yield this: http://thread.gmane.org/gmane.comp.lang.rust.devel/6778/match=dst ...which will let you easily browse a full conversation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Tue Dec 3 20:01:56 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Wed, 4 Dec 2013 05:01:56 +0100 Subject: [rust-dev] Distilled essence of placement new Message-ID: Prompted by the recent discussion about the syntax to use for placement new, I took a few steps back to think about the bigger picture. I'm glad I did, because I now think that the important part of the feature has been misidentified so far, and correctly identifying it opens the door to a much more general and powerful mechanism, with a smaller conceptual "surface area", and whose implementation burden doesn't appear any larger than that of the placement new feature as up-to-now envisioned (in particular, the magic sauce is the same in both). ## What is placement new? The C++ syntax for "placement new" is: `new (place) MyType(args...)`, where place is a memory address. This constructs a new instance of `MyType` into `place`. This is useful because it lets you avoid the overhead of first constructing the `MyType` elsewhere and then copying or moving it into `place`. I used to think that placement new is not commonly used in C++, but I have revised my opinion. As Daniel Micay reminded me of in the other thread, C++ now has things like `emplace_back` in many places which use placement new under the hood to avoid the cost of a move. The reason C++ didn't *previously* use placement new very often is that the lack of perfect forwarding and variadic templates made doing so in a generic way way too painful. This is also one of the things that got me thinking: restricting our version of placement new to smart pointers seems artificial and not very well-motivated, except if by the fact that smart pointers are an important use case and the built-in ones already have the feature. But we also want `emplace_back`, don't we? ## What is placement new, *really*? The C++ signature of `emplace_back` is: template // I'm ignoring the allocator template void vector::emplace_back(Args&&... args); What it does is reserve some memory at the end of the vector, then use placement new to invoke the constructor of `T`, with `args`, into that memory. How could we translate this to Rust? First of all, Rust doesn't have constructors as a distinguished language feature. But a constructor is not anything more than a function statically known based on a type: in Rust, a (self-less) trait method. Rust doesn't have variadic templates either, but we could use tuples. (As for perfect forwarding, I suspect it solves a problem Rust doesn't have.) So then we have: trait Construct { fn construct(Args) -> Self; } fn emplace_back>(self: &mut Vec, args: Args); So in reality, placement new is nothing more than a statically dispatched trait method call. The only reason C++ needs special syntax for it is because C++ distinguishes constructors from other functions. In particular, it's worth noticing that if C++'s functions use a hidden out-pointer argument like Rust's functions do, then the C++ version of `emplace_back` could just as well take a function pointer returning `T` as a non-type template parameter, and call that instead of T's constructor. (Except C++ doesn't let you make a function pointer to a constructor either, so you would still want both versions. C++'s complications are of its own design.) (It's also worth noticing that C++ is using the same pass-the-environment-explicitly encoding of closures here that Rust occasionally does.) ## Magic sauce All of that begs a question: if placement new is not much more than calling a trait method, then why are we in the process of adding placement new? If what we're adding isn't placement new, then what *is* it? Well: we *could* use something like the above Rust version of `emplace_back`, but it would be super-tedious. Right now if you write `~(this thing)` or `@(that thing)`, this thing and that thing are constructed (placement newed) directly into the allocated memory -- where this thing and that thing can be any expression. That's really nice. We want other smart pointers to be able to do that. How does it work? If this thing or that thing is a function call, then the out-pointer is set to the allocated memory. If it's an expression, then the compiler emits code to put the result of the expression directly into the memory. Without having direct knowledge, I imagine that's the same way it's planned to work for other smart pointers. (I can't imagine any other way to do it.) What this implies is that the function that allocates the memory is monomorphized (has a separate version generated) not only on the type of the object being constructed, but also on the specific expression constructing it. This is no different from what happens with the current built-in smart pointers, where the compiler has built-in special-cased code generation for them. It's also no different from C++'s `emplace_back`, except there the possible "expressions" are limited to the constructors available for the type. (If you consider the hypothetical version passing a function pointer as a template argument, then the number of possibilities is again much larger.) So what we're adding is this ability to monomorphize user-provided functions (smart pointer constructors) on the expression provided as their argument. ## Proposal Given that we're adding this magic one way or another, I propose to make it more generally available. Rather than restrict it to smart pointer constructors, tied in to the compiler with some kind of built-in trait, let's let *any* function use it: let them declare that any particular argument is to be passed "by-expression" in this way, by monomorphizing the function over it. To avoid duplicating side effects and such, in the body of the function, this argument may only be used once (which already holds in the case of things like smart pointer constructors and `emplace_back`). (So it's kind of like call-by-name, except it happens statically and can only be called once.) With regards to syntax, I don't have any ideas yet that I'm particularly satisfied with. Here are some ideas: fn new_gc(x: expr T) -> Gc; fn new_gc(x: Exp) -> Gc; fn new_gc(x) -> Gc; It's difficult because the expression parameter wants to be passed both between `<>`, because it's passed at compile time and leads to monomorphization, and also between `()`, because that's where the programmer actually writes the argument when calling it. I think I like the second possibility best so far: in that case you can interpret it as working with inference like type parameters do. (But I don't even know whether or not there might be other good possibilities besides an `expr` keyword, as in all three of these.) Anyways, upshot: * Instead of being a restricted subset of C++, our "placement new" ability becomes much broader and more convenient than C++ * We no longer need special "placement new" syntax, and can keep writing `Gc::new(some thing)`, because the magic is moved to the callee * In exchange, we do need special syntax in the callee, so bikeshed painters will not have their employment prospects diminished. Thanks for reading: G?bor -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue Dec 3 20:05:45 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 3 Dec 2013 23:05:45 -0500 Subject: [rust-dev] Distilled essence of placement new In-Reply-To: References: Message-ID: This looks a lot like what stack once functions would provide. From illissius at gmail.com Tue Dec 3 20:10:32 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Wed, 4 Dec 2013 05:10:32 +0100 Subject: [rust-dev] Distilled essence of placement new In-Reply-To: References: Message-ID: Yes, that was one of the things that passed through my mind as well. One difference is that those are passed at runtime, whereas here everything happens at compile time. I remember LLVM had difficulty reliably optimizing runtime closure passing code, like with the old iterators. On Wed, Dec 4, 2013 at 5:05 AM, Daniel Micay wrote: > This looks a lot like what stack once functions would provide. > -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Tue Dec 3 20:13:26 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Tue, 03 Dec 2013 20:13:26 -0800 Subject: [rust-dev] Distilled essence of placement new In-Reply-To: References: Message-ID: <8f5caf0b-6970-4190-9993-d030e9fd64d2@email.android.com> Placement new does support "emplace_back". You'd write "box(my_array.in_back()) value", where "in_back" returns a special allocator value that implements the placement new trait. Having functions that can change the evaluation order of their arguments feels too magical to me. Almost fexpr-ish. Patrick "G?bor Lehel" wrote: >Prompted by the recent discussion about the syntax to use for placement >new, I took a few steps back to think about the bigger picture. I'm >glad I >did, because I now think that the important part of the feature has >been >misidentified so far, and correctly identifying it opens the door to a >much >more general and powerful mechanism, with a smaller conceptual "surface >area", and whose implementation burden doesn't appear any larger than >that >of the placement new feature as up-to-now envisioned (in particular, >the >magic sauce is the same in both). > > >## What is placement new? > >The C++ syntax for "placement new" is: `new (place) MyType(args...)`, >where >place is a memory address. This constructs a new instance of `MyType` >into >`place`. This is useful because it lets you avoid the overhead of first >constructing the `MyType` elsewhere and then copying or moving it into >`place`. > >I used to think that placement new is not commonly used in C++, but I >have >revised my opinion. As Daniel Micay reminded me of in the other thread, >C++ >now has things like `emplace_back` in many places which use placement >new >under the hood to avoid the cost of a move. The reason C++ didn't >*previously* use placement new very often is that the lack of perfect >forwarding and variadic templates made doing so in a generic way way >too >painful. > >This is also one of the things that got me thinking: restricting our >version of placement new to smart pointers seems artificial and not >very >well-motivated, except if by the fact that smart pointers are an >important >use case and the built-in ones already have the feature. But we also >want >`emplace_back`, don't we? > > >## What is placement new, *really*? > >The C++ signature of `emplace_back` is: > > template // I'm ignoring the allocator > template > void vector::emplace_back(Args&&... args); > >What it does is reserve some memory at the end of the vector, then use >placement new to invoke the constructor of `T`, with `args`, into that >memory. How could we translate this to Rust? First of all, Rust doesn't >have constructors as a distinguished language feature. But a >constructor is >not anything more than a function statically known based on a type: in >Rust, a (self-less) trait method. Rust doesn't have variadic templates >either, but we could use tuples. (As for perfect forwarding, I suspect >it >solves a problem Rust doesn't have.) So then we have: > > trait Construct { > fn construct(Args) -> Self; > } > > fn emplace_back>(self: &mut Vec, args: >Args); > >So in reality, placement new is nothing more than a statically >dispatched >trait method call. The only reason C++ needs special syntax for it is >because C++ distinguishes constructors from other functions. In >particular, >it's worth noticing that if C++'s functions use a hidden out-pointer >argument like Rust's functions do, then the C++ version of >`emplace_back` >could just as well take a function pointer returning `T` as a non-type >template parameter, and call that instead of T's constructor. (Except >C++ >doesn't let you make a function pointer to a constructor either, so you >would still want both versions. C++'s complications are of its own >design.) > >(It's also worth noticing that C++ is using the same >pass-the-environment-explicitly encoding of closures here that Rust >occasionally does.) > > >## Magic sauce > >All of that begs a question: if placement new is not much more than >calling >a trait method, then why are we in the process of adding placement new? >If >what we're adding isn't placement new, then what *is* it? Well: we >*could* >use something like the above Rust version of `emplace_back`, but it >would >be super-tedious. Right now if you write `~(this thing)` or `@(that >thing)`, this thing and that thing are constructed (placement newed) >directly into the allocated memory -- where this thing and that thing >can >be any expression. That's really nice. We want other smart pointers to >be >able to do that. > >How does it work? If this thing or that thing is a function call, then >the >out-pointer is set to the allocated memory. If it's an expression, then >the >compiler emits code to put the result of the expression directly into >the >memory. Without having direct knowledge, I imagine that's the same way >it's >planned to work for other smart pointers. (I can't imagine any other >way to >do it.) What this implies is that the function that allocates the >memory is >monomorphized (has a separate version generated) not only on the type >of >the object being constructed, but also on the specific expression >constructing it. This is no different from what happens with the >current >built-in smart pointers, where the compiler has built-in special-cased >code >generation for them. It's also no different from C++'s `emplace_back`, >except there the possible "expressions" are limited to the constructors >available for the type. (If you consider the hypothetical version >passing a >function pointer as a template argument, then the number of >possibilities >is again much larger.) > >So what we're adding is this ability to monomorphize user-provided >functions (smart pointer constructors) on the expression provided as >their >argument. > > >## Proposal > >Given that we're adding this magic one way or another, I propose to >make it >more generally available. Rather than restrict it to smart pointer >constructors, tied in to the compiler with some kind of built-in trait, >let's let *any* function use it: let them declare that any particular >argument is to be passed "by-expression" in this way, by monomorphizing >the >function over it. To avoid duplicating side effects and such, in the >body >of the function, this argument may only be used once (which already >holds >in the case of things like smart pointer constructors and >`emplace_back`). >(So it's kind of like call-by-name, except it happens statically and >can >only be called once.) > >With regards to syntax, I don't have any ideas yet that I'm >particularly >satisfied with. Here are some ideas: > > fn new_gc(x: expr T) -> Gc; > > fn new_gc(x: Exp) -> Gc; > > fn new_gc(x) -> Gc; > >It's difficult because the expression parameter wants to be passed both >between `<>`, because it's passed at compile time and leads to >monomorphization, and also between `()`, because that's where the >programmer actually writes the argument when calling it. I think I like >the >second possibility best so far: in that case you can interpret it as >working with inference like type parameters do. (But I don't even know >whether or not there might be other good possibilities besides an >`expr` >keyword, as in all three of these.) > > >Anyways, upshot: > >* Instead of being a restricted subset of C++, our "placement new" >ability >becomes much broader and more convenient than C++ > >* We no longer need special "placement new" syntax, and can keep >writing >`Gc::new(some thing)`, because the magic is moved to the callee > > * In exchange, we do need special syntax in the callee, so bikeshed >painters will not have their employment prospects diminished. > > >Thanks for reading: >G?bor > >-- >Your ship was destroyed in a monadic eruption. > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Tue Dec 3 20:57:24 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Tue, 03 Dec 2013 20:57:24 -0800 Subject: [rust-dev] Distilled essence of placement new In-Reply-To: References: Message-ID: I should elaborate: I think you've successfully formulated placement new in terms of unboxed closures as monomorphized traits whose "call" method takes self by value. That is, something like (in Rust of the future): fn GC>(f: F) -> GC The difference, though, is that the construction of the closure is implicit at the call site in this proposal. This is what I'm uncomfortable with. Rust is a strict language, not a lazy one, and the order of evaluation of function arguments is one of the things that one has heretofore been unable to change. I would prefer that a different argument evaluation order would necessitate some sort of annotation at the call site (e.g. ocaml's "lazy"). But once you've done that you've essentially recreated something equivalent to placement new, but more verbose since you have to name a method when you allocate into an object (e.g. instead of "box(my_arena) foo" you'd have to write "my_arena.alloc(lazy foo)". I think we would end up wanting the sugar. Patrick "G?bor Lehel" wrote: >Yes, that was one of the things that passed through my mind as well. >One >difference is that those are passed at runtime, whereas here everything >happens at compile time. I remember LLVM had difficulty reliably >optimizing >runtime closure passing code, like with the old iterators. > > >On Wed, Dec 4, 2013 at 5:05 AM, Daniel Micay >wrote: > >> This looks a lot like what stack once functions would provide. >> > > > >-- >Your ship was destroyed in a monadic eruption. > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnathan at vandals.uidaho.edu Tue Dec 3 21:31:28 2013 From: pnathan at vandals.uidaho.edu (Paul Nathan) Date: Tue, 3 Dec 2013 21:31:28 -0800 Subject: [rust-dev] Rust forum In-Reply-To: References: Message-ID: <529EBE30.9090107@vandals.uidaho.edu> Apologies for getting this reply late, but I had to run before I finished this email. Replies inline and bottom-posted. ;-) On 12/2/13 9:45 PM, David Piepgrass wrote: > On 02/12/2013 16:21, David Piepgrass wrote: > > > That would be so. much. better. than a mailing list. > > Hi. Could you expand on this? I don?t necessarily disagree, but as the > one proposing change it?s up to you to convince everyone else :) > > -- > Simon Sapin > > > Okay, well, I've never liked mailing lists at all, because: > > 1. In non-digest mode, My inbox gets flooded. > 2. In digest mode, it's quite inconvenient to write a reply, having to > cut out all the messages that I don't want to reply to and manually edit > the subject line. Also, unrelated messages are grouped together while > threads are broken apart, making discussions harder to follow. > 3. In email I don't get a threaded view. If I go to mailing list > archives to see a threaded view, I can't reply. > 4. I have to manually watch for replies to my messages or to threads I'm > following. If someone mentions my name (not that they would), I won't be > notified. > I respectfully suggest that you consider finding a new email client. These are solved problems. > In contrast, Discourse has a variety of email notification options. I > don't know if those options are enough to please everybody, but you can > probably configure it to notify you about all posts, which makes it > essentially equivalent to a mailing list. It supports reply by email, so > those that prefer a mailing list can still pretend it's a mailing list. > Currently I'm getting an shrunk digest of Discourse Meta--by email I > only get a subset of all messages, auto-selected by Discourse, whatever > it thinks is interesting. That's good for me: I really don't want to see > every message. > Filters in a mail client address this. > Plus, a mailing list offers less privacy as it mandates publishing your > email address. That's not a big deal for me personally, but do you > really want to require that from every Rust user? A quite reasonable point, no doubt about it. I have chosen to use my alumni email with my real name, but I recognize that others might choose otherwise. > > (btw, if I'm wrong about any of the above points, I promise there are > lots of other netizens out there who have the same misconception(s), so > many of them will avoid mailing lists. The fact that y'all are talking > to me on a mailing list suggests that the disadvantages of a mailing > list are not a big deal *to you*, but as for those who aren't > participating, you can't conclude *they* prefer mailing lists.) This is a classic "everyone else wants vs techie wants" argument. I vastly prefer the techie approaches, as a rule of thumb. I personally think that the techie desires should win for a while. Of course, many other people (most, probably) disagree. > > And like mailing lists, Discourse also supports private messages. Unfortunately, these private messages are tied to the discourse system, which, for all we know, might die. Email is a known medium with (somewhat) portable archiving - both on the archive server and on the personal computer(s). > > I don't understand why Paul mentioned GPG. You want to encrypt messages > to a public mailing list? You can sign messages, but surely almost no > one actually checks the signature, and I'd be surprised if Discourse > didn't offer some built-in evidence of identity (surely it's not like > email in letting you spoof the sender name easily?). > Again, this ties the communications into a third party system. Why *not* let GPG sigs provide authentication? > I heard discourse supports attachments, just that you may have to go to > the forum to attach or download them (rather than by email). > More grief I really don't want to deal with - figuring out how to attach stuff in yet another interface. I am very happy with my Mozilla Thunderbird! Then the rust team have to consider how to store the attachments, manage the discourse server, etc... Me, I'd rather see the Mozilla team focus on Rust rather than server admin work. > > Just for discussion - example Discourse site: http://try.discourse.org/ I have generally been happy with Discourse search, overall - I don't have any complaints with it. Further problems with discourse in my experience: Infinite scroll doesn't let you jump to page n of the board. I really like being able to do that on mailing lists. I've used it to browse archives from a decade ago by date n stuff. Perhaps I'm not expert at the UI however. Space inefficiency in heading sizes (maybe just out of the box, dunno). User list avatar images on the posts scales sideways - not a good thing when lots of people are contributing. The discourse UI is very web 2.0 & 2010s-ish. That makes it visually more attractive; but I still favor my email client Thunderbird & mailing lists because they work & are the standard open source interface for long-form discussion, without the downsides of web sites. I have search, authentication (via gpg), threaded archives, separation of email. I appreciate that in the long term, when the goal is wide adoption, the humble open source mailing list so beloved by the techies will not be the optimal approach to draw all people in. But I think I will stick with the mailing lists even then. -- Regards, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 946 bytes Desc: OpenPGP digital signature URL: From ml at isaac.cedarswampstudios.org Tue Dec 3 23:28:36 2013 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Wed, 04 Dec 2013 02:28:36 -0500 Subject: [rust-dev] Persistent data structures Message-ID: <529ED9A4.4080901@isaac.cedarswampstudios.org> I'm interested in having persistent data structures[1] in Rust. To start, I implemented the simplest one, the cons/nil list (it looks like extra::list::List has another implementation of it). Am I using Rust conventions properly? My persistent list code: https://github.com/idupree/rust-code/blob/master/persistent.rs My next goal is a persistent tree-map, probably cribbing from Haskell's Data.Map. Is Rc the best smart pointer for persistent data structures? Is it possible for the structure to be parametrized on smart pointer? Rc requires the contained data to be Freeze or Send or risk reference cycles. Gc requires T:'static (which means no borrowed pointers besides &'static ones within the type). Every Send type is 'static, but not every Freeze type is 'static, so neither Rc nor Gc is strictly more flexible. Arc is Send, unlike either Rc or Gc, but has more overhead and can only contain Freeze+Send data; someone wanting to share persistence between tasks (conceivably for the sake of memory-use or asymptotic time) would want it. Is it possible to implement FromIterator for List without using O(n) temporary space or "unsafe" code? The problem is that the list comes out reversed in an obvious implementation. (O(n) stack space via recursion, or an O(n) intermediate data structure, or unsafely constructing a cons cell before constructing its tail.) [1] https://en.wikipedia.org/wiki/Persistent_data_structure , like every data structure in Haskell -Isaac From bascule at gmail.com Tue Dec 3 23:30:36 2013 From: bascule at gmail.com (Tony Arcieri) Date: Tue, 3 Dec 2013 23:30:36 -0800 Subject: [rust-dev] Persistent data structures In-Reply-To: <529ED9A4.4080901@isaac.cedarswampstudios.org> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> Message-ID: On Tue, Dec 3, 2013 at 11:28 PM, Isaac Dupree < ml at isaac.cedarswampstudios.org> wrote: > I'm interested in having persistent data structures[1] in Rust. Nice! -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Dec 4 00:23:35 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 04 Dec 2013 00:23:35 -0800 Subject: [rust-dev] Persistent data structures In-Reply-To: <529ED9A4.4080901@isaac.cedarswampstudios.org> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> Message-ID: <529EE687.2060004@mozilla.com> On 12/3/13 11:28 PM, Isaac Dupree wrote: > Is Rc the best smart pointer for persistent data structures? I would think so, for non-thread safe ones. > Is it > possible for the structure to be parametrized on smart pointer? Not without higher kinded types (which eventually we do want--so the answer is "not yet"). > Rc requires the contained data to be Freeze or Send or risk reference > cycles. I want to lift this restriction, BTW. Trying to prevent cycles through the type system has never really worked for us. Gc requires T:'static (which means no borrowed pointers besides > &'static ones within the type). Yes, but I wouldn't worry about this restriction biting users of your structure too much. Rust data structures rarely ever store non-static references in them, as the stack discipline that references must follow is fairly limited. (I can probably count the number of times I've put a non-static `&` reference into a dynamic vector on one hand, and I don't think I've ever put references into a hash map.) Every Send type is 'static, but not > every Freeze type is 'static, so neither Rc nor Gc is strictly more > flexible. Arc is Send, unlike either Rc or Gc, but has more overhead > and can only contain Freeze+Send data; someone wanting to share > persistence between tasks (conceivably for the sake of memory-use or > asymptotic time) would want it. Really what you want here for maximum flexibility is higher-kinded types and an implementation parameterized over Rc or Arc. That doesn't work in today's Rust, so you'll have to implement the data structure separately for non-thread-safe and thread-safe applications, unless you use macros. (Though often times you may want separate logic either way, necessitating a separate implementation. I'm not sure about the particular data structure you had in mind though.) > Is it possible to implement FromIterator for List without using > O(n) temporary space or "unsafe" code? The problem is that the list > comes out reversed in an obvious implementation. (O(n) stack space via > recursion, or an O(n) intermediate data structure, or unsafely > constructing a cons cell before constructing its tail.) I think it should be possible to reverse the list after it's constructed, but then of course it has to be mutable (at least temporarily). Or you could carry around a pointer to the end of the list (which, again, requires mutation). I don't think this is solvable without mutation in a strict (non-lazy) language, unless I'm missing something. Patrick From remifontan at yahoo.fr Wed Dec 4 00:24:35 2013 From: remifontan at yahoo.fr (=?UTF-8?B?UsOpbWkgRm9udGFu?=) Date: Wed, 4 Dec 2013 21:24:35 +1300 Subject: [rust-dev] method overloading and generic In-Reply-To: References: Message-ID: thanks for explanation, it all makes sense now. so I will stick to manually implement the overloading for every float type until #8075 is fixed, which is fine for now. cheers, R?mi On Tue, Dec 3, 2013 at 11:50 PM, Eric Reed wrote: > I think you're running into issue #8075which has to do with generic impls conflicting with all the other impls > present. > The typechecker tries to ensure that impls are coherent, i.e. that impls > do not overlap (otherwise the compiler wouldn't know which one to use). > Unfortunately, the coherence check isn't very smart right now and if > there's a generic impl around then it assumes it could conflict with > everything (and consequently forbids any other impls). > > The specific problem here is that the coherence checker doesn't realize > that SomeData does not impl Float. Without knowing that, the checker sees > two possible impls for SomeData and rejects the code. > If you replace "impl SomeDataRhs for T" with "impl SomeDataRhs > for f64", then it'll work fine. You can add an impl for f32 as well (FYI > "float" is already removed in HEAD). > Unfortunately, I don't know of a good general solution that will support > all types implementing Float (i.e. what the generic impl is doing). > > > On Tue, Dec 3, 2013 at 1:09 AM, R?mi Fontan wrote: > >> Hi, >> >> I think I already asked this question in the past and I'm not very sure >> what was the answer and whether it is still applicable wirh rust 0.8. >> >> I'm implementing the double dispatch method overloading such that I can >> add 2 struct together and a float to a struct. >> >> let data = SomeData{a:1.0} + 2.0; >> let data2 = SomeData{a:100.0} + data; >> >> I would like to implement the add for every type of float. I asked >> whether I could write something like this: >> >> impl SomeDataRhs for T { >> fn add_to(&self, lhs:&SomeData) -> SomeData { >> SomeData{a:lhs.a + cast(*self)} >> } >> } >> >> it does not compile right now with rust 0.8 >> I get error messages as follow >> >> test2.rs:39:0: 43:1 error: conflicting implementations for trait >> `SomeDataRhs` >> >> test2.rs:39 impl SomeDataRhs for SomeData { >> >> test2.rs:40 fn add_to(&self, lhs:&SomeData) -> SomeData { >> >> test2.rs:41 SomeData{a:lhs.a + self.a} >> >> test2.rs:42 } >> >> test2.rs:43 } >> >> test2.rs:33:0: 37:1 note: note conflicting implementation here >> >> test2.rs:33 impl SomeDataRhs for T { >> >> test2.rs:34 fn add_to(&self, lhs:&SomeData) -> SomeData { >> >> test2.rs:35 SomeData{a:lhs.a + cast(*self)} >> >> test2.rs:36 } >> >> Would you know whether what I try to do is possible. I was recommended to >> use macro for that, I don't mind to eventually go this way but I would >> rather do it the proper way if there is one. >> >> here's the full code of my test: >> extern mod std; >> use std::num::cast; >> >> >> struct SomeData { a:float } >> >> trait SomeDataRhs { >> fn add_to(&self, lhs:&SomeData) -> SomeData; >> } >> >> impl Add for SomeData { >> >> fn add(&self, rhs:&T) -> SomeData { >> rhs.add_to(self) >> } >> } >> >> // --------------- >> // implementations >> >> // impl SomeDataRhs for float { >> // fn add_to(&self, lhs:&SomeData) -> SomeData { >> // SomeData{a:lhs.a + *self} >> // } >> // } >> >> // impl SomeDataRhs for f64 { >> // fn add_to(&self, lhs:&SomeData) -> SomeData { >> // SomeData{a:lhs.a + cast(*self)} >> // } >> // } >> >> impl SomeDataRhs for T { >> fn add_to(&self, lhs:&SomeData) -> SomeData { >> SomeData{a:lhs.a + cast(*self)} >> } >> } >> >> impl SomeDataRhs for SomeData { >> fn add_to(&self, lhs:&SomeData) -> SomeData { >> SomeData{a:lhs.a + self.a} >> } >> } >> >> >> #[test] >> fn test_sandbox() { >> >> let mut data = SomeData{a:1.0} + 2.0; >> println!("result: {}", data.a); >> >> let mut data2 = SomeData{a:100.0} + data; >> data = data + data2; >> println!("result: {}", data.a); >> >> } >> >> >> >> cheers, >> >> R?mi >> >> >> -- >> R?mi Fontan : remifontan at yahoo.fr >> mobile: +64 21 855 351 >> 93 Otaki Street, Miramar 6022 >> Wellington, New Zealand >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- R?mi Fontan : remifontan at yahoo.fr mobile: +64 21 855 351 93 Otaki Street, Miramar 6022 Wellington, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.boggiano at seld.be Wed Dec 4 00:36:42 2013 From: j.boggiano at seld.be (Jordi Boggiano) Date: Wed, 4 Dec 2013 09:36:42 +0100 Subject: [rust-dev] Practical usage of rustpkg In-Reply-To: <529E34A5.2070700@aim.com> References: <529E34A5.2070700@aim.com> Message-ID: On Tue, Dec 3, 2013 at 8:44 PM, SiegeLord wrote: > I don't think any of these options are ideal. I don't want to suggest > solutions to these issues because I'm not sure how things are supposed to be > used/what the planned design is. Does anybody use rustpkg seriously today? > Is everybody making workspaces with a github.com/ directory where they > develop their software? I usually (i.e. in other languages I work with) develop dependencies "in-line" as they were cloned by the package manager, at least if they need deep integration with the surrounding project and can not be easily tested/developed in isolation. It's not such a horrible situation as long as the package manager is smart enough to avoid wiping your stuff on its own. That said, a pretty good option I think is to have a command like npm link [1] that would allow you to tell rustpkg to set up a symlink to another dir on the disk, yet without interfering/polluting the project's source itself. [1] https://npmjs.org/doc/cli/npm-link.html Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi From kevin at sb.org Wed Dec 4 00:42:32 2013 From: kevin at sb.org (Kevin Ballard) Date: Wed, 4 Dec 2013 00:42:32 -0800 Subject: [rust-dev] Persistent data structures In-Reply-To: <529EE687.2060004@mozilla.com> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> <529EE687.2060004@mozilla.com> Message-ID: <3B21214F-C07F-4A63-AB8F-0CEEA31305DB@sb.org> On Dec 4, 2013, at 12:23 AM, Patrick Walton wrote: > Yes, but I wouldn't worry about this restriction biting users of your structure too much. Rust data structures rarely ever store non-static references in them, as the stack discipline that references must follow is fairly limited. (I can probably count the number of times I've put a non-static `&` reference into a dynamic vector on one hand, and I don't think I've ever put references into a hash map.) I've put non-static &[u8]s into a map. Specifically, I have a function in one of my sources that looks vaguely like pub fn process_input<'a>(input: &'a [u8]) -> int { let mut map: HashMap<&'a [u8], int> = HashMap::new(); // .. process the input using the map, then throw away the map return result; } -Kevin From philippe.delrieu at free.fr Wed Dec 4 01:21:27 2013 From: philippe.delrieu at free.fr (Philippe Delrieu) Date: Wed, 04 Dec 2013 10:21:27 +0100 Subject: [rust-dev] Problem to use Encodable as fn parameter In-Reply-To: <529B71D4.9000603@free.fr> References: <52972F3D.6010901@free.fr> <52984FE1.80505@free.fr> <529880BA.2090006@free.fr> <52988F48.6010407@free.fr> <5298916A.8040105@gmail.com> <529B71D4.9000603@free.fr> Message-ID: <529EF417.3040103@free.fr> I reply to my questions. It can be helpful to somebody. First the error: wrong number of lifetime parameters The struct encoder is declared pub struct Encoder<'self> so the <'self> lifetime is part of the type and must be keep. The good declaration is pub fn buffer_encode>>(to_encode_object: &T) -> ~[u8] The call to the function is : Encoder::buffer_encode(&to_encode_object) For the other questions. The lifetime has been added to init (pub fn init<'a>(wr: &'a mut io::Writer) -> Encoder<'a>) because the borrowed specified parameter (wr) is returning in the Encoder and must be keep borrower after the call and during all the Encoder use. Fn Init borrow the wr and give it to the Encoder. After the 'init' call, returned Encoder is use to encode object and wr must still be borrowed. The call to init and encode are put inside a scoped block to manage the Encoder lifetime: ex: let mut m = MemWriter::new(); { let mut encoder = Encoder::init(&mut m as &mut Writer); to_encode_object.encode(&mut encoder); } m.inner() Why the type is declared with a <'self> lifetime (pub struct Encoder<'self>). It's not so clear. What I think, It's because the struct contains an attribute (priv wr: &'self mut io::Writer) that have a variable lifetime (depend on the use) , so to be configurable the lifetime must be declared as a generic in the struct. The variable lifetime is needed because, it allow the Encoder to borrow the writer during a lifetime longer that the function call (lifetime of normal borrowing) needed in the init function. For more informations: http://static.rust-lang.org/doc/master/tutorial-borrowed-ptr.html : to understand borrowing mechanism https://www.mail-archive.com/rust-dev at mozilla.org/msg05811.html : for the <'self> Hope my explication is clear. I have remark about the list and the thread 'Rust Forum', I think it become important to have a user mailing list or forum. It's the second time I answer to my trivial questions and I fell that I'm annoying everybody with these. Philippe Delrieu Le 01/12/2013 18:28, Philippe Delrieu a ?crit : > I see the PR has been approved to I try to implements the method 'pub > fn buffer_encode>(to_encode_object: &T) -> ~[u8]' > and I have this error : "error: wrong number of lifetime parameters: > expected 1 but found 0" and indicate the Encoder type. > > I have another question. I try to understand the modification on > json.rs and function declaration has changed from : > impl serialize::Encoder for Encoder > to: > impl<'self> serialize::Encoder for Encoder<'self> > or > pub fn init<'a>(wr: &'a mut io::Writer) -> Encoder<'a> > instead of > pub fn new(wr: &mut io::Writer) -> Encoder > > Could you explain me the difference if you don't mind. > > Philippe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Wed Dec 4 01:22:37 2013 From: gaetan at xeberon.net (Gaetan) Date: Wed, 4 Dec 2013 10:22:37 +0100 Subject: [rust-dev] Practical usage of rustpkg In-Reply-To: References: <529E34A5.2070700@aim.com> Message-ID: dependencies management is really a not so trivial solution... There are several solution: - javaish : use reverse url notation like: org.server.organisation.product.libraryname. If we expect not to use the URL from another company, conflict should be avoided most of the time. But while this is good for compagny, this is not really usable for personal development. org.compagnie doesn't change often, while you may want to switch from github to another server, breaking this rule. Given that, you simple push your artifact inside a repository manager (like artifactory), and simply request the package name and version, it will easily find out which one to use and install it in your development environement. - central repository: much simpler, just the name of the library should be unique. pip use this and it's much easier to use (just push the tarball and that's all, pip will see and install it when needed). I don't know if there are plan to do something about rustpkg, but I think dependencies management is something really important to have to ease the wide adoption of rust. I like the python way, simple is better. Just the name of the package should be unique, and the package should be validated. I would imagine something like: defining in mod.rs the depencendies import directives with something like "#[import mylibrary]" which would direct rust pbk to try importing the library "mylibrary" from a know local path (if you develop both library and the application that use it) or from a central repository (www.rust-lang.com/pkg/ ?), download it and install it inside the directory structure (eventually not versionnned, to avoid copying it), and configuring the proper "use pkg::mylibrary" to work directly, for example. Of course for local development, copying it would not be necessary. I also think that proposing a random URL to be set (for instance to specify the URL of a personal Github project) would also allow the use of package that is not entered yet inside the managed central repository. But this doesn't cover dependencies between packages and versionning... G. ----- Gaetan 2013/12/4 Jordi Boggiano > On Tue, Dec 3, 2013 at 8:44 PM, SiegeLord wrote: > > I don't think any of these options are ideal. I don't want to suggest > > solutions to these issues because I'm not sure how things are supposed > to be > > used/what the planned design is. Does anybody use rustpkg seriously > today? > > Is everybody making workspaces with a github.com/ directory where > they > > develop their software? > > I usually (i.e. in other languages I work with) develop dependencies > "in-line" as they were cloned by the package manager, at least if they > need deep integration with the surrounding project and can not be > easily tested/developed in isolation. It's not such a horrible > situation as long as the package manager is smart enough to avoid > wiping your stuff on its own. > > That said, a pretty good option I think is to have a command like npm > link [1] that would allow you to tell rustpkg to set up a symlink to > another dir on the disk, yet without interfering/polluting the > project's source itself. > > [1] https://npmjs.org/doc/cli/npm-link.html > > Cheers > > -- > Jordi Boggiano > @seldaek - http://nelm.io/jordi > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Wed Dec 4 01:25:32 2013 From: gaetan at xeberon.net (Gaetan) Date: Wed, 4 Dec 2013 10:25:32 +0100 Subject: [rust-dev] Problem to use Encodable as fn parameter In-Reply-To: <529EF417.3040103@free.fr> References: <52972F3D.6010901@free.fr> <52984FE1.80505@free.fr> <529880BA.2090006@free.fr> <52988F48.6010407@free.fr> <5298916A.8040105@gmail.com> <529B71D4.9000603@free.fr> <529EF417.3040103@free.fr> Message-ID: is it possible to have the <'self> explained inside the tutorial? ----- Gaetan 2013/12/4 Philippe Delrieu > I reply to my questions. It can be helpful to somebody. > First the error: wrong number of lifetime parameters > The struct encoder is declared pub struct Encoder<'self> so the <'self> > lifetime is part of the type and must be keep. > The good declaration is pub fn > buffer_encode>>(to_encode_object: &T) -> ~[u8] > > The call to the function is : Encoder::buffer_encode(&to_encode_object) > > For the other questions. > The lifetime has been added to init (pub fn init<'a>(wr: &'a mut > io::Writer) -> Encoder<'a>) because the borrowed specified parameter (wr) > is returning in the Encoder and must be keep borrower after the call and > during all the Encoder use. Fn Init borrow the wr and give it to the > Encoder. After the 'init' call, returned Encoder is use to encode object > and wr must still be borrowed. The call to init and encode are put inside a > scoped block to manage the Encoder lifetime: > ex: > > let mut m = MemWriter::new(); > { > let mut encoder = Encoder::init(&mut m as &mut Writer); > to_encode_object.encode(&mut encoder); > } > m.inner() > > Why the type is declared with a <'self> lifetime (pub struct > Encoder<'self>). It's not so clear. What I think, It's because the struct > contains an attribute (priv wr: &'self mut io::Writer) that have a variable > lifetime (depend on the use) , so to be configurable the lifetime must be > declared as a generic in the struct. The variable lifetime is needed > because, it allow the Encoder to borrow the writer during a lifetime longer > that the function call (lifetime of normal borrowing) needed in the init > function. > > For more informations: > http://static.rust-lang.org/doc/master/tutorial-borrowed-ptr.html : to > understand borrowing mechanism > https://www.mail-archive.com/rust-dev at mozilla.org/msg05811.html : for the > <'self> > > Hope my explication is clear. > > I have remark about the list and the thread 'Rust Forum', I think it > become important to have a user mailing list or forum. It's the second time > I answer to my trivial questions and I fell that I'm annoying everybody > with these. > > Philippe Delrieu > > > Le 01/12/2013 18:28, Philippe Delrieu a ?crit : > > I see the PR has been approved to I try to implements the method 'pub fn > buffer_encode>(to_encode_object: &T) -> ~[u8]' > and I have this error : "error: wrong number of lifetime parameters: > expected 1 but found 0" and indicate the Encoder type. > > I have another question. I try to understand the modification on json.rsand function declaration has changed from : > impl serialize::Encoder for Encoder > to: > impl<'self> serialize::Encoder for Encoder<'self> > or > pub fn init<'a>(wr: &'a mut io::Writer) -> Encoder<'a> > instead of > pub fn new(wr: &mut io::Writer) -> Encoder > > Could you explain me the difference if you don't mind. > > Philippe > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelwoerister at posteo.de Wed Dec 4 01:51:43 2013 From: michaelwoerister at posteo.de (Michael Woerister) Date: Wed, 04 Dec 2013 10:51:43 +0100 Subject: [rust-dev] Persistent data structures In-Reply-To: <529ED9A4.4080901@isaac.cedarswampstudios.org> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> Message-ID: <529EFB2F.5090506@posteo.de> I've implemented a persistent HAMT [1] a while back: https://github.com/michaelwoerister/rs-persistent-datastructures/blob/master/hamt.rs It's the data structure used for persistent maps in Clojure (and Scala, I think). It's not too hard to implement and it's pretty nifty. I'm not sure about the performance with atomic reference counting being used for memory management. It will definitely be worse than with a stop-the-world garbage collector. Although, it's noteworthy that look ups in the data structure only have to copy one `Arc` for returning the result, so the high fan-out of the data structure should not hurt if you mostly read from it. I'd be very interested in a performance comparison to other persistent map implementations in Rust (e.g. a red-black tree or splay tree). Here are some things I came across during implementing this: * I too discovered that I couldn't parametrize on the type of reference being used without higher kinded types. I did the implementation with regular @ pointers at first and later switched to `Arc`, since concurrent contexts are where persistent data structures really shine. Switching the implementation from @ to Arc was pretty straight forward. * I found there is no standardized trait for persistent maps in libstd or libextra. It would be nice to have one! * It's probably a very good idea to provide a non-persistent "builder" that avoids the excessive copying during the insertion phase. In Clojure one can switch between "transient" and persistent mode for a data structure instance which also allows for optimized batch modifications. An `insert_from(iterator)` method might also do the trick. There's quite a bit of design space here. * I would have liked to avoid some allocations and pointer chasing by using fixed size vectors directly within nodes but I could not get that to work without a lot of unsafe code that I was not sure would be correct in all cases. So I just used owned vectors in the end. Looking forward to seeing more in this area :) -Michael [1] https://en.wikipedia.org/wiki/Hash_array_mapped_trie On 04.12.2013 08:28, Isaac Dupree wrote: > I'm interested in having persistent data structures[1] in Rust. To > start, I implemented the simplest one, the cons/nil list (it looks > like extra::list::List has another implementation of it). Am I using > Rust conventions properly? > > My persistent list code: > https://github.com/idupree/rust-code/blob/master/persistent.rs > > My next goal is a persistent tree-map, probably cribbing from > Haskell's Data.Map. > > > Is Rc the best smart pointer for persistent data structures? Is it > possible for the structure to be parametrized on smart pointer? > > Rc requires the contained data to be Freeze or Send or risk reference > cycles. Gc requires T:'static (which means no borrowed pointers > besides &'static ones within the type). Every Send type is 'static, > but not every Freeze type is 'static, so neither Rc nor Gc is strictly > more flexible. Arc is Send, unlike either Rc or Gc, but has more > overhead and can only contain Freeze+Send data; someone wanting to > share persistence between tasks (conceivably for the sake of > memory-use or asymptotic time) would want it. > > > Is it possible to implement FromIterator for List without using > O(n) temporary space or "unsafe" code? The problem is that the list > comes out reversed in an obvious implementation. (O(n) stack space via > recursion, or an O(n) intermediate data structure, or unsafely > constructing a cons cell before constructing its tail.) > > > [1] https://en.wikipedia.org/wiki/Persistent_data_structure , like > every data structure in Haskell > > -Isaac > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From steve at steveklabnik.com Wed Dec 4 02:24:14 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 4 Dec 2013 11:24:14 +0100 Subject: [rust-dev] Ideas of small projects or improvements In-Reply-To: <529A3174.8060701@hyc.io> References: <529A3174.8060701@hyc.io> Message-ID: There is a tag on GitHub specifically for easy issues: https://github.com/mozilla/rust/issues?labels=E-easy&milestone=13&state=open From dbau.pp at gmail.com Wed Dec 4 02:33:56 2013 From: dbau.pp at gmail.com (Huon Wilson) Date: Wed, 04 Dec 2013 21:33:56 +1100 Subject: [rust-dev] Persistent data structures In-Reply-To: <529EFB2F.5090506@posteo.de> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> <529EFB2F.5090506@posteo.de> Message-ID: <529F0514.1050503@gmail.com> On 04/12/13 20:51, Michael Woerister wrote: > I've implemented a persistent HAMT [1] a while back: > https://github.com/michaelwoerister/rs-persistent-datastructures/blob/master/hamt.rs > > > It's the data structure used for persistent maps in Clojure (and > Scala, I think). It's not too hard to implement and it's pretty nifty. > I'm not sure about the performance with atomic reference counting > being used for memory management. It will definitely be worse than > with a stop-the-world garbage collector. Although, it's noteworthy > that look ups in the data structure only have to copy one `Arc` for > returning the result, so the high fan-out of the data structure should > not hurt if you mostly read from it. I'd be very interested in a > performance comparison to other persistent map implementations in Rust > (e.g. a red-black tree or splay tree). > > Here are some things I came across during implementing this: > * I too discovered that I couldn't parametrize on the type of > reference being used without higher kinded types. I did the > implementation with regular @ pointers at first and later switched to > `Arc`, since concurrent contexts are where persistent data structures > really shine. Switching the implementation from @ to Arc was pretty > straight forward. > * I found there is no standardized trait for persistent maps in libstd > or libextra. It would be nice to have one! > * It's probably a very good idea to provide a non-persistent "builder" > that avoids the excessive copying during the insertion phase. In > Clojure one can switch between "transient" and persistent mode for a > data structure instance which also allows for optimized batch > modifications. An `insert_from(iterator)` method might also do the > trick. There's quite a bit of design space here. For reference, the FromIterator & Extendable traits are the things to implement if one has a structure that can be constructed from/extended with an iterator and wishes to share the behaviour. http://static.rust-lang.org/doc/master/std/iter/trait.FromIterator.html http://static.rust-lang.org/doc/master/std/iter/trait.Extendable.html Huon > * I would have liked to avoid some allocations and pointer chasing by > using fixed size vectors directly within nodes but I could not get > that to work without a lot of unsafe code that I was not sure would be > correct in all cases. So I just used owned vectors in the end. > > Looking forward to seeing more in this area :) > > -Michael > > [1] https://en.wikipedia.org/wiki/Hash_array_mapped_trie From illissius at gmail.com Wed Dec 4 02:38:22 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Wed, 4 Dec 2013 11:38:22 +0100 Subject: [rust-dev] Distilled essence of placement new In-Reply-To: References: Message-ID: What's the current plan for the implementation of placement new as you envision it? In particular what would the trait used by Gc etc. to hook into it look like? How does it do the thing where expressions are constructed directly into place? I agree with many parts of your analysis (different argument evaluation orders implicitly would indeed be unfortunate), but I want to have a clearer picture of the other alternative before discussing it further. On Wed, Dec 4, 2013 at 5:57 AM, Patrick Walton wrote: > I should elaborate: I think you've successfully formulated placement new > in terms of unboxed closures as monomorphized traits whose "call" method > takes self by value. That is, something like (in Rust of the future): > > fn GC>(f: F) -> GC > > The difference, though, is that the construction of the closure is > implicit at the call site in this proposal. This is what I'm uncomfortable > with. Rust is a strict language, not a lazy one, and the order of > evaluation of function arguments is one of the things that one has > heretofore been unable to change. I would prefer that a different argument > evaluation order would necessitate some sort of annotation at the call site > (e.g. ocaml's "lazy"). But once you've done that you've essentially > recreated something equivalent to placement new, but more verbose since you > have to name a method when you allocate into an object (e.g. instead of > "box(my_arena) foo" you'd have to write "my_arena.alloc(lazy foo)". I think > we would end up wanting the sugar. > > Patrick > > "G?bor Lehel" wrote: >> >> Yes, that was one of the things that passed through my mind as well. One >> difference is that those are passed at runtime, whereas here everything >> happens at compile time. I remember LLVM had difficulty reliably optimizing >> runtime closure passing code, like with the old iterators. >> >> >> On Wed, Dec 4, 2013 at 5:05 AM, Daniel Micay wrote: >> >>> This looks a lot like what stack once functions would provide. >>> >> >> >> >> -- >> Your ship was destroyed in a monadic eruption. >> >> ------------------------------ >> >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelwoerister at posteo.de Wed Dec 4 03:18:47 2013 From: michaelwoerister at posteo.de (Michael Woerister) Date: Wed, 04 Dec 2013 12:18:47 +0100 Subject: [rust-dev] Persistent data structures In-Reply-To: <529F0514.1050503@gmail.com> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> <529EFB2F.5090506@posteo.de> <529F0514.1050503@gmail.com> Message-ID: <529F0F97.4050607@posteo.de> > For reference, the FromIterator & Extendable traits are the things to > implement if one has a structure that can be constructed from/extended > with an iterator and wishes to share the behaviour. > > > http://static.rust-lang.org/doc/master/std/iter/trait.FromIterator.html > http://static.rust-lang.org/doc/master/std/iter/trait.Extendable.html Thanks for pointing that out :) Implementing FromIterator should work out fine. Extendable would need a persistent version returning the newly created instance, something like: mod persistent { pub trait Extendable: FromIterator { fn extend >(&self, iterator: &mut T) -> Self; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Wed Dec 4 03:41:16 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Wed, 4 Dec 2013 12:41:16 +0100 Subject: [rust-dev] Type system thoughts In-Reply-To: <20131202181825.GG21938@Mr-Bennet> References: <20131202181825.GG21938@Mr-Bennet> Message-ID: On Mon, Dec 2, 2013 at 7:18 PM, Niko Matsakis wrote: > > OK, I read a bit more. I've been working on a blog post about "HKR" > (higher-kinded Rust) and you've been elaborating on some of the same > themes as I was thinking about (naturally enough). All makes sense. > ...which was part of the impetus for finally getting my thoughts down on "paper". :) > In the absence of an erased keyword, I think that higher-kinded traits > and objects are simply incompatible. The situation is not as simple as > you made it out, as the trait may itself have generic parameters of > higher-kind. Without having thought about very deeply about whether it's true (can you provide an example?), wouldn't this be more accurately phrased as: "(higher-kinded?) traits with higher-kinded generic parameters and objects are simply incompatible"? In other words, if the problem is with the higher-kinded generic parameters, then why not forbid objects only in that case, and support them in their absence? > > The other is the potential to abstract over traits. GHC does this with > the > > `ConstraintKinds` extension. (According to people who have implemented > > Haskell compilers, it's actually easier to implement it than not to![1] > > Which is pretty crazy.) > > I'm not sure this would be true for Rust, but perhaps. > I have no idea either - it's astonishing enough that it's true for Haskell. :) > > > There's two further issues that higher-kinded generics raise... > > This is as far as I got in this round. More later. :) > OK. :) (I also still have yet to find serious time for DST parts [2..4]...) > > > Niko > -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Wed Dec 4 04:14:22 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 4 Dec 2013 07:14:22 -0500 Subject: [rust-dev] Mentoring + E-easy In-Reply-To: References: Message-ID: <20131204121422.GC2409@Mr-Bennet> This is a great idea. Niko On Tue, Nov 26, 2013 at 03:58:58AM -0500, Corey Richardson wrote: > Hey fellow Rusties, > > We have a fair number of new contributors, and my devious mind wonders > how we can get more. My first thought was a new tag, E-mentored, where > someone can volunteer to mentor someone through an E-easy issue. It's > a very lightweight, non-formal process, and can hopefully give some > more guidance to people who come into #rust asking for a good issue to > get started with. > > This is intended for brand-new contributors, whereas I feel E-easy is > a teeny bit misused. > > I also propose that, when tagging an issue as E-easy, a comment > describing the nature of the fix and where (file + function ideal) one > would look to start the fix. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From denis.spir at gmail.com Wed Dec 4 05:31:06 2013 From: denis.spir at gmail.com (spir) Date: Wed, 04 Dec 2013 14:31:06 +0100 Subject: [rust-dev] Rust forum In-Reply-To: References: <0DA6C2F8-3190-4601-ADE5-848048564FED@sb.org> Message-ID: <529F2E9A.2000307@gmail.com> On 12/03/2013 11:01 PM, Martin DeMello wrote: > keeping up with email is a lot easier than pretty much everything else, > though. the solution to keeping old messages around is mirroring the > mailing list to a searchable archive, not moving to a forum en masse and > sacrificing ease-of-conversation for ease-of-recall. Agreed. Plus, with emails everyone can *also* filter / categorise / search according to their own preferred rules on their preferret email client. [I have always hated forums for such reasons, plus they force one to explore, search, navigate, online, without any control.] Denis From simon.sapin at exyr.org Wed Dec 4 06:01:38 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Wed, 04 Dec 2013 14:01:38 +0000 Subject: [rust-dev] Meeting-weekly-2013-12-03, str.from_utf8 Message-ID: <529F35C2.1060606@exyr.org> Hi, In response to: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-12-03#strfrom_utf8 Yes, error handling other than strict/fail requires allocation. I suggest taking the pull request for the special case of non-allocating strict UTF-8, and keeping error handling for a future, larger API that also handles other encodings (and incremental processing): https://github.com/mozilla/rust/pull/10701 https://github.com/mozilla/rust/wiki/Proposal-for-character-encoding-API [On invalid UTF-8 bytes] > brson: One has a condition that lets you replace a bad character I believe this is not implemented. The current not_utf8 condition lets you do the entire decoding yourself. > acrichto: We could truncate by default. I am very much opposed to this. Truncating silently loses data (potentially lots of it!) It should not be implemented, let alone be the default. > jack: In python, you have to specify how you want it transformed. > Truncate vs. replace with '?', etc. Maybe there should be an > alternate version that takes the transform. > pnkfelix: But doesn't work with slices... > jack: There's truncate, replace, and fail. Python does not have truncate. It has ignore (skip invalid byte sequences but continue with the rest of the input), strict (fail), and replace (with ? U+FFFD REPLACEMENT CHARACTER). You don?t have to specify an error handling, strict is the default. Ignore is bad IMO as it silently loses data (although it?s not as bad as truncate) though it could have uses I?m not thinking of right now. Side note: Regarding failing vs. returning an Option or Result: I?d be in favor of only having the latter. Having two versions of the same API (foo() and foo_opt()) is ugly, and it?s easy to get "value or fail" from an Option with .unwrap() -- Simon Sapin From thadguidry at gmail.com Wed Dec 4 06:58:47 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Wed, 4 Dec 2013 08:58:47 -0600 Subject: [rust-dev] How to search the mailing list archives In-Reply-To: References: Message-ID: Actually, you do not have to change the "article" to "thread"...instead, just CLICK on the Subject and you get the full thread discussion view. Thanks for the tip Benjamin ! (search at the bottom ? whatever. everyone is copying Firefox these days. :-) ) On Tue, Dec 3, 2013 at 9:11 PM, Benjamin Striegel wrote: > Apparently even Brian doesn't know how to do this, so I figured I'd share > this tip. > > The rust-dev mailing list is archived here: > > http://thread.gmane.org/gmane.comp.lang.rust.devel/ > > Use the search box at the bottom to search through the mailing list's > archives since the beginning of time. > > When you click on a result, you will end up on a page like this: > > http://article.gmane.org/gmane.comp.lang.rust.devel/6778/match=dst > > ...which is pretty terrible from a navigation standpoint. But in that URL > you can manually change the "article" bit on the front to "thread", to > yield this: > > http://thread.gmane.org/gmane.comp.lang.rust.devel/6778/match=dst > > ...which will let you easily browse a full conversation. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Wed Dec 4 08:18:50 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Wed, 4 Dec 2013 08:18:50 -0800 Subject: [rust-dev] Please welcome the Rust and Servo GNOME/OPW interns for December 2013-March 2014 Message-ID: Hello, I'm pleased to announce that the winter/spring Rust and Servo interns through the GNOME Outreach Program for Women ( https://wiki.gnome.org/OutreachProgramForWomen ) have been chosen. The program starts December 10 and runs until March 10. Nif Ward (IRC nick: nif) will be interning on Rust, working to develop a full-fledged B-tree library. Nif is a senior graduating this fall in computer science from Oberlin College in Ohio, USA. I will be her mentor. Isabelle Carter (IRC nick: ibnc) will be interning on Servo, working to add support for fixed positioning. Isabelle is on leave from her undergraduate degree in mathematics, and will be working from Springfield, Missouri, USA. Lars Bergstrom will be her mentor. We had many qualified applicants for Rust and Servo's first foray into OPW, so it's an honor to be chosen for this program. Please be friendly to nif and ibnc if you see them on #rust! Depending how this round of OPW goes, Rust and/or Servo may participate in a future iteration, so if you're interested in applying, then keep watching for more announcements. In addition, internships at Mozilla working on Rust and Servo (look for the "Research Engineering" listing; paid, on-site in the Bay Area) are open to all graduate students (undergraduate students with research experience have been considered in the past): http://careers.mozilla.org/ . Thanks are due to the Rust and Servo teams -- particularly Lars Bergstrom, Brian Anderson, and Jack Moffitt -- for helping many people apply for the program, and to the Mozilla coordinator for OPW, Larissa Shapiro, for their efforts. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "If you are silent about your pain, they'll kill you and say you enjoyed it." -- Zora Neale Hurston From catamorphism at gmail.com Wed Dec 4 08:37:14 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Wed, 4 Dec 2013 08:37:14 -0800 Subject: [rust-dev] Practical usage of rustpkg In-Reply-To: <529E34A5.2070700@aim.com> References: <529E34A5.2070700@aim.com> Message-ID: FYI, there's a related bug open: https://github.com/mozilla/rust/issues/8673 (this is about the problem of repeating the same package ID#revision string in different files and not having a way to abstract it out) The preferred way to work on a dependency and the package that depends on it at the same time is to make a local copy and put it in your RUST_PATH; this copy will be found before rustpkg looks for the upstream copy and/or for an automatically-cached copy of that. The local copy has to have the same package ID, of course, so for a package like github.com/foo/bar, you would have to have a github.com/foo/bar directory in your RUST_PATH. Hope that helps! Cheers, Tim On Tue, Dec 3, 2013 at 11:44 AM, SiegeLord wrote: > So I've been thinking for awhile about how one would actually use rustpkg. > Let me first outline my use case. I have a library and a program that uses > that library, both of which I host on GitHub. One of the features of the > rustpkg system is that I should be able to write this to refer to the > library in my program: > > extern mod lib = "package_id"; > > Unfortunately, there is no obvious thing to put into the 'package_id' slot. > There are two options: > > First, I could use "github.com/SiegeLord/library" as my package_id. This is > problematic, as it would require one of these sub-optimal courses of action: > > - Stick the source of the library into workspace/src/library where I would > actually develop and then use a duplicate package in the > workspace/src/github.com/SiegeLord/library that would be created by rustpkg > (the program is located in workspace/src/program). Somehow this duplicate > package will be synced to the actual package: either through pushing to > GitHub and then pulling somehow via rustpkg (this is less than ideal, as I > may want to test WIP changes without committing them elsewhere/I may have no > internet connection e.g. when traveling), or some manual, local git > operation. > > - Stick the source of the library into > workspace/src/github.com/SiegeLord/library and develop the library there. > There is no duplication, but it really seems bizarre to me to locate a > project in a directory named like that. Also, I'd be a bit paranoid about > rustpkg not realizing that I never want to communicate with GitHub and > having it accidentally overwriting my local changes. > > The second option is to use "library" as the package id. This allows me to > locate my library in a logical location (workspace/src/library), but it > prevents other users of my program from building it automatically. > Essentially what they'll have to do is to manually check out the library > repository inside their workspaces so as to create the workspace/src/library > directory on their system: the `extern mod` syntax will not work otherwise. > > I don't think any of these options are ideal. I don't want to suggest > solutions to these issues because I'm not sure how things are supposed to be > used/what the planned design is. Does anybody use rustpkg seriously today? > Is everybody making workspaces with a github.com/ directory where they > develop their software? > > -SL > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "If you are silent about your pain, they'll kill you and say you enjoyed it." -- Zora Neale Hurston From niko at alum.mit.edu Wed Dec 4 09:01:21 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 4 Dec 2013 12:01:21 -0500 Subject: [rust-dev] Persistent data structures In-Reply-To: <529EE687.2060004@mozilla.com> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> <529EE687.2060004@mozilla.com> Message-ID: <20131204170121.GD2409@Mr-Bennet> On Wed, Dec 04, 2013 at 12:23:35AM -0800, Patrick Walton wrote: > Not without higher kinded types (which eventually we do want--so the > answer is "not yet"). This. That said, I imagine that if we do it right, it'll be possible to write one persistent map implementation that can be used with GC, ARC, and also an arena. The latter would -- at least in principle -- make it possible to store references. I haven't thought hard about this though and it may be that complications arise. Niko From michaelwoerister at posteo.de Wed Dec 4 11:09:56 2013 From: michaelwoerister at posteo.de (Michael Woerister) Date: Wed, 04 Dec 2013 20:09:56 +0100 Subject: [rust-dev] Persistent data structures In-Reply-To: <529EE687.2060004@mozilla.com> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> <529EE687.2060004@mozilla.com> Message-ID: <529F7E04.3000809@posteo.de> >> Is it >> possible for the structure to be parametrized on smart pointer? > > Not without higher kinded types (which eventually we do want--so the > answer is "not yet"). I've been thinking about that a bit more and I think it might be possible to support different reference types without higher-kinded types. We can define a `Reference` trait that is then implemented for `Rc`, `Arc` and what have you. Something like: trait Reference : Clone { fn borrow<'a>(&'a self) -> &'a T; } If we also want to create references without knowing their concrete type, we also need a trait for creating them: trait ReferenceFactory> { fn create_reference(&self, val: T) -> TRef; } And then we can define a container type, using the generic reference type: struct Container { items: ~[TRef], reference_factory: TRefFactory } It contains a `ReferenceFactory` value that is used to create `Reference` instances when the container needs one (see the `add` method below): impl< T, TRef: Reference, TRefFactory: ReferenceFactory > Container { pub fn create(factory: TRefFactory) -> Container { Container { reference_factory: factory, items: ~[] } } pub fn add(&mut self, val: T) { self.items.push(self.reference_factory.create_reference(val)); } } This setup is a bit roundabout but it should get the job done. Of course, I may have overlooked something but at least rustc swallows the above code without complaint ;) If we could call static methods on type parameters, the factory functionality could be moved to the `Reference` trait: trait Reference : Clone { fn borrow<'a>(&'a self) -> &'a T; fn new(value: T) -> Self; } // Now using the static `new` method instead of the `ReferenceFactory` trait pub fn add(&mut self, val: T) { self.items.push(TRef::new(val)); } With this, the code would actually be of acceptable complexity in my eyes. -Michael From banderson at mozilla.com Wed Dec 4 11:10:03 2013 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 04 Dec 2013 11:10:03 -0800 Subject: [rust-dev] Meeting-weekly-2013-12-03, str.from_utf8 In-Reply-To: <529F35C2.1060606@exyr.org> References: <529F35C2.1060606@exyr.org> Message-ID: <529F7E0B.1090104@mozilla.com> On 12/04/2013 06:01 AM, Simon Sapin wrote: > Hi, > > In response to: > https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-12-03#strfrom_utf8 > > > Yes, error handling other than strict/fail requires allocation. I > suggest taking the pull request for the special case of non-allocating > strict UTF-8, and keeping error handling for a future, larger API that > also handles other encodings (and incremental processing): OK. > > https://github.com/mozilla/rust/pull/10701 > https://github.com/mozilla/rust/wiki/Proposal-for-character-encoding-API > > > [On invalid UTF-8 bytes] >> brson: One has a condition that lets you replace a bad character > > I believe this is not implemented. The current not_utf8 condition lets > you do the entire decoding yourself. You're right! I guess I was forshadowing. > >> acrichto: We could truncate by default. > > I am very much opposed to this. Truncating silently loses data > (potentially lots of it!) It should not be implemented, let alone be > the default. I agree. > >> jack: In python, you have to specify how you want it transformed. >> Truncate vs. replace with '?', etc. Maybe there should be an >> alternate version that takes the transform. >> pnkfelix: But doesn't work with slices... >> jack: There's truncate, replace, and fail. > > Python does not have truncate. It has ignore (skip invalid byte > sequences but continue with the rest of the input), strict (fail), and > replace (with ? U+FFFD REPLACEMENT CHARACTER). You don?t have to > specify an error handling, strict is the default. > > Ignore is bad IMO as it silently loses data (although it?s not as bad > as truncate) though it could have uses I?m not thinking of right now. > > > Side note: > > Regarding failing vs. returning an Option or Result: I?d be in favor > of only having the latter. Having two versions of the same API (foo() > and foo_opt()) is ugly, and it?s easy to get "value or fail" from an > Option with .unwrap() > Thanks for your always valuable feedback, Simon! From matthias at urlichs.de Wed Dec 4 00:04:45 2013 From: matthias at urlichs.de (Matthias Urlichs) Date: Wed, 4 Dec 2013 08:04:45 +0000 (UTC) Subject: [rust-dev] Rust front-end to GCC References: Message-ID: Hi, > > fn fib1 (n:int) -> int { > ? ? if (n <= 1) { 1 } > ? ? else { n * fib1 (n - 1) } > } Wrong function name. That's "fac". ;-) "fib" is ... ? ? else { fib1 (n - 1) + fib1 (n - 2) } -- Matthias Urlichs From banderson at mozilla.com Wed Dec 4 11:16:11 2013 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 04 Dec 2013 11:16:11 -0800 Subject: [rust-dev] Rust front-end to GCC In-Reply-To: References: Message-ID: <529F7F7B.2020301@mozilla.com> On 12/03/2013 09:22 AM, Philip Herron wrote: > Hey all > > Some of you may have noticed the gccrs branch on the git mirror. Since > PyCon IE 2013 i gave a talk on my Python Front-end pet project and > heard about rust by a few people and i never really looked at it > before until then but i've kind of been hooked since. > > So to learn the language i've been writing this front-end to GCC. Only > really a a month or so on and off work in between work. Currently it > compiles alot of rust already in fairly little effort on my side GCC > is doing loads of the heavy lifting. > > Currently it compiles most of the basic stuff such as a struct an impl > block while loop, functions expressions calling methods passing > arguments etc. Currently focusing on getting the typing working > correctly to support & and ~ and look at how templates might work as > well as need to implement break and return. > > There is still a lot of work but i would really like to share it and > see what people think. Personally i think rust will target GCC very > well and be a good addition (if / when it works). I really want to try > and give back to this community who have been very good to me in > learning over the last few years with GSOC. > This is very exciting work. I'm looking forward to following your progress. From banderson at mozilla.com Wed Dec 4 11:43:10 2013 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 04 Dec 2013 11:43:10 -0800 Subject: [rust-dev] Please welcome the Rust and Servo GNOME/OPW interns for December 2013-March 2014 In-Reply-To: References: Message-ID: <529F85CE.1070805@mozilla.com> Welcome aboard, Nif and Isabelle. I'm looking forward to working with you. And thanks for setting this up, Tim and Lars. On 12/04/2013 08:18 AM, Tim Chevalier wrote: > Hello, > > I'm pleased to announce that the winter/spring Rust and Servo interns > through the GNOME Outreach Program for Women ( > https://wiki.gnome.org/OutreachProgramForWomen ) have been chosen. The > program starts December 10 and runs until March 10. > > Nif Ward (IRC nick: nif) will be interning on Rust, working to develop > a full-fledged B-tree library. Nif is a senior graduating this fall in > computer science from Oberlin College in Ohio, USA. I will be her > mentor. > > Isabelle Carter (IRC nick: ibnc) will be interning on Servo, working > to add support for fixed positioning. Isabelle is on leave from her > undergraduate degree in mathematics, and will be working from > Springfield, Missouri, USA. Lars Bergstrom will be her mentor. > > We had many qualified applicants for Rust and Servo's first foray into > OPW, so it's an honor to be chosen for this program. Please be > friendly to nif and ibnc if you see them on #rust! > > Depending how this round of OPW goes, Rust and/or Servo may > participate in a future iteration, so if you're interested in > applying, then keep watching for more announcements. In addition, > internships at Mozilla working on Rust and Servo (look for the > "Research Engineering" listing; paid, on-site in the Bay Area) are > open to all graduate students (undergraduate students with research > experience have been considered in the past): > http://careers.mozilla.org/ . > > Thanks are due to the Rust and Servo teams -- particularly Lars > Bergstrom, Brian Anderson, and Jack Moffitt -- for helping many people > apply for the program, and to the Mozilla coordinator for OPW, Larissa > Shapiro, for their efforts. > > Cheers, > Tim > From michael.letterle+rust at gmail.com Wed Dec 4 11:50:07 2013 From: michael.letterle+rust at gmail.com (Michael Letterle) Date: Wed, 4 Dec 2013 14:50:07 -0500 Subject: [rust-dev] Please welcome the Rust and Servo GNOME/OPW interns for December 2013-March 2014 In-Reply-To: <529F85CE.1070805@mozilla.com> References: <529F85CE.1070805@mozilla.com> Message-ID: So much awesome! On Wed, Dec 4, 2013 at 2:43 PM, Brian Anderson wrote: > Welcome aboard, Nif and Isabelle. I'm looking forward to working with you. > And thanks for setting this up, Tim and Lars. > > > On 12/04/2013 08:18 AM, Tim Chevalier wrote: > >> Hello, >> >> I'm pleased to announce that the winter/spring Rust and Servo interns >> through the GNOME Outreach Program for Women ( >> https://wiki.gnome.org/OutreachProgramForWomen ) have been chosen. The >> program starts December 10 and runs until March 10. >> >> Nif Ward (IRC nick: nif) will be interning on Rust, working to develop >> a full-fledged B-tree library. Nif is a senior graduating this fall in >> computer science from Oberlin College in Ohio, USA. I will be her >> mentor. >> >> Isabelle Carter (IRC nick: ibnc) will be interning on Servo, working >> to add support for fixed positioning. Isabelle is on leave from her >> undergraduate degree in mathematics, and will be working from >> Springfield, Missouri, USA. Lars Bergstrom will be her mentor. >> >> We had many qualified applicants for Rust and Servo's first foray into >> OPW, so it's an honor to be chosen for this program. Please be >> friendly to nif and ibnc if you see them on #rust! >> >> Depending how this round of OPW goes, Rust and/or Servo may >> participate in a future iteration, so if you're interested in >> applying, then keep watching for more announcements. In addition, >> internships at Mozilla working on Rust and Servo (look for the >> "Research Engineering" listing; paid, on-site in the Bay Area) are >> open to all graduate students (undergraduate students with research >> experience have been considered in the past): >> http://careers.mozilla.org/ . >> >> Thanks are due to the Rust and Servo teams -- particularly Lars >> Bergstrom, Brian Anderson, and Jack Moffitt -- for helping many people >> apply for the program, and to the Mozilla coordinator for OPW, Larissa >> Shapiro, for their efforts. >> >> Cheers, >> Tim >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Wed Dec 4 11:54:26 2013 From: catamorphism at gmail.com (Tim Chevalier) Date: Wed, 4 Dec 2013 11:54:26 -0800 Subject: [rust-dev] Separated/Incremential compilation In-Reply-To: <5298CA4A.7000106@mozilla.com> References: <5298CA4A.7000106@mozilla.com> Message-ID: On Fri, Nov 29, 2013 at 9:09 AM, Patrick Walton wrote: > I shouldn't say that Rust has no problems with build times--it could always > be faster, and in particular the memory representations are inefficient, > particularly around ASTs--but when you actually run with `-Z time-passes`, > you'll see that the vast majority of the time for any reasonably-sized crate > is spent in LLVM. There isn't much we can do to make that faster by an order > of magnitude, other than to try to push on the parallel per-function > optimization and codegen work that is happening in some upstream branches. > Mergefunc, disabling exceptions, and the no-zeroing-out stuff that Niko is > doing would be nice, but they won't improve build times by an order of > magnitude. What about caching LLVM bitcode for individual Rust functions / items (using workcache, for example) and only recompiling those items whose dependencies have changed? Obviously this would be a lot of design and implementation work, and one would want to do the math to make sure it's likely to improve build performance, but offhand I can't see why it's not feasible. The scenario I'm thinking of is "add a debug! statement to one function, and only recompile the code for that function since its interface hasn't changed". In that case, only regenerating code for the changed function and not the entire crate should make a big difference. Cheers, Tim > > Patrick > > [1]: > https://groups.google.com/forum/#!topic/mozilla.dev.platform/WjcCfckml4A > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt "If you are silent about your pain, they'll kill you and say you enjoyed it." -- Zora Neale Hurston From banderson at mozilla.com Wed Dec 4 12:06:07 2013 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 04 Dec 2013 12:06:07 -0800 Subject: [rust-dev] Separated/Incremential compilation In-Reply-To: References: Message-ID: <529F8B2F.9020404@mozilla.com> On 11/29/2013 03:01 AM, L?o Testard wrote: > > Hello, > > I think everyone here will agree to say that compilation times in Rust > are problematic. Recently, there was an argument on IRC about reducing > compilation times by reducing the use of GC and failures. Although I > agree it's good to reduce Rustc's overhead, I think there are more > important problems. The total duration of a build matters only because > you have to recompile the whole crate on each modification. In C++, > the duration of the complete build of a project matters less because > when you compile incrementally, you only have to rebuild a couple of > files - those you modified. I know the "1 crate = 1 compilation unit" > is the model chosen by Rust, but this is a major issue for production. > Nobody will ever use Rust in production if they have to recompile > thousands of lines of code on each modification. > > On some of my personal projects, I "solved" this problem by splitting > the codebase into several crates, that I compile statically, and then > link together using extern mod. This is not really a solution, because > this implies that there is no cyclic dependency between each of the > small crates, or I end up with issues trying to compile it, because > using extern mod requires that the library corresponding to that mod > exists before compiling the crate that depends on it. > > But strictly speaking, a compiled crate is nothing more than a module > hierarchy, and so is a single Rust source file, so we should be able > to compile a single file to some sort of .o and then link all together > to form a crate. References to modules outside of this file just > require the first passes of the build, not the code generation, so it > should be ok regarding to cyclic dependencies, and if not, we could > still introduce some kind of auto-generated interface file, like Caml > does. I know it's quite a big work, and that the current system is > quite good, but having this is very important if we want Rust to be > used in production. > I agree that incremental recompilation would be a good thing to pursue, and I'd be happy to see someone work on it, but as you say it is a very difficult problem, and it's frankly a low priority. Some other compilition performance wins to pursue are removing metadata compression (causes dynamic linker crashes on linux), improving llvm perf, and improving linker perf. From banderson at mozilla.com Wed Dec 4 12:11:46 2013 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 04 Dec 2013 12:11:46 -0800 Subject: [rust-dev] Plz separate mail threads for separated compilation [was Re: Separated/Incremential compilation] In-Reply-To: <52989A9F.2000504@mozilla.com> References: <5298790B.3090709@gmail.com> <52989A9F.2000504@mozilla.com> Message-ID: <529F8C82.7050901@mozilla.com> Thanks Felix. I added this to https://github.com/mozilla/rust/issues/4047 On 11/29/2013 05:46 AM, Felix S. Klock II wrote: > First off, the topic of rustc slowness and long bootstrap times has > indeed been discussed many times. If you have not yet tried skimming > the archives, I recommend doing so, e.g. via > > http://lmgtfy.com/?q=+site%3Amail.mozilla.org+rust+crate+compilation+speed > > (I provide a (surely incomplete) list of previous-post links below.) > > ---- > > Now, a request: when discussing this topic, please try to avoid > conflating: > > 1. librustc+libstd bootstrap time, > > from the somewhat separate issues of > > 2. models for incremental compilation, and > > 3. compilation times when running rustc on projects other than > rustc itself. > > > In particular, incremental compilation alone is not going to solve > (1). (At least, not as long as one is using the default make rule > that rebuilds all of librustc+libstd atop the newly built rustc, and > rustc itself draws upon a (large) libstd. Under the latter two > constraints, you *have* to redo the build for all of librustc+libstd: > the compiler itself was changed. Incremental compilation does not > solve this.) > > I am concerned that we will waste time debating tasks/designs related > to (2) and then people will be disappointed when it does not provide > the gains that they were expecting for issues like (1). > > ---- > > In case its not clear from the comments above: the team is well aware > that rustc itself runs more slowly than it should; it is a common > topic of discussion. > > The team is also well aware that the time to bootstrap librustc+libstd > is longer than many developers can cope with. > > I am not sure I agree with the assertion that the approach of breaking > a project into multiple crates is not a solution. Yes, we may need > better tools here (though I don't know how much rustpkg could help > with this problem). > > ---- > > As promised, here are some relevant links to previous posts. In *all* > of the cases below, the *whole thread* is often worth review. > > * A great overview from pcwalton > Thread subject: " Why does Rust compile slowly?" > https://mail.mozilla.org/pipermail/rust-dev/2012-October/002462.html > > * In early 2013 there was discussion of easing crate decomposition: > Thread subject: " Plans for improving compiler performance" > https://mail.mozilla.org/pipermail/rust-dev/2013-January/002878.html > > * strcat and graydon each had good points in this discussion: > Thread subject: "Please tell me about making rustc faster" > https://mail.mozilla.org/pipermail/rust-dev/2013-May/004326.html > https://mail.mozilla.org/pipermail/rust-dev/2013-May/004328.html > > * The team internally discussed whether to break lubrustc into > multiple subcrates here: > Thread subject: " code generation and rustc speed" > https://mail.mozilla.org/pipermail/rust-dev/2013-June/004493.html > > > Cheers, > -Felix > > On 29/11/2013 12:22, Guillaume HERVIER wrote: >> +1 for this issue. I think that compilation time is really important >> if we want Rust to be used as production language. >> >> For example, I think that if we can reduce significantly the Rust >> compiler's compilation time, it could allow more developers to >> contribute to the Rust language (as they won't have to wait 30min for >> each small modifications in the compiler). >> Personally, it's the only thing which blocks me when I want to >> contribute to Rust, because I like to often compile code when I do >> small modifications to test each of these small modifications, partly >> because I don't know the language very well. >> >> On 11/29/2013 12:01 PM, L?o Testard wrote: >>> >>> Hello, >>> >>> I think everyone here will agree to say that compilation times in >>> Rust are problematic. Recently, there was an argument on IRC about >>> reducing compilation times by reducing the use of GC and failures. >>> Although I agree it's good to reduce Rustc's overhead, I think there >>> are more important problems. The total duration of a build matters >>> only because you have to recompile the whole crate on each >>> modification. In C++, the duration of the complete build of a >>> project matters less because when you compile incrementally, you >>> only have to rebuild a couple of files - those you modified. I know >>> the "1 crate = 1 compilation unit" is the model chosen by Rust, but >>> this is a major issue for production. Nobody will ever use Rust in >>> production if they have to recompile thousands of lines of code on >>> each modification. >>> >>> On some of my personal projects, I "solved" this problem by >>> splitting the codebase into several crates, that I compile >>> statically, and then link together using extern mod. This is not >>> really a solution, because this implies that there is no cyclic >>> dependency between each of the small crates, or I end up with issues >>> trying to compile it, because using extern mod requires that the >>> library corresponding to that mod exists before compiling the crate >>> that depends on it. >>> >>> But strictly speaking, a compiled crate is nothing more than a >>> module hierarchy, and so is a single Rust source file, so we should >>> be able to compile a single file to some sort of .o and then link >>> all together to form a crate. References to modules outside of this >>> file just require the first passes of the build, not the code >>> generation, so it should be ok regarding to cyclic dependencies, and >>> if not, we could still introduce some kind of auto-generated >>> interface file, like Caml does. I know it's quite a big work, and >>> that the current system is quite good, but having this is very >>> important if we want Rust to be used in production. >>> >>> Sorry if this topic has already been posted several times, but I >>> feel this is important, and the related issues seem to date (#2369). >>> I think it's a real mistake to report this to post-1.0. >>> >>> Leo >>> >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > -- > irc: pnkfelix on irc.mozilla.org > email: {fklock,pnkfelix}@mozilla.com > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Wed Dec 4 12:26:09 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 04 Dec 2013 12:26:09 -0800 Subject: [rust-dev] Separated/Incremential compilation In-Reply-To: References: <5298CA4A.7000106@mozilla.com> Message-ID: <3f11298d-eafa-4410-896b-13d0f662c2d2@email.android.com> Maybe this should be done upstream in LLVM, actually. Seems like work that would be applicable to e.g. clang with LTO as well. Tim Chevalier wrote: >On Fri, Nov 29, 2013 at 9:09 AM, Patrick Walton >wrote: >> I shouldn't say that Rust has no problems with build times--it could >always >> be faster, and in particular the memory representations are >inefficient, >> particularly around ASTs--but when you actually run with `-Z >time-passes`, >> you'll see that the vast majority of the time for any >reasonably-sized crate >> is spent in LLVM. There isn't much we can do to make that faster by >an order >> of magnitude, other than to try to push on the parallel per-function >> optimization and codegen work that is happening in some upstream >branches. >> Mergefunc, disabling exceptions, and the no-zeroing-out stuff that >Niko is >> doing would be nice, but they won't improve build times by an order >of >> magnitude. > >What about caching LLVM bitcode for individual Rust functions / items >(using workcache, for example) and only recompiling those items whose >dependencies have changed? Obviously this would be a lot of design and >implementation work, and one would want to do the math to make sure >it's likely to improve build performance, but offhand I can't see why >it's not feasible. > >The scenario I'm thinking of is "add a debug! statement to one >function, and only recompile the code for that function since its >interface hasn't changed". In that case, only regenerating code for >the changed function and not the entire crate should make a big >difference. > >Cheers, >Tim > >> >> Patrick >> >> [1]: >> >https://groups.google.com/forum/#!topic/mozilla.dev.platform/WjcCfckml4A >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > >-- >Tim Chevalier * http://catamorphism.org/ * Often in error, never in >doubt >"If you are silent about your pain, they'll kill you and say you >enjoyed it." >-- Zora Neale Hurston -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill_myers at outlook.com Wed Dec 4 12:36:00 2013 From: bill_myers at outlook.com (Bill Myers) Date: Wed, 4 Dec 2013 20:36:00 +0000 Subject: [rust-dev] Persistent data structures In-Reply-To: <529ED9A4.4080901@isaac.cedarswampstudios.org> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> Message-ID: Hello, I already implemented a persistent tree-map called SnapMap: you can find the source code at https://github.com/mozilla/rust/pull/9816 I stopped working on it before I made a serious effort to push it into the Rust codebase and don't have time to work further on it, so it would be awesome if you were interested in continuing that effort. It's pretty much finished, but pretty much completely untested (however, it was derived from the existing treemap, so the amount of bugs should not be as high as something written from scratch and untested). The first thing that needs to be done is to run the existing tests inherited from treemap, fix any bug that shows up, and then write more tests to test SnapMap specific usage patterns and features. Then, one should look at the mutable/handle-based iterators in the code and decide whether they should be removed, kept as is, or improved, possibly after changing the iterator interface to return an object with the lifetime of the function call instead of the iterator. The rest of the code should be fine (except for bugs due to no testing), but there might be places where unnecessary copy-on-write is performed. My code used an improved version of Rc that supports copy-on-write by cloning only when reference count > 1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Wed Dec 4 12:54:55 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 4 Dec 2013 15:54:55 -0500 Subject: [rust-dev] Please welcome the Rust and Servo GNOME/OPW interns for December 2013-March 2014 In-Reply-To: References: Message-ID: Hooray, welcome to our new contributors! :) And thanks to our mentors and coordinators as well! On Wed, Dec 4, 2013 at 11:18 AM, Tim Chevalier wrote: > Hello, > > I'm pleased to announce that the winter/spring Rust and Servo interns > through the GNOME Outreach Program for Women ( > https://wiki.gnome.org/OutreachProgramForWomen ) have been chosen. The > program starts December 10 and runs until March 10. > > Nif Ward (IRC nick: nif) will be interning on Rust, working to develop > a full-fledged B-tree library. Nif is a senior graduating this fall in > computer science from Oberlin College in Ohio, USA. I will be her > mentor. > > Isabelle Carter (IRC nick: ibnc) will be interning on Servo, working > to add support for fixed positioning. Isabelle is on leave from her > undergraduate degree in mathematics, and will be working from > Springfield, Missouri, USA. Lars Bergstrom will be her mentor. > > We had many qualified applicants for Rust and Servo's first foray into > OPW, so it's an honor to be chosen for this program. Please be > friendly to nif and ibnc if you see them on #rust! > > Depending how this round of OPW goes, Rust and/or Servo may > participate in a future iteration, so if you're interested in > applying, then keep watching for more announcements. In addition, > internships at Mozilla working on Rust and Servo (look for the > "Research Engineering" listing; paid, on-site in the Bay Area) are > open to all graduate students (undergraduate students with research > experience have been considered in the past): > http://careers.mozilla.org/ . > > Thanks are due to the Rust and Servo teams -- particularly Lars > Bergstrom, Brian Anderson, and Jack Moffitt -- for helping many people > apply for the program, and to the Mozilla coordinator for OPW, Larissa > Shapiro, for their efforts. > > Cheers, > Tim > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > "If you are silent about your pain, they'll kill you and say you enjoyed > it." > -- Zora Neale Hurston > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at isaac.cedarswampstudios.org Wed Dec 4 13:17:58 2013 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Wed, 04 Dec 2013 16:17:58 -0500 Subject: [rust-dev] Persistent data structures In-Reply-To: <529F7E04.3000809@posteo.de> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> <529EE687.2060004@mozilla.com> <529F7E04.3000809@posteo.de> Message-ID: <529F9C06.7080801@isaac.cedarswampstudios.org> On 12/04/2013 02:09 PM, Michael Woerister wrote: >>> Is it >>> possible for the structure to be parametrized on smart pointer? >> >> Not without higher kinded types (which eventually we do want--so the >> answer is "not yet"). > > And then we can define a container type, using the generic reference type: > > struct Container { > items: ~[TRef], > reference_factory: TRefFactory > } Clever solution! In the cons list, it needs to be a reference to Node, not to T. Every persistent container library would have to expose its node type and take as a parameter an allocator for its Node. Simplified example: enum Node { Nil, Cons(T, TNodeRef) } type IntList = Rc>; But that is an infinite type and, as such, does not compile. Instead using struct IntList(Rc>); works and could implement the necessary traits. Or better, struct RcList(Rc>>); Ooh, this is within the realm of maybe being reasonable. A persistent data structure module could provide RcList and ArcList versions. Is performance affected by the use of traits for this strategy, or does the way Rust generics are compiled make that a non-issue? Are there other reasons this is a terrible idea? :) -Isaac From danielmicay at gmail.com Wed Dec 4 13:28:18 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 4 Dec 2013 16:28:18 -0500 Subject: [rust-dev] Persistent data structures In-Reply-To: <529F9C06.7080801@isaac.cedarswampstudios.org> References: <529ED9A4.4080901@isaac.cedarswampstudios.org> <529EE687.2060004@mozilla.com> <529F7E04.3000809@posteo.de> <529F9C06.7080801@isaac.cedarswampstudios.org> Message-ID: On Wed, Dec 4, 2013 at 4:17 PM, Isaac Dupree wrote: > On 12/04/2013 02:09 PM, Michael Woerister wrote: >>>> >>>> Is it >>>> possible for the structure to be parametrized on smart pointer? >>> >>> >>> Not without higher kinded types (which eventually we do want--so the >>> answer is "not yet"). >> >> >> And then we can define a container type, using the generic reference type: >> >> struct Container { >> items: ~[TRef], >> reference_factory: TRefFactory >> } > > > Clever solution! In the cons list, it needs to be a reference to Node, > not to T. Every persistent container library would have to expose its node > type and take as a parameter an allocator for its Node. Simplified > example: > > enum Node { > Nil, > Cons(T, TNodeRef) > } > > type IntList = Rc>; > > But that is an infinite type and, as such, does not compile. Instead using > > struct IntList(Rc>); > > works and could implement the necessary traits. Or better, > > struct RcList(Rc>>); > > Ooh, this is within the realm of maybe being reasonable. A persistent data > structure module could provide RcList and ArcList versions. Is performance > affected by the use of traits for this strategy, or does the way Rust > generics are compiled make that a non-issue? Are there other reasons this > is a terrible idea? :) > > -Isaac Generics are equivalent to substituting all of the type parameters with the concrete type by hand. Specialized code is generated for each set of type parameters with removing the duplication left up to LLVM (`mergefunc` is close to being completely stable). From ml at isaac.cedarswampstudios.org Wed Dec 4 13:42:51 2013 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Wed, 04 Dec 2013 16:42:51 -0500 Subject: [rust-dev] Persistent data structures In-Reply-To: References: <529ED9A4.4080901@isaac.cedarswampstudios.org> Message-ID: <529FA1DB.9030000@isaac.cedarswampstudios.org> On 12/04/2013 03:36 PM, Bill Myers wrote: > Hello, I already implemented a persistent tree-map called SnapMap: you > can find the source code at https://github.com/mozilla/rust/pull/9816 > > I stopped working on it before I made a serious effort to push it into > the Rust codebase and don't have time to work further on it, so it would > be awesome if you were interested in continuing that effort. > > It's pretty much finished, but pretty much completely untested (however, > it was derived from the existing treemap, so the amount of bugs should > not be as high as something written from scratch and untested). > > The first thing that needs to be done is to run the existing tests > inherited from treemap, fix any bug that shows up, and then write more > tests to test SnapMap specific usage patterns and features. Yay! Looks like I should start by collecting the various existing persistent structures (your SnapMap, Michael's HAMT, extra::list) and polishing them up. > Then, one should look at the mutable/handle-based iterators in the code > and decide whether they should be removed, kept as is, or improved, > possibly after changing the iterator interface to return an object with > the lifetime of the function call instead of the iterator. > > The rest of the code should be fine (except for bugs due to no testing), > but there might be places where unnecessary copy-on-write is performed. > > My code used an improved version of Rc that supports copy-on-write by > cloning only when reference count > 1. Did COW improve performance? What's a good way to do performance testing of Rust code? Should I try to get your patches to Rc and Arc merged? They look generally useful, if folks think they fit the design of Rc. You also have a patch that adds Own to std which is equivalent to ~T but has methods that look like Rc's. You use this, and putting most of your treemap.rs inside macro definitions, to get a sort of reference-type-polymorphism in your treemap. Shall I continue with this approach and try to get Own merged too? (Opinions from anybody are welcome.) (I used https://github.com/mozilla/rust/pull/9816/files + click "Show Diff Stats" to look through the changes) -Isaac From hatahet at gmail.com Wed Dec 4 17:07:10 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Wed, 4 Dec 2013 17:07:10 -0800 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity Message-ID: To be taken with a grain of salt, naturally: https://www.youtube.com/watch?v=TS1lpKBMkgg -- Ziad -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill_myers at outlook.com Wed Dec 4 18:15:06 2013 From: bill_myers at outlook.com (Bill Myers) Date: Thu, 5 Dec 2013 02:15:06 +0000 Subject: [rust-dev] Persistent data structures In-Reply-To: <529FA1DB.9030000@isaac.cedarswampstudios.org> References: <529ED9A4.4080901@isaac.cedarswampstudios.org>, , <529FA1DB.9030000@isaac.cedarswampstudios.org> Message-ID: > Did COW improve performance? What's a good way to do performance > testing of Rust code? The reason I introduced COW when RC > 1 is that it allows persistent data structures to be mutated in place if there aren't extra references, just like non-persistent data structures. Lots of languages with persistent data structures can't do that because they use garbage collection (and thus they can't tell whether there are other references due to lack of a reference count), but it seems an essential feature to have if one is using reference counting in a language like Rust that is supposed to be a systems language producing optimal code. > Should I try to get your patches to Rc and Arc merged? They look > generally useful, if folks think they fit the design of Rc. You also > have a patch that adds Own to std which is equivalent to ~T but has > methods that look like Rc's. You use this, and putting most of your > treemap.rs inside macro definitions, to get a sort of > reference-type-polymorphism in your treemap. Shall I continue with this > approach and try to get Own merged too? (Opinions from anybody are > welcome.) I did it because I realized that having two different balanced tree implementations would have imposed a significant maintenance burden, and thus the macro and Own approach would have allowed to avoid that by replacing the current treemap code completely with the new optionally-persistent version. Also, having both Rc and Arc versions seems quite useful anyway, and currently I think macros are the best way to have both, until Rust starts supporting higher-kinded types (which would allow to pass Rc as a parameter), or at least recursive types (which would allow to express Rc instead of ~T and so on; I guess someone on the Rust core team will have to decide on that, and there's already some discussion on that on https://github.com/mozilla/rust/pull/9786 -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at kevincantu.org Wed Dec 4 19:36:24 2013 From: me at kevincantu.org (Kevin Cantu) Date: Wed, 4 Dec 2013 19:36:24 -0800 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: References: Message-ID: There are a couple parts of the Rust compiler about which I've heard people say "if I knew how that worked, I'd fix it so that we could do ..." So I definitely thought of Rust when watching that. I think it is very encouraging to see so how many components Rust has pushed out of the core and into libraries in the last year or so, though. Rust seems a long way from ossification. Considering Scala, count me pre-emptively as a fan of rustz. Hopefully we can avoid that kind of apparent community split, though... Kevin On Wed, Dec 4, 2013 at 5:07 PM, Ziad Hatahet wrote: > To be taken with a grain of salt, naturally: > https://www.youtube.com/watch?v=TS1lpKBMkgg > > > -- > Ziad > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From pcwalton at mozilla.com Wed Dec 4 19:46:41 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 04 Dec 2013 19:46:41 -0800 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: References: Message-ID: <529FF721.6010908@mozilla.com> On 12/4/13 7:36 PM, Kevin Cantu wrote: > There are a couple parts of the Rust compiler about which I've heard > people say "if I knew how that worked, I'd fix it so that we could do > ..." So I definitely thought of Rust when watching that. The Rust compiler is not that bad. Niko and I, as well as several others I'm sure, know how basically all of it works, at least at a high level. I think it's true that in any large piece of software, it's never true that everyone knows precisely how all of it works. The biggest problem with the Rust compiler, I think, is much of it is written in an old Rust style, and modernizing its style would not take too long. (Unfortunately we're all racing to 1.0 and on the core team such modernization will have to take a back seat to the 1.0-incompatible language changes... but that said we should not allow our technical debt to garner too much interest.) The particular criticisms of the Scala compiler, that the front-end does too much desugaring and that code is a string, are definitely not true for the Rust compiler. (Well, OK, `for` is desugared too early, but that has to be fixed before 1.0 anyway because this desugaring is actually incorrect.) Niko and Jed, just to name two, have done a lot of work to improve the state of the Rust compiler, for example by rewriting type unification, rewriting ad-hoc passes to use the CFG produced by liveness analysis, introducing `Datum`, and creating a universal ADT type to represent data types. There is more work to be done, of course, and I think we should very much hold the line against additional cruft being added to the compiler at this point, but I think we're OK as long as we keep moving in the right direction. Patrick From pcwalton at mozilla.com Wed Dec 4 19:53:10 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 04 Dec 2013 19:53:10 -0800 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: References: Message-ID: <529FF8A6.2050008@mozilla.com> On 12/4/13 5:07 PM, Ziad Hatahet wrote: > To be taken with a grain of salt, naturally: > https://www.youtube.com/watch?v=TS1lpKBMkgg I watched some of this. Some notes on specific criticisms follow. (Many of the criticisms are too abstract to really confront head-on though--for example, "correctness versus performance".) 1. *The compiler is too hard to modify.* See my other message in the thread. 2. *Universal equality is bad.* Rust doesn't do it. 3. *Using inheritance for collection mutability is bad.* Rust doesn't do it. 4. *The argument to functions such as "filter" should be pure to allow for stream fusion.* Purity is hard in Rust. We tried it and the annotation burden was too high. At least our iterators allow for more stream fusion than creating intermediate data structures would. 5. *Forbid reference equality.* Incompatible with the systems language nature of Rust. 6. *Silent coercion between primitives is bad.* Rust doesn't do it. 7. *Don't try to be too general purpose.* Rust is explicitly not designed to be a language for all use cases. 8. *Unnecessary expressiveness is the enemy.* I think we've been holding the line on language complexity quite well, even for features that are popular like `&once fn`. Patrick From qwertie256 at gmail.com Wed Dec 4 20:03:42 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Wed, 4 Dec 2013 21:03:42 -0700 Subject: [rust-dev] Persistent data structures Message-ID: >My next goal is a persistent tree-map, probably cribbing from Haskell's >Data.Map. I look forward to hearing how that goes! I've been meaning to make a data structure in Rust too, but it's hard to find the time, so how's about I tell you guys about it instead. I call my data structure an "optionally-persistent" hashtable or hashset. In C# I implemented this "optionally-persistent" hashtable and hashset with mutable and immutable variants of each (the term "semi-persistent" was already taken and means something else). I've been meaning to write an article about this, but didn't get around to it yet. Optionally-persistent means that it's structured as if it were persistent, but each node can be either mutable (locally) or immutable (recursively). Each node has a "frozen" flag which implicitly applies recursively to all children. Converting the tree from immutable to mutable, or mutable to immutable takes O(1) time. Immutable to mutable is essentially a no-op (the mutable copy has copy-on-write behavior), while mutable-to-immutable simply requires marking the root node as frozen. The "hashtable" is really a tree that is up to 8 levels deep, with each level representing 4 bits of the hashcode (not sure if this is the best approach). Lots more details in the doc comment: https://sourceforge.net/p/loyc/code/HEAD/tree/Src/Loyc.Collections/Sets/InternalSet.cs My benchmarks show that mutating such a set/map is dramatically faster than immutable editing (which requires copying multiple nodes for each change), and not that much slower than a traditional hashtable, so I think it's "hands down" superior to a traditional persistent hash tree. In my version, from the end-user's perspective, there's a separate data type for immutable and mutable versions of the data structure (MMap and MSet are mutable, Map and Set are immutable). Both data types encapsulate an instance of InternalSet which is the "real" data structure. InternalSet manages a tree of nodes, where each node has 16 entries and represents 4 bits of the hashcode. There's also an interesting variation called InvertibleSet; an invertible set can represent a negative set such as "all integers except 0 and 1". -- - David http://loyc-etc.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjzaba at yahoo.com.au Wed Dec 4 20:18:03 2013 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Thu, 5 Dec 2013 14:18:03 +1000 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: <529FF721.6010908@mozilla.com> References: <529FF721.6010908@mozilla.com> Message-ID: On 5 Dec 2013, at 1:46 pm, Patrick Walton wrote: > The particular criticisms of the Scala compiler, that the front-end does too much desugaring and that code is a string, are definitely not true for the Rust compiler. (Well, OK, `for` is desugared too early, but that has to be fixed before 1.0 anyway because this desugaring is actually incorrect.) Whilst desugaring too early is indeed an issue for creating a robust compiler, would it still make sense to think of how these language features desugar on a design/theoretical level? Then once these are set in stone for 1.0, document these transformations? ~Brendan From ben.striegel at gmail.com Wed Dec 4 21:29:03 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Thu, 5 Dec 2013 00:29:03 -0500 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: <529FF8A6.2050008@mozilla.com> References: <529FF8A6.2050008@mozilla.com> Message-ID: > 3. *Using inheritance for collection mutability is bad.* Rust doesn't do it. Is this an argument against generalizing over mutability at all (as I believe has been proposed in the past)? On Wed, Dec 4, 2013 at 10:53 PM, Patrick Walton wrote: > On 12/4/13 5:07 PM, Ziad Hatahet wrote: > >> To be taken with a grain of salt, naturally: >> https://www.youtube.com/watch?v=TS1lpKBMkgg >> > > I watched some of this. Some notes on specific criticisms follow. (Many of > the criticisms are too abstract to really confront head-on though--for > example, "correctness versus performance".) > > 1. *The compiler is too hard to modify.* See my other message in the > thread. > > 2. *Universal equality is bad.* Rust doesn't do it. > > 3. *Using inheritance for collection mutability is bad.* Rust doesn't do > it. > > 4. *The argument to functions such as "filter" should be pure to allow for > stream fusion.* Purity is hard in Rust. We tried it and the annotation > burden was too high. At least our iterators allow for more stream fusion > than creating intermediate data structures would. > > 5. *Forbid reference equality.* Incompatible with the systems language > nature of Rust. > > 6. *Silent coercion between primitives is bad.* Rust doesn't do it. > > 7. *Don't try to be too general purpose.* Rust is explicitly not designed > to be a language for all use cases. > > 8. *Unnecessary expressiveness is the enemy.* I think we've been holding > the line on language complexity quite well, even for features that are > popular like `&once fn`. > > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Dec 4 21:31:51 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 04 Dec 2013 21:31:51 -0800 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: References: <529FF8A6.2050008@mozilla.com> Message-ID: <52A00FC7.90908@mozilla.com> On 12/4/13 9:29 PM, Benjamin Striegel wrote: > > 3. *Using inheritance for collection mutability is bad.* Rust doesn't > do it. > > Is this an argument against generalizing over mutability at all (as I > believe has been proposed in the past)? According to the talk it's more of a problem specific to OO-style *inheritance* (which we do have an equivalent to via default methods, but stylistically we don't use it unless it really fits the problem). Patrick From ohler at gnu.org Wed Dec 4 22:17:18 2013 From: ohler at gnu.org (Christian Ohler) Date: Wed, 4 Dec 2013 22:17:18 -0800 Subject: [rust-dev] Error casting to trait: "value may contain borrowed pointers" In-Reply-To: <529C9003.10302@mozilla.com> References: <529C9003.10302@mozilla.com> Message-ID: I see, thanks for the explanation. Looks like a compiler bug, then. I'll work around it with an unsafe transmute for now. Thanks, Christian. On Mon, Dec 2, 2013 at 5:49 AM, Felix S. Klock II wrote: > rust-dev- > > In general, we need to ensure that for an expression ` as ` > that any borrowed pointers in the type of are not obscured [1] by > the cast. > > A collection of conditions sufficient to enforce this are listed in a > comment in librustc/middle/kind.rs that I think is apropos here: > > https://github.com/mozilla/rust/blob/master/src/librustc/middle/kind.rs#L488 > > However, there are probably other conditions that would also suffice that we > might add to that set. > > In particular, I do not see anything immediately wrong with your example; > the type-expression `&'a V` should ensure that `V` does not contain any > lifetimes that are shorter than 'a, and therefore it should be safe to cast > `v: &'a V` to a `&'a T`. > > I have filed this as issue #10766 [2]. > > Cheers, > -Felix > > [1] https://github.com/mozilla/rust/issues/5723 > > [2] https://github.com/mozilla/rust/issues/10766 > > > On 30/11/2013 23:22, Christian Ohler wrote: >> >> Hi all, >> >> I'm trying to learn rust and ran into an error message I don't >> understand, and would appreciate some help. This code: >> >> trait T {} >> >> fn f<'a, V: T>(v: &'a V) -> &'a T { >> v as &'a T >> } >> >> >> is rejected with this error message: >> >> trait-cast.rs:4:4: 4:5 error: value may contain borrowed pointers; add >> `'static` bound >> trait-cast.rs:4 v as &'a T >> >> >> I'm trying to upcast from V to T so that I can put v in a container of >> element type T (in code not shown here). The suggestion to add a >> 'static bound doesn't sound like what I'm looking for. >> >> What is the concern about borrowed pointers here? What would an >> implementation of T and a caller of f look like to lead to a safety >> problem? >> >> I'm using a version of rust that is a few days old. >> >> Thanks, >> Christian. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > -- > irc: pnkfelix on irc.mozilla.org > email: {fklock, pnkfelix}@mozilla.com > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From qwertie256 at gmail.com Wed Dec 4 22:23:02 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Wed, 4 Dec 2013 23:23:02 -0700 Subject: [rust-dev] Persistent data structures In-Reply-To: References: Message-ID: Please disregard this message; I hadn't seen Bill Myers' solution ("copy-on-write by cloning only when reference count > 1"), which sounds like it's probably perfect for Rust. On Wed, Dec 4, 2013 at 9:03 PM, David Piepgrass wrote: > >My next goal is a persistent tree-map, probably cribbing from Haskell's > >Data.Map. > > I look forward to hearing how that goes! > > I've been meaning to make a data structure in Rust too, but it's hard to > find the time, so how's about I tell you guys about it instead. > > I call my data structure an "optionally-persistent" hashtable or hashset. > In C# I implemented this "optionally-persistent" hashtable and hashset with > mutable and immutable variants of each (the term "semi-persistent" was > already taken and means something else). I've been meaning to write an > article about this, but didn't get around to it yet. > > Optionally-persistent means that it's structured as if it were persistent, > but each node can be either mutable (locally) or immutable (recursively). > Each node has a "frozen" flag which implicitly applies recursively to all > children. Converting the tree from immutable to mutable, or mutable to > immutable takes O(1) time. Immutable to mutable is essentially a no-op (the > mutable copy has copy-on-write behavior), while mutable-to-immutable simply > requires marking the root node as frozen. > > The "hashtable" is really a tree that is up to 8 levels deep, with each > level representing 4 bits of the hashcode (not sure if this is the best > approach). Lots more details in the doc comment: > > > https://sourceforge.net/p/loyc/code/HEAD/tree/Src/Loyc.Collections/Sets/InternalSet.cs > > My benchmarks show that mutating such a set/map is dramatically faster > than immutable editing (which requires copying multiple nodes for each > change), and not that much slower than a traditional hashtable, so I think > it's "hands down" superior to a traditional persistent hash tree. > > In my version, from the end-user's perspective, there's a separate data > type for immutable and mutable versions of the data structure (MMap and > MSet are mutable, Map and Set are immutable). Both data types > encapsulate an instance of InternalSet which is the "real" data > structure. InternalSet manages a tree of nodes, where each node has 16 > entries and represents 4 bits of the hashcode. There's also an interesting > variation called InvertibleSet; an invertible set can represent a > negative set such as "all integers except 0 and 1". > > -- > - David > http://loyc-etc.blogspot.com > > -- - David http://qism.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.delrieu at free.fr Thu Dec 5 00:43:49 2013 From: philippe.delrieu at free.fr (Philippe Delrieu) Date: Thu, 05 Dec 2013 09:43:49 +0100 Subject: [rust-dev] new compile errors in the master since a few days Message-ID: <52A03CC5.7070500@free.fr> Hello, since a few days, I have a lot of new errors in the master compiler. For example in the rust_zmq lib that I use. When I compile it I have these errors : 321:9 error: last argument in `do` call has non-procedure type: |*i8| -> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319 let rc = do endpoint.with_c_str |cstr| { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320 unsafe {zmq_bind(self.sock, cstr)} /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321 }; /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29: 330:9 error: last argument in `do` call has non-procedure type: |*i8| -> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328 let rc = do endpoint.with_c_str |cstr| { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329 unsafe {zmq_connect(self.sock, cstr)} /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330 }; /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16: 352:9 error: last argument in `do` call has non-procedure type: |*u8, uint| -> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337 do data.as_imm_buf |base_ptr, len| { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338 let msg = [0, ..32]; /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340 unsafe { /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341 // Copy the data into the message. /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 zmq_msg_init_size(&msg, len as size_t); ... /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40: 342:43 error: the type of this value must be known in this context /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 zmq_msg_init_size(&msg, len as size_t); ^~~ /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344:16: 344:32 error: cannot determine a type for this bounded type parameter: unconstrained type /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344 ptr::copy_memory(::cast::transmute(zmq_msg_data(&msg)), base_ptr, len); ^~~~~~~~~~~~~~~~ I have the same type of errors in my code plus other error when the trait can't be found like type `MyType` does not implement any method in scope named `encode` and the function is implemented just above. This code where compiling last week. Philippe Delrieu From kevin at sb.org Thu Dec 5 00:56:14 2013 From: kevin at sb.org (Kevin Ballard) Date: Thu, 5 Dec 2013 00:56:14 -0800 Subject: [rust-dev] new compile errors in the master since a few days In-Reply-To: <52A03CC5.7070500@free.fr> References: <52A03CC5.7070500@free.fr> Message-ID: `do` no longer works with stack closures. It now only works with the new proc() type, which basically means you're only going to see it used with spawn(). You need to now say something like let rc = endpoint.with_c_str(|cstr| { unsafe {smq_bind(self.sock, cstr)} }); I can't speculate on your encode error without seeing it. -Kevin On Dec 5, 2013, at 12:43 AM, Philippe Delrieu wrote: > Hello, > > since a few days, I have a lot of new errors in the master compiler. For example in the rust_zmq lib that I use. When I compile it I have these errors : > 321:9 error: last argument in `do` call has non-procedure type: |*i8| -> > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319 let rc = do endpoint.with_c_str |cstr| { > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320 unsafe {zmq_bind(self.sock, cstr)} > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321 }; > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29: 330:9 error: last argument in `do` call has non-procedure type: |*i8| -> > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328 let rc = do endpoint.with_c_str |cstr| { > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329 unsafe {zmq_connect(self.sock, cstr)} > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330 }; > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16: 352:9 error: last argument in `do` call has non-procedure type: |*u8, uint| -> > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337 do data.as_imm_buf |base_ptr, len| { > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338 let msg = [0, ..32]; > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339 > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340 unsafe { > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341 // Copy the data into the message. > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 zmq_msg_init_size(&msg, len as size_t); > ... > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40: 342:43 error: the type of this value must be known in this context > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 zmq_msg_init_size(&msg, len as size_t); > ^~~ > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344:16: 344:32 error: cannot determine a type for this bounded type parameter: unconstrained type > /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344 ptr::copy_memory(::cast::transmute(zmq_msg_data(&msg)), base_ptr, len); > ^~~~~~~~~~~~~~~~ > I have the same type of errors in my code plus other error when the trait can't be found like type `MyType` does not implement any method in scope named `encode` and the function is implemented just above. > This code where compiling last week. > > Philippe Delrieu > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From philippe.delrieu at free.fr Thu Dec 5 01:53:35 2013 From: philippe.delrieu at free.fr (Philippe Delrieu) Date: Thu, 05 Dec 2013 10:53:35 +0100 Subject: [rust-dev] new compile errors in the master since a few days In-Reply-To: References: <52A03CC5.7070500@free.fr> Message-ID: <52A04D1F.3040102@free.fr> Thank you it correct my first problems. I didn't send code because I thought it has the same cause. For the last problems the code is : use extra::serialize; use extra::json::{Json, Decoder, ToJson, Object, Encoder, Decoder}; use extra::treemap::TreeMap; use std::io::Decorator; //second struct with manually implemented Decodable, Encodable #[deriving(Decodable, Encodable, Eq)] pub struct TestStruct2 { dataInt: u8, dataStr:~str, dataArray:~[u8], } let test3 : TestStruct2 = TestStruct2 {dataInt: 1, dataStr:~"toto", dataArray:~[2,3,4,5]}; //{\"dataArray\":[2,3,4,5],\"dataInt\":1,\"dataStr\":\"toto\"} let mut m3 = MemWriter::new(); { let mut encoder3 =Encoder::init(&mut m3 as &mut Writer); test3.encode(&mut encoder3); } Rustc result : test_json.rs:292:8: 292:36 error: type `TestStruct2` does not implement any method in scope named `encode` test/test_json.rs:292 test3.encode(&mut encoder3); Philippe Le 05/12/2013 09:56, Kevin Ballard a ?crit : > `do` no longer works with stack closures. It now only works with the new proc() type, which basically means you're only going to see it used with spawn(). > > You need to now say something like > > let rc = endpoint.with_c_str(|cstr| { > unsafe {smq_bind(self.sock, cstr)} > }); > > I can't speculate on your encode error without seeing it. > > -Kevin > > On Dec 5, 2013, at 12:43 AM, Philippe Delrieu wrote: > >> Hello, >> >> since a few days, I have a lot of new errors in the master compiler. For example in the rust_zmq lib that I use. When I compile it I have these errors : >> 321:9 error: last argument in `do` call has non-procedure type: |*i8| -> >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319 let rc = do endpoint.with_c_str |cstr| { >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320 unsafe {zmq_bind(self.sock, cstr)} >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321 }; >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29: 330:9 error: last argument in `do` call has non-procedure type: |*i8| -> >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328 let rc = do endpoint.with_c_str |cstr| { >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329 unsafe {zmq_connect(self.sock, cstr)} >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330 }; >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16: 352:9 error: last argument in `do` call has non-procedure type: |*u8, uint| -> >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337 do data.as_imm_buf |base_ptr, len| { >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338 let msg = [0, ..32]; >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339 >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340 unsafe { >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341 // Copy the data into the message. >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 zmq_msg_init_size(&msg, len as size_t); >> ... >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40: 342:43 error: the type of this value must be known in this context >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 zmq_msg_init_size(&msg, len as size_t); >> ^~~ >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344:16: 344:32 error: cannot determine a type for this bounded type parameter: unconstrained type >> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344 ptr::copy_memory(::cast::transmute(zmq_msg_data(&msg)), base_ptr, len); >> ^~~~~~~~~~~~~~~~ >> I have the same type of errors in my code plus other error when the trait can't be found like type `MyType` does not implement any method in scope named `encode` and the function is implemented just above. >> This code where compiling last week. >> >> Philippe Delrieu >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > From jurily at gmail.com Thu Dec 5 03:40:40 2013 From: jurily at gmail.com (=?ISO-8859-1?Q?Gy=F6rgy_Andrasek?=) Date: Thu, 05 Dec 2013 12:40:40 +0100 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: <529FF8A6.2050008@mozilla.com> References: <529FF8A6.2050008@mozilla.com> Message-ID: <52A06638.8000808@gmail.com> On 12/05/2013 04:53 AM, Patrick Walton wrote: > 4. *The argument to functions such as "filter" should be pure to allow > for stream fusion.* Purity is hard in Rust. We tried it and the > annotation burden was too high. At least our iterators allow for more > stream fusion than creating intermediate data structures would. Could you elaborate a bit for those of us who weren't around? I've been thinking about how purity would work in Rust, but a quick search says the verdict was apparently "kill it with fire" (#5384). If there's a List of Things We've Already Tried So Stop Asking, this really needs to be on it. From asb at asbradbury.org Thu Dec 5 04:26:53 2013 From: asb at asbradbury.org (Alex Bradbury) Date: Thu, 5 Dec 2013 12:26:53 +0000 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: <52A06638.8000808@gmail.com> References: <529FF8A6.2050008@mozilla.com> <52A06638.8000808@gmail.com> Message-ID: On 5 December 2013 11:40, Gy?rgy Andrasek wrote: > On 12/05/2013 04:53 AM, Patrick Walton wrote: >> >> 4. *The argument to functions such as "filter" should be pure to allow >> for stream fusion.* Purity is hard in Rust. We tried it and the >> annotation burden was too high. At least our iterators allow for more >> stream fusion than creating intermediate data structures would. > > > Could you elaborate a bit for those of us who weren't around? I've been > thinking about how purity would work in Rust, but a quick search says the > verdict was apparently "kill it with fire" (#5384). If there's a List of > Things We've Already Tried So Stop Asking, this really needs to be on it. Graydon's response here and other posts in that thread gives one starting point. Alex From gokcehankara at gmail.com Thu Dec 5 05:20:12 2013 From: gokcehankara at gmail.com (Gokcehan Kara) Date: Thu, 5 Dec 2013 15:20:12 +0200 Subject: [rust-dev] How to reply properly in digest mode? Message-ID: Hello, I don't have much experience with email lists but I would like to gain some. I have been using digest mode for 'rust-dev' and I'm not sure how to reply properly to a specific thread. Things I'm looking for are: - Having the specific thread subject instead of 'Rust-dev Digest..'. There is a note in digest emails about doing this manually so I'm guessing there is no easier way to do it? - Having responses archived in the appropriate thread. I have read something about in-reply headers and I'm not sure how manually adjusting the subject line would work regarding this. - Replying to all people participating in the thread while also cc'in the mail to the mail list so people can use reply all functionality to easily reply back. There are message-id's in each mail which looks like this: Message-ID: It seems interesting but I don't know what they are for. I have searched through internet and the best advice was to disable digest mode if you intend to reply. Is that the only option? On a side note, digest mode doesn't work like I expected either. I was thinking of having a collection of emails at the end of the day but I usually get multiple digests per day. There seems to be an upper limit of 6 per digest so my first thought was that it sends the digest if the buffer is full but I also get digests with fewer emails like 1 or 2. (Note: I'm using gmail if that matters) Thanks, Gokcehan -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelwoerister at posteo.de Thu Dec 5 06:08:10 2013 From: michaelwoerister at posteo.de (Michael Woerister) Date: Thu, 05 Dec 2013 15:08:10 +0100 Subject: [rust-dev] Persistent data structures In-Reply-To: References: <529ED9A4.4080901@isaac.cedarswampstudios.org>, , <529FA1DB.9030000@isaac.cedarswampstudios.org> Message-ID: <52A088CA.1020902@posteo.de> On 05.12.2013 03:15, Bill Myers wrote: > The reason I introduced COW when RC > 1 is that it allows persistent > data structures to be mutated in place if there aren't extra > references, just like non-persistent data structures. That's a great idea that an might obviate the need to have a separate `Builder` type (as in .Net [1]) or explicit `transients` (as in Clojure [2]). However, one has to be careful to "lock" the whole path when working in a graph structure in a concurrent setting, so no other task/thread changes a node further up, while the first task does changes to the some node further down. This can happen, when relying on the reference count alone because there can be N Arc-references + M borrowed references to some memory box---and the reference count will only be N. Conceptually, the `get()` method in Arc also should increase the reference count for the lifetime of the borrowed reference. For safe memory management, this is not necessary because the compiler will ensure that no borrowed reference outlives all memory owners, but for counting who has access to the memory contents, the reference count alone is inadequate. This should not be hard to mitigate manually but it's a potential source for some nasty race conditions ;) -Michael [1] https://msdn.microsoft.com/en-us/library/dn385366(v=vs.110).aspx [2] http://clojure.org/transients -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Thu Dec 5 07:43:46 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Thu, 5 Dec 2013 16:43:46 +0100 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: References: Message-ID: In a similar vein, see this list of complaints against Scala by Edward Kmett, possibly the most brilliant and prolific Haskell programmer on Earth: http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu I'll try to comment with my understanding of where Rust stands on each point: > - > > If you take any two of the random extensions that have been thrown > into scala and try to use them together, they typically don't play nice. > e.g. Implicits and subtyping don't play nice together. > > We have to stay careful, but I think the various parts of Rust's type system fit together amazingly well right now. > - > > Type inference works right up until you write anything that needs it. > If you go to write any sort of tricky recursive function, you know, where > inference would be useful, then it stops working. > > Not completely sure about this, but hopeful. Can anyone else make a better-informed comment? > > - > > Due to type erasure, its easy to refine a type in a case expression / > pattern match to get something that is a lie. > > I don't think Rust has this problem. > > - > > Free theorems aren't. > > This is referring to the idea that if type variables are completely opaque to a generic function parameterized over them, then you can formulate some equational theorems for the function "for free", which you know will always be true, because they can't not be. For example, for the Haskell function fmap :: forall a b. (a -> b) -> (f a -> fb): fmap f . fmap g = fmap (f . g) fmap id = id Due to unrestricted (non-mutation) side effects Rust flunks this, but it would be nice if, for functions which can be assumed to be pure, it didn't. For that we have to be vigilant about never allowing things like dynamic_cast or various built-in intrinsics on completely generic types, at least outside of unsafe code. This seems more hopeful, but Rust still flunks it right now: because of, for one instance, size_of::(). I'm not sure whether there are other instances. It would be nice if this could be addressed. > - > > Since you can pass any dictionary anywhere to any implicit you can't > rely on the canonicity of anything. If you make a Map or Set using an > ordering, you can't be sure you'll get the same ordering back when you come > to do a lookup later. This means you can't safely do hedge unions/merges in > their containers. It also means that much of scalaz is lying to itself and > hoping you'll pass back the same dictionary every time. > > Rust smartly avoids this problem. > > - > > The container types they do have have weird ad hoc overloadings. e.g. > Map is treated as an iterable container of pairs, but this means you can't > write code that is parametric in the Traversable container type that can do > anything sensible. It is one of those solutions that seems like it might be > a nice idea unless you've had experience programming with more principled > classes like Foldable/Traversable. > > Not quite sure what sort of overloadings this is referring to, but if/when we add an Iterable trait, this means that perhaps the impl for maps should iterate only over values, rather than key-value pairs, so that it makes more sense to use the same generic code for both e.g. maps and arrays. (Of course a (key, value) iterator should still be provided separately.) When we gain higher-kinded types, we should also be able to add the actual Foldable and Traversable traits themselves. > > - > > You wind up with code that looks like myMap.map(...).toMap all over > the place due to CanBuildFrom inference woes. > > No idea what this is about. > > - > > Monads have to pay for an extra map at the end of any comprehension, > because of the way the for { } sugar works. > > We have neither monads nor sugar at the moment, but if we ever do (not quite as crazy as it sounds, given that C# also has a version of it in LINQ), we should presumably try to remember this problem and avoid it. > > - > > You have type lambdas. Yay, right? But now you can't just talk about Functor > (StateT s IO). Its Functor[({type F[X] = StateT[S,IO,X]})#F], and you > have to hand plumb it to something like return, because it basically > can't infer any of that, once you start dealing with transformers ever. The > instance isn't directly in scope. 12.pure[({type F[X] = > StateT[S,IO,X]})#F] isn't terribly concise. It can't figure out it > should use the inference rule to define the implicit for StateT[S,M,_]from the one for > M[_] because of the increased flexibility that nobody uses. > > Rust doesn't have type lambdas and almost certainly never will. > > - > > In this mindset and in the same vein as the CanBuildFrom issue, things > like Either don't have the biased flatMap you'd expect, somehow > encouraging you to use other tools, just in case you wanted to bind on the > Left. So you don't write generic monadic code over the Either monad, > but rather are constantly chaining foo.right.flatMap(... > .right.flatMap(....)) ensuring you can't use the sugar without turning > to something like scalaz to fill it in. Basically almost the entire > original motivation for all the type lambda craziness came down to being > able to write classes like Functor have have several instances for > different arguments, but because they are so hard to use nobody does it, > making the feature hardly pay its way, as it makes things like unification, > and path dependent type checking harder and sometimes impossible, but the > language specification requires them to do it! > > See above. > - > > You don't have any notion of a kind system and can only talk about > fully saturated types, monad transformers are hell to write. It is easier > for me to use the fact that every Comonad gives rise to a monad > transformer to intuitively describe how to manually plumb a semimonoidal > Comonad through my parser to carry extra state than to work with a > monad transformer! > > Rust doesn't have a kind system either, but hopefully it will! > > - > > I've been able to get the compiler to build classes that it thinks are > fully instantiated, but which still have abstract methods in them. > > I don't believe Rust has this problem. > > - > > Tail-call optimization is only performed for self-tail calls, where > you do not do polymorphic recursion. > > Rust is a little bit better here (LLVM does "sibling call" optimization, which is somewhat more general than just self calls), but not by much. > - > > Monads are toys due to the aforementioned restriction. (>>=) is called > flatMap. Any chain of monadic binds is going to be a series of > non-self tailcalls. A function calls flatMap which calls a function, which > calls flatMap... This means that non-trivial operations in even the > identity monad, like using a Haskell style traverse for a monad over > an arbitrary container blows the stack after a few thousand entries. > > Rust is not any better on this front. While we still had segmented stacks we could've handled this, if not in constant space but at least on the stack, but we no longer do. I'm wondering whether the fact that we're going to have moves and drops statically tracked by the compiler might make it more realistic to think about TCE again. I think the biggest remaining obstacle would be the calling convention. > > - > > We can fix this, and have in scalaz by adapting apfelmus' operational > monad to get a trampoline that moves us off the stack to the heap, hiding > the problem, but at a 50x slowdown, as the JIT no longer knows how to help. > - > > We can also fix it by passing imperative state around, and maybe > getting scala to pass the state for me using implicits and hoping I don't > accidentally use a lazy val. Guess which one is the only viable > solution I know at scale? The code winds up less than 1/2 the size and 3x > faster than the identity monad version. If scala was the only language I > had to think in, I'd think functional programming was a bad idea that > didn't scale, too. > - > > for yield sugar is a very simple expansion, but that means it has all > sorts of rules about what you can't define locally inside of it, e.g. you > can't stop and def a function, lazy val, etc. without nesting another > for yield block. > > Not sure what this is about, but if we ever add a `yield` construct we should presumably try to take this into consideration. > - > > You wind up with issues like SI-3295where out of a desire to not "confuse the computation model", it was > decided that it was better to you know, just crash when someone folded a > reasonably large list than fix the issue.. until it finally affected > scalac itself. I've been told this has been relatively recently fixed. > - > > No first-class universal quantification means that quantifier tricks > like ST s, or automatic differentiation without infinitesimal > confusion are basically impossible. > > def test = diff(new FF[Id,Id,Double] { > def apply[S[_]](x: AD[S, Double])(implicit mode: Mode[S, Double]): AD[S, Double] > = cos(x) > }) > > is a poor substitute for > > test = diff cos > > > Rust doesn't have this right now either, but in part of my earlier "Type system thoughts" e-mail I was thinking about how it could potentially be added. > ... but it runs on the JVM. > Rust doesn't have this excuse. :-) On Thu, Dec 5, 2013 at 2:07 AM, Ziad Hatahet wrote: > To be taken with a grain of salt, naturally: > https://www.youtube.com/watch?v=TS1lpKBMkgg > > > -- > Ziad > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill_myers at outlook.com Thu Dec 5 07:59:08 2013 From: bill_myers at outlook.com (Bill Myers) Date: Thu, 5 Dec 2013 15:59:08 +0000 Subject: [rust-dev] Persistent data structures In-Reply-To: <52A088CA.1020902@posteo.de> References: <529ED9A4.4080901@isaac.cedarswampstudios.org>, , , , <529FA1DB.9030000@isaac.cedarswampstudios.org>, , <52A088CA.1020902@posteo.de> Message-ID: No, the problem you describe does not exist in my implementation because it requires an &mut to the smart pointer. In particular, if the reference count is 1, then there is no other Rc and Arc pointing to the same data, and because we have an &mut there is also no other borrowed reference to the Rc or Arc we are manipulating. Hence, if the reference count is 1 and we have an &mut to the Rc or Arc, it's safe to return an &mut pointing to the contents and thus mutate its contents in place using it. If the reference count is more than 1, then it uses read-only access to clone the contents, giving a new allocation with reference count 1 that can then be mutated in place as above. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Dec 5 08:07:32 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 5 Dec 2013 11:07:32 -0500 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: References: Message-ID: On Thu, Dec 5, 2013 at 10:43 AM, G?bor Lehel wrote: > >> Free theorems aren't. > > > This is referring to the idea that if type variables are completely opaque > to a generic function parameterized over them, then you can formulate some > equational theorems for the function "for free", which you know will always > be true, because they can't not be. For example, for the Haskell function > fmap :: forall a b. (a -> b) -> (f a -> fb): > > fmap f . fmap g = fmap (f . g) > fmap id = id > > Due to unrestricted (non-mutation) side effects Rust flunks this, but it > would be nice if, for functions which can be assumed to be pure, it didn't. > For that we have to be vigilant about never allowing things like > dynamic_cast or various built-in intrinsics on completely generic types, at > least outside of unsafe code. This seems more hopeful, but Rust still flunks > it right now: because of, for one instance, size_of::(). I'm not sure > whether there are other instances. It would be nice if this could be > addressed. There are worse cases than `size_of` like `type_id`, `get_tydesc` and `visit_tydesc`. The `visit_tydesc` intrinsic is by far the worst since it allows walking the entire type, even cross-crate private fields. This is used by `std::repr` for "%?" in format strings. >> The container types they do have have weird ad hoc overloadings. e.g. Map >> is treated as an iterable container of pairs, but this means you can't write >> code that is parametric in the Traversable container type that can do >> anything sensible. It is one of those solutions that seems like it might be >> a nice idea unless you've had experience programming with more principled >> classes like Foldable/Traversable. > > Not quite sure what sort of overloadings this is referring to, but if/when > we add an Iterable trait, this means that perhaps the impl for maps should > iterate only over values, rather than key-value pairs, so that it makes more > sense to use the same generic code for both e.g. maps and arrays. (Of course > a (key, value) iterator should still be provided separately.) > > When we gain higher-kinded types, we should also be able to add the actual > Foldable and Traversable traits themselves. I think it makes sense to treat a map as a sequence of tuples. There is a corresponding array type and you can always extract only the keys or only the values with `map`. I expect there isn't going to be an `Iterable` type for a while though. There's not a single obvious way to implement it. >> You wind up with code that looks like myMap.map(...).toMap all over the >> place due to CanBuildFrom inference woes. > > No idea what this is about. I think this is similar to `collect` in Rust, where a container type needs to be provided and usually can't be inferred. I'm not sure how it could be done differently. >> Tail-call optimization is only performed for self-tail calls, where you do >> not do polymorphic recursion. > > Rust is a little bit better here (LLVM does "sibling call" optimization, > which is somewhat more general than just self calls), but not by much. It's worse too, because you have to understand the obscure rules used by LLVM, it only works for internal functions unless you use link-time optimization and doesn't happen at all for non-optimized builds. An example of those obscure rules is a function returning a large value (returned via an out pointer) not ever being a candidate for tail call elimination on most architectures. You also have to understand which cases Rust will use an out pointer for, and that's likely to keep changing. >> Monads are toys due to the aforementioned restriction. (>>=) is called >> flatMap. Any chain of monadic binds is going to be a series of non-self >> tailcalls. A function calls flatMap which calls a function, which calls >> flatMap... This means that non-trivial operations in even the identity >> monad, like using a Haskell style traverse for a monad over an arbitrary >> container blows the stack after a few thousand entries. > > Rust is not any better on this front. While we still had segmented stacks we > could've handled this, if not in constant space but at least on the stack, > but we no longer do. > > I'm wondering whether the fact that we're going to have moves and drops > statically tracked by the compiler might make it more realistic to think > about TCE again. I think the biggest remaining obstacle would be the calling > convention. I don't think it's a good idea to add any frontend support for tail-call elimination. It's not something that's ever going to be acceptable with optimizations disabled because it drastically changes debugging. >> We can fix this, and have in scalaz by adapting apfelmus' operational >> monad to get a trampoline that moves us off the stack to the heap, hiding >> the problem, but at a 50x slowdown, as the JIT no longer knows how to help. >> >> We can also fix it by passing imperative state around, and maybe getting >> scala to pass the state for me using implicits and hoping I don't >> accidentally use a lazy val. Guess which one is the only viable solution I >> know at scale? The code winds up less than 1/2 the size and 3x faster than >> the identity monad version. If scala was the only language I had to think >> in, I'd think functional programming was a bad idea that didn't scale, too. >> >> for yield sugar is a very simple expansion, but that means it has all >> sorts of rules about what you can't define locally inside of it, e.g. you >> can't stop and def a function, lazy val, etc. without nesting another for >> yield block. > > Not sure what this is about, but if we ever add a `yield` construct we > should presumably try to take this into consideration. If we have `yield` sugar, it's going to be more restrictive than a regular function in order to maintain memory safety. Move semantics are very relevant here. From comexk at gmail.com Thu Dec 5 09:58:37 2013 From: comexk at gmail.com (comex) Date: Thu, 5 Dec 2013 12:58:37 -0500 Subject: [rust-dev] How to reply properly in digest mode? In-Reply-To: References: Message-ID: On Thu, Dec 5, 2013 at 8:20 AM, Gokcehan Kara wrote: > It seems interesting but I don't know what they are for. I have searched > through internet and the best advice was to disable digest mode if you > intend to reply. Is that the only option? If you ask Gmail to filter messages to the list into their own label, there's not really much advantage to using a digest (which is an inferior reading experience) rather than just periodically checking the label. HTH. From bill_myers at outlook.com Thu Dec 5 10:04:19 2013 From: bill_myers at outlook.com (Bill Myers) Date: Thu, 5 Dec 2013 18:04:19 +0000 Subject: [rust-dev] How to reply properly in digest mode? In-Reply-To: References: Message-ID: Never use digest mode. Instead, use normal mode and if necessary add a filter in your e-mail website or application to separate all mailing list messages in a specific folder or label. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokcehankara at gmail.com Thu Dec 5 10:19:19 2013 From: gokcehankara at gmail.com (Gokcehan Kara) Date: Thu, 5 Dec 2013 20:19:19 +0200 Subject: [rust-dev] How to reply properly in digest mode? In-Reply-To: References: Message-ID: I have turned of digest mode and did the label thing and it seems alright, thanks.. On Thu, Dec 5, 2013 at 8:04 PM, Bill Myers wrote: > Never use digest mode. > > Instead, use normal mode and if necessary add a filter in your e-mail > website or application to separate all mailing list messages in a specific > folder or label. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From illissius at gmail.com Thu Dec 5 12:05:04 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Thu, 5 Dec 2013 21:05:04 +0100 Subject: [rust-dev] Interesting talk about (scala) language/compiler complexity In-Reply-To: References: Message-ID: On Thu, Dec 5, 2013 at 5:07 PM, Daniel Micay wrote: > On Thu, Dec 5, 2013 at 10:43 AM, G?bor Lehel wrote: > >> The container types they do have have weird ad hoc overloadings. e.g. Map > >> is treated as an iterable container of pairs, but this means you can't > write > >> code that is parametric in the Traversable container type that can do > >> anything sensible. It is one of those solutions that seems like it > might be > >> a nice idea unless you've had experience programming with more > principled > >> classes like Foldable/Traversable. > > > > Not quite sure what sort of overloadings this is referring to, but > if/when > > we add an Iterable trait, this means that perhaps the impl for maps > should > > iterate only over values, rather than key-value pairs, so that it makes > more > > sense to use the same generic code for both e.g. maps and arrays. (Of > course > > a (key, value) iterator should still be provided separately.) > > > > When we gain higher-kinded types, we should also be able to add the > actual > > Foldable and Traversable traits themselves. > > I think it makes sense to treat a map as a sequence of tuples. When iterating over a map, sure thing. When writing generic code over any kind of container, not so sure. In that case a `Map` can be viewed as V values indexed over K keys, while `[T]` can be viewed as T values indexed over `uint` keys -- and so perhaps there should be a separate `IterableWithKey` trait for this kind of thing, where arrays would also be iterated as (index, value) pairs. That said, maybe you wouldn't ever want to write generic code over `Iterable`, only `Iterator`, and so this concern wouldn't actually end up applying. > > >> You wind up with code that looks like myMap.map(...).toMap all over the > >> place due to CanBuildFrom inference woes. > > > > No idea what this is about. > > I think this is similar to `collect` in Rust, where a container type > needs to be provided and usually can't be inferred. I'm not sure how > it could be done differently. > Hmm. Seems like the sort of thing that HKT might help with. > > >> Monads are toys due to the aforementioned restriction. (>>=) is called > >> flatMap. Any chain of monadic binds is going to be a series of non-self > >> tailcalls. A function calls flatMap which calls a function, which calls > >> flatMap... This means that non-trivial operations in even the identity > >> monad, like using a Haskell style traverse for a monad over an arbitrary > >> container blows the stack after a few thousand entries. > > > > Rust is not any better on this front. While we still had segmented > stacks we > > could've handled this, if not in constant space but at least on the > stack, > > but we no longer do. > > > > I'm wondering whether the fact that we're going to have moves and drops > > statically tracked by the compiler might make it more realistic to think > > about TCE again. I think the biggest remaining obstacle would be the > calling > > convention. > > I don't think it's a good idea to add any frontend support for > tail-call elimination. It's not something that's ever going to be > acceptable with optimizations disabled because it drastically changes > debugging. > That seems like something the programmer would be in a good position to make an informed choice about. The other obstacles seem more significant than this one. (I'm assuming that *if* we ever add TCE, it would be have to be invoked explicitly (there's currently the `be` keyword reserved for this, which seems a bit strange, but not as if I have a better idea). So it's not like the compiler would always unconditionally eliminate tail calls and the unsuspecting programmer would be foiled in her debugging. She would be able to pick her poison.) -- Your ship was destroyed in a monadic eruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.delrieu at free.fr Thu Dec 5 12:26:14 2013 From: philippe.delrieu at free.fr (Philippe Delrieu) Date: Thu, 05 Dec 2013 21:26:14 +0100 Subject: [rust-dev] new compile errors in the master since a few days In-Reply-To: <52A04D1F.3040102@free.fr> References: <52A03CC5.7070500@free.fr> <52A04D1F.3040102@free.fr> Message-ID: <52A0E166.9060207@free.fr> I found my error. It's a classical problem. TestStruct2 implement the trait `extra::serialize::Encodable` using the generated impl by the compiler. I didn't declare : use extra::serialize::Encodable; So the compiler doesn't find it and declare the problem at the implementation. It's the same problem when you work with different file and the trait is implemented in one file and use in another. Usually I found the error but I was confused with other errors and the message wasn't clear. Is it possible to change the message by for example in this case trait `extra::serialize::Encodable` not found for encode, or to add all `use` needed when using a type and its implementation. Philippe Le 05/12/2013 10:53, Philippe Delrieu a ?crit : > Thank you it correct my first problems. > > I didn't send code because I thought it has the same cause. For the > last problems the code is : > > use extra::serialize; > use extra::json::{Json, Decoder, ToJson, Object, Encoder, Decoder}; > use extra::treemap::TreeMap; > use std::io::Decorator; > > //second struct with manually implemented Decodable, Encodable > #[deriving(Decodable, Encodable, Eq)] > pub struct TestStruct2 { > dataInt: u8, > dataStr:~str, > dataArray:~[u8], > } > > let test3 : TestStruct2 = TestStruct2 {dataInt: 1, > dataStr:~"toto", dataArray:~[2,3,4,5]}; > //{\"dataArray\":[2,3,4,5],\"dataInt\":1,\"dataStr\":\"toto\"} > let mut m3 = MemWriter::new(); > { > let mut encoder3 =Encoder::init(&mut m3 as &mut Writer); > test3.encode(&mut encoder3); > } > > Rustc result : > test_json.rs:292:8: 292:36 error: type `TestStruct2` does not > implement any method in scope named `encode` > test/test_json.rs:292 test3.encode(&mut encoder3); > > Philippe > > > > Le 05/12/2013 09:56, Kevin Ballard a ?crit : >> `do` no longer works with stack closures. It now only works with the >> new proc() type, which basically means you're only going to see it >> used with spawn(). >> >> You need to now say something like >> >> let rc = endpoint.with_c_str(|cstr| { >> unsafe {smq_bind(self.sock, cstr)} >> }); >> >> I can't speculate on your encode error without seeing it. >> >> -Kevin >> >> On Dec 5, 2013, at 12:43 AM, Philippe Delrieu >> wrote: >> >>> Hello, >>> >>> since a few days, I have a lot of new errors in the master compiler. >>> For example in the rust_zmq lib that I use. When I compile it I have >>> these errors : >>> 321:9 error: last argument in `do` call has non-procedure type: >>> |*i8| -> >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319 >>> let rc = do endpoint.with_c_str |cstr| { >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320 >>> unsafe {zmq_bind(self.sock, cstr)} >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321 >>> }; >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29: >>> 330:9 error: last argument in `do` call has non-procedure type: >>> |*i8| -> >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328 >>> let rc = do endpoint.with_c_str |cstr| { >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329 >>> unsafe {zmq_connect(self.sock, cstr)} >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330 >>> }; >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16: >>> 352:9 error: last argument in `do` call has non-procedure type: >>> |*u8, uint| -> >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337 >>> do data.as_imm_buf |base_ptr, len| { >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338 >>> let msg = [0, ..32]; >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339 >>> >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340 >>> unsafe { >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341 >>> // Copy the data into the message. >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 >>> zmq_msg_init_size(&msg, len as size_t); >>> ... >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40: >>> 342:43 error: the type of this value must be known in this context >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 >>> zmq_msg_init_size(&msg, len as size_t); >>> ^~~ >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344:16: >>> 344:32 error: cannot determine a type for this bounded type >>> parameter: unconstrained type >>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344 >>> ptr::copy_memory(::cast::transmute(zmq_msg_data(&msg)), base_ptr, len); >>> ^~~~~~~~~~~~~~~~ >>> I have the same type of errors in my code plus other error when the >>> trait can't be found like type `MyType` does not implement any >>> method in scope named `encode` and the function is implemented just >>> above. >>> This code where compiling last week. >>> >>> Philippe Delrieu >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > From corey at octayn.net Thu Dec 5 12:57:39 2013 From: corey at octayn.net (Corey Richardson) Date: Thu, 5 Dec 2013 15:57:39 -0500 Subject: [rust-dev] new compile errors in the master since a few days In-Reply-To: <52A0E166.9060207@free.fr> References: <52A03CC5.7070500@free.fr> <52A04D1F.3040102@free.fr> <52A0E166.9060207@free.fr> Message-ID: No, since it isn't known which trait the method should come from. It could list *all* the traits that provide that method with that signature, but even that wouldn't be great if you had the signature off. On Thu, Dec 5, 2013 at 3:26 PM, Philippe Delrieu wrote: > I found my error. It's a classical problem. > TestStruct2 implement the trait `extra::serialize::Encodable` using the > generated impl by the compiler. > I didn't declare : use extra::serialize::Encodable; > So the compiler doesn't find it and declare the problem at the > implementation. > It's the same problem when you work with different file and the trait is > implemented in one file and use in another. > Usually I found the error but I was confused with other errors and the > message wasn't clear. > Is it possible to change the message by for example in this case trait > `extra::serialize::Encodable` not found for encode, > or to add all `use` needed when using a type and its implementation. > > Philippe > > Le 05/12/2013 10:53, Philippe Delrieu a ?crit : > >> Thank you it correct my first problems. >> >> I didn't send code because I thought it has the same cause. For the last >> problems the code is : >> >> use extra::serialize; >> use extra::json::{Json, Decoder, ToJson, Object, Encoder, Decoder}; >> use extra::treemap::TreeMap; >> use std::io::Decorator; >> >> //second struct with manually implemented Decodable, Encodable >> #[deriving(Decodable, Encodable, Eq)] >> pub struct TestStruct2 { >> dataInt: u8, >> dataStr:~str, >> dataArray:~[u8], >> } >> >> let test3 : TestStruct2 = TestStruct2 {dataInt: 1, dataStr:~"toto", >> dataArray:~[2,3,4,5]}; >> //{\"dataArray\":[2,3,4,5],\"dataInt\":1,\"dataStr\":\"toto\"} >> let mut m3 = MemWriter::new(); >> { >> let mut encoder3 =Encoder::init(&mut m3 as &mut Writer); >> test3.encode(&mut encoder3); >> } >> >> Rustc result : >> test_json.rs:292:8: 292:36 error: type `TestStruct2` does not implement >> any method in scope named `encode` >> test/test_json.rs:292 test3.encode(&mut encoder3); >> >> Philippe >> >> >> >> Le 05/12/2013 09:56, Kevin Ballard a ?crit : >>> >>> `do` no longer works with stack closures. It now only works with the new >>> proc() type, which basically means you're only going to see it used with >>> spawn(). >>> >>> You need to now say something like >>> >>> let rc = endpoint.with_c_str(|cstr| { >>> unsafe {smq_bind(self.sock, cstr)} >>> }); >>> >>> I can't speculate on your encode error without seeing it. >>> >>> -Kevin >>> >>> On Dec 5, 2013, at 12:43 AM, Philippe Delrieu >>> wrote: >>> >>>> Hello, >>>> >>>> since a few days, I have a lot of new errors in the master compiler. For >>>> example in the rust_zmq lib that I use. When I compile it I have these >>>> errors : >>>> 321:9 error: last argument in `do` call has non-procedure type: |*i8| -> >>>> >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319 >>>> let rc = do endpoint.with_c_str |cstr| { >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320 >>>> unsafe {zmq_bind(self.sock, cstr)} >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321 >>>> }; >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29: >>>> 330:9 error: last argument in `do` call has non-procedure type: |*i8| -> >>>> >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328 >>>> let rc = do endpoint.with_c_str |cstr| { >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329 >>>> unsafe {zmq_connect(self.sock, cstr)} >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330 >>>> }; >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16: >>>> 352:9 error: last argument in `do` call has non-procedure type: |*u8, uint| >>>> -> >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337 >>>> do data.as_imm_buf |base_ptr, len| { >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338 >>>> let msg = [0, ..32]; >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339 >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340 >>>> unsafe { >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341 >>>> // Copy the data into the message. >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 >>>> zmq_msg_init_size(&msg, len as size_t); >>>> ... >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40: >>>> 342:43 error: the type of this value must be known in this context >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 >>>> zmq_msg_init_size(&msg, len as size_t); >>>> ^~~ >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344:16: >>>> 344:32 error: cannot determine a type for this bounded type parameter: >>>> unconstrained type >>>> >>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344 >>>> ptr::copy_memory(::cast::transmute(zmq_msg_data(&msg)), base_ptr, len); >>>> ^~~~~~~~~~~~~~~~ >>>> I have the same type of errors in my code plus other error when the >>>> trait can't be found like type `MyType` does not implement any method in >>>> scope named `encode` and the function is implemented just above. >>>> This code where compiling last week. >>>> >>>> Philippe Delrieu >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From philippe.delrieu at free.fr Thu Dec 5 13:29:59 2013 From: philippe.delrieu at free.fr (Philippe Delrieu) Date: Thu, 05 Dec 2013 22:29:59 +0100 Subject: [rust-dev] new compile errors in the master since a few days In-Reply-To: References: <52A03CC5.7070500@free.fr> <52A04D1F.3040102@free.fr> <52A0E166.9060207@free.fr> Message-ID: <52A0F057.8090109@free.fr> Perhaps the error message can be more explicit like trait not found for method instead of method not found. Le 05/12/2013 21:57, Corey Richardson a ?crit : > No, since it isn't known which trait the method should come from. It > could list *all* the traits that provide that method with that > signature, but even that wouldn't be great if you had the signature > off. > > On Thu, Dec 5, 2013 at 3:26 PM, Philippe Delrieu > wrote: >> I found my error. It's a classical problem. >> TestStruct2 implement the trait `extra::serialize::Encodable` using the >> generated impl by the compiler. >> I didn't declare : use extra::serialize::Encodable; >> So the compiler doesn't find it and declare the problem at the >> implementation. >> It's the same problem when you work with different file and the trait is >> implemented in one file and use in another. >> Usually I found the error but I was confused with other errors and the >> message wasn't clear. >> Is it possible to change the message by for example in this case trait >> `extra::serialize::Encodable` not found for encode, >> or to add all `use` needed when using a type and its implementation. >> >> Philippe >> >> Le 05/12/2013 10:53, Philippe Delrieu a ?crit : >> >>> Thank you it correct my first problems. >>> >>> I didn't send code because I thought it has the same cause. For the last >>> problems the code is : >>> >>> use extra::serialize; >>> use extra::json::{Json, Decoder, ToJson, Object, Encoder, Decoder}; >>> use extra::treemap::TreeMap; >>> use std::io::Decorator; >>> >>> //second struct with manually implemented Decodable, Encodable >>> #[deriving(Decodable, Encodable, Eq)] >>> pub struct TestStruct2 { >>> dataInt: u8, >>> dataStr:~str, >>> dataArray:~[u8], >>> } >>> >>> let test3 : TestStruct2 = TestStruct2 {dataInt: 1, dataStr:~"toto", >>> dataArray:~[2,3,4,5]}; >>> //{\"dataArray\":[2,3,4,5],\"dataInt\":1,\"dataStr\":\"toto\"} >>> let mut m3 = MemWriter::new(); >>> { >>> let mut encoder3 =Encoder::init(&mut m3 as &mut Writer); >>> test3.encode(&mut encoder3); >>> } >>> >>> Rustc result : >>> test_json.rs:292:8: 292:36 error: type `TestStruct2` does not implement >>> any method in scope named `encode` >>> test/test_json.rs:292 test3.encode(&mut encoder3); >>> >>> Philippe >>> >>> >>> >>> Le 05/12/2013 09:56, Kevin Ballard a ?crit : >>>> `do` no longer works with stack closures. It now only works with the new >>>> proc() type, which basically means you're only going to see it used with >>>> spawn(). >>>> >>>> You need to now say something like >>>> >>>> let rc = endpoint.with_c_str(|cstr| { >>>> unsafe {smq_bind(self.sock, cstr)} >>>> }); >>>> >>>> I can't speculate on your encode error without seeing it. >>>> >>>> -Kevin >>>> >>>> On Dec 5, 2013, at 12:43 AM, Philippe Delrieu >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> since a few days, I have a lot of new errors in the master compiler. For >>>>> example in the rust_zmq lib that I use. When I compile it I have these >>>>> errors : >>>>> 321:9 error: last argument in `do` call has non-procedure type: |*i8| -> >>>>> >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319 >>>>> let rc = do endpoint.with_c_str |cstr| { >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320 >>>>> unsafe {zmq_bind(self.sock, cstr)} >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321 >>>>> }; >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29: >>>>> 330:9 error: last argument in `do` call has non-procedure type: |*i8| -> >>>>> >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328 >>>>> let rc = do endpoint.with_c_str |cstr| { >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329 >>>>> unsafe {zmq_connect(self.sock, cstr)} >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330 >>>>> }; >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16: >>>>> 352:9 error: last argument in `do` call has non-procedure type: |*u8, uint| >>>>> -> >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337 >>>>> do data.as_imm_buf |base_ptr, len| { >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338 >>>>> let msg = [0, ..32]; >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339 >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340 >>>>> unsafe { >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341 >>>>> // Copy the data into the message. >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 >>>>> zmq_msg_init_size(&msg, len as size_t); >>>>> ... >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40: >>>>> 342:43 error: the type of this value must be known in this context >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 >>>>> zmq_msg_init_size(&msg, len as size_t); >>>>> ^~~ >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344:16: >>>>> 344:32 error: cannot determine a type for this bounded type parameter: >>>>> unconstrained type >>>>> >>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344 >>>>> ptr::copy_memory(::cast::transmute(zmq_msg_data(&msg)), base_ptr, len); >>>>> ^~~~~~~~~~~~~~~~ >>>>> I have the same type of errors in my code plus other error when the >>>>> trait can't be found like type `MyType` does not implement any method in >>>>> scope named `encode` and the function is implemented just above. >>>>> This code where compiling last week. >>>>> >>>>> Philippe Delrieu >>>>> >>>>> _______________________________________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > From michaelwoerister at posteo.de Thu Dec 5 13:45:20 2013 From: michaelwoerister at posteo.de (Michael Woerister) Date: Thu, 05 Dec 2013 22:45:20 +0100 Subject: [rust-dev] Persistent data structures In-Reply-To: References: <529ED9A4.4080901@isaac.cedarswampstudios.org>, , , , <529FA1DB.9030000@isaac.cedarswampstudios.org>, , <52A088CA.1020902@posteo.de> Message-ID: <52A0F3F0.30804@posteo.de> On 05.12.2013 16:59, Bill Myers wrote: > No, the problem you describe does not exist in my implementation > because it requires an &mut to the smart pointer. You are right. I needed some time to wrap my head around this :) This is really a very clever approach! I'm looking forward to experimenting with it in my HAMT implementation. -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Thu Dec 5 13:50:06 2013 From: corey at octayn.net (Corey Richardson) Date: Thu, 5 Dec 2013 16:50:06 -0500 Subject: [rust-dev] new compile errors in the master since a few days In-Reply-To: <52A0F057.8090109@free.fr> References: <52A03CC5.7070500@free.fr> <52A04D1F.3040102@free.fr> <52A0E166.9060207@free.fr> <52A0F057.8090109@free.fr> Message-ID: How about "method `foo` no found and no trait in scope provided one" ? On Thu, Dec 5, 2013 at 4:29 PM, Philippe Delrieu wrote: > Perhaps the error message can be more explicit like trait not found for > method instead of method not found. > > > Le 05/12/2013 21:57, Corey Richardson a ?crit : > >> No, since it isn't known which trait the method should come from. It >> could list *all* the traits that provide that method with that >> signature, but even that wouldn't be great if you had the signature >> off. >> >> On Thu, Dec 5, 2013 at 3:26 PM, Philippe Delrieu >> wrote: >>> >>> I found my error. It's a classical problem. >>> TestStruct2 implement the trait `extra::serialize::Encodable` using the >>> generated impl by the compiler. >>> I didn't declare : use extra::serialize::Encodable; >>> So the compiler doesn't find it and declare the problem at the >>> implementation. >>> It's the same problem when you work with different file and the trait is >>> implemented in one file and use in another. >>> Usually I found the error but I was confused with other errors and the >>> message wasn't clear. >>> Is it possible to change the message by for example in this case trait >>> `extra::serialize::Encodable` not found for encode, >>> or to add all `use` needed when using a type and its implementation. >>> >>> Philippe >>> >>> Le 05/12/2013 10:53, Philippe Delrieu a ?crit : >>> >>>> Thank you it correct my first problems. >>>> >>>> I didn't send code because I thought it has the same cause. For the last >>>> problems the code is : >>>> >>>> use extra::serialize; >>>> use extra::json::{Json, Decoder, ToJson, Object, Encoder, Decoder}; >>>> use extra::treemap::TreeMap; >>>> use std::io::Decorator; >>>> >>>> //second struct with manually implemented Decodable, Encodable >>>> #[deriving(Decodable, Encodable, Eq)] >>>> pub struct TestStruct2 { >>>> dataInt: u8, >>>> dataStr:~str, >>>> dataArray:~[u8], >>>> } >>>> >>>> let test3 : TestStruct2 = TestStruct2 {dataInt: 1, dataStr:~"toto", >>>> dataArray:~[2,3,4,5]}; >>>> //{\"dataArray\":[2,3,4,5],\"dataInt\":1,\"dataStr\":\"toto\"} >>>> let mut m3 = MemWriter::new(); >>>> { >>>> let mut encoder3 =Encoder::init(&mut m3 as &mut Writer); >>>> test3.encode(&mut encoder3); >>>> } >>>> >>>> Rustc result : >>>> test_json.rs:292:8: 292:36 error: type `TestStruct2` does not implement >>>> any method in scope named `encode` >>>> test/test_json.rs:292 test3.encode(&mut encoder3); >>>> >>>> Philippe >>>> >>>> >>>> >>>> Le 05/12/2013 09:56, Kevin Ballard a ?crit : >>>>> >>>>> `do` no longer works with stack closures. It now only works with the >>>>> new >>>>> proc() type, which basically means you're only going to see it used >>>>> with >>>>> spawn(). >>>>> >>>>> You need to now say something like >>>>> >>>>> let rc = endpoint.with_c_str(|cstr| { >>>>> unsafe {smq_bind(self.sock, cstr)} >>>>> }); >>>>> >>>>> I can't speculate on your encode error without seeing it. >>>>> >>>>> -Kevin >>>>> >>>>> On Dec 5, 2013, at 12:43 AM, Philippe Delrieu >>>>> >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> since a few days, I have a lot of new errors in the master compiler. >>>>>> For >>>>>> example in the rust_zmq lib that I use. When I compile it I have these >>>>>> errors : >>>>>> 321:9 error: last argument in `do` call has non-procedure type: |*i8| >>>>>> -> >>>>>> >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319 >>>>>> let rc = do endpoint.with_c_str |cstr| { >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320 >>>>>> unsafe {zmq_bind(self.sock, cstr)} >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321 >>>>>> }; >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29: >>>>>> 330:9 error: last argument in `do` call has non-procedure type: |*i8| >>>>>> -> >>>>>> >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328 >>>>>> let rc = do endpoint.with_c_str |cstr| { >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329 >>>>>> unsafe {zmq_connect(self.sock, cstr)} >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330 >>>>>> }; >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16: >>>>>> 352:9 error: last argument in `do` call has non-procedure type: |*u8, >>>>>> uint| >>>>>> -> >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337 >>>>>> do data.as_imm_buf |base_ptr, len| { >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338 >>>>>> let msg = [0, ..32]; >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339 >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340 >>>>>> unsafe { >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341 >>>>>> // Copy the data into the message. >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 >>>>>> zmq_msg_init_size(&msg, len as size_t); >>>>>> ... >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40: >>>>>> 342:43 error: the type of this value must be known in this context >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342 >>>>>> zmq_msg_init_size(&msg, len as size_t); >>>>>> ^~~ >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344:16: >>>>>> 344:32 error: cannot determine a type for this bounded type parameter: >>>>>> unconstrained type >>>>>> >>>>>> >>>>>> /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344 >>>>>> ptr::copy_memory(::cast::transmute(zmq_msg_data(&msg)), base_ptr, >>>>>> len); >>>>>> ^~~~~~~~~~~~~~~~ >>>>>> I have the same type of errors in my code plus other error when the >>>>>> trait can't be found like type `MyType` does not implement any method >>>>>> in >>>>>> scope named `encode` and the function is implemented just above. >>>>>> This code where compiling last week. >>>>>> >>>>>> Philippe Delrieu >>>>>> >>>>>> _______________________________________________ >>>>>> Rust-dev mailing list >>>>>> Rust-dev at mozilla.org >>>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From erick.tryzelaar at gmail.com Thu Dec 5 19:27:54 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 5 Dec 2013 19:27:54 -0800 Subject: [rust-dev] December 17th San Francisco Bay Area Meetup Message-ID: Good evening Rusties, I'm happy to announce the next Bay Area Rust meetup on December 17th in San Francisco. Mozilla is graciously hosting us again. We've got a couple short talks lined up: ? Luqman Aden will talk about using Rust to make a Minecraft Chat Client . ? Alex Crichton will talk about Channels and their performance. ? Brian Anderson will talk about *something*. ? And if he's able to get it to a presentable state, Kevin Ballard will talk about his safe Lua Bindings. It'll start at 7:00pm and go until 10:00pm. If you would like to attend, please sign up here: http://www.meetup.com/Rust-Bay-Area/events/153010612/ We also might have some room for more other talks, so if you would like to present something at this meetup, or a future one, please let me know. I hope you can make it! -Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Dec 5 19:42:08 2013 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 05 Dec 2013 19:42:08 -0800 Subject: [rust-dev] December 17th San Francisco Bay Area Meetup In-Reply-To: References: Message-ID: <52A14790.2050907@mozilla.com> Thanks for organizing this, Erick! I'm super-excited. The last event was a blast. On 12/05/2013 07:27 PM, Erick Tryzelaar wrote: > Good evening Rusties, > > I'm happy to announce the next Bay Area Rust meetup on December 17th > in San Francisco. Mozilla is graciously hosting us again. We've got a > couple short talks lined up: > > . Luqman Aden will talk about using Rust to make a Minecraft Chat > Client . > > . Alex Crichton will talk about Channels and their performance. > > . Brian Anderson will talk about /something/. > > . And if he's able to get it to a presentable state, Kevin Ballard > will talk about his safe Lua Bindings. > > > It'll start at 7:00pm and go until 10:00pm. If you would like to > attend, please sign up here: > > http://www.meetup.com/Rust-Bay-Area/events/153010612/ > > We also might have some room for more other talks, so if you would > like to present something at this meetup, or a future one, please let > me know. > > I hope you can make it! > -Erick > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Thu Dec 5 20:01:09 2013 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 5 Dec 2013 20:01:09 -0800 Subject: [rust-dev] December 17th San Francisco Bay Area Meetup In-Reply-To: <52A14790.2050907@mozilla.com> References: <52A14790.2050907@mozilla.com> Message-ID: Me too! I love this community. On Thu, Dec 5, 2013 at 7:42 PM, Brian Anderson wrote: > Thanks for organizing this, Erick! I'm super-excited. The last event was > a blast. > > > On 12/05/2013 07:27 PM, Erick Tryzelaar wrote: > > Good evening Rusties, > > I'm happy to announce the next Bay Area Rust meetup on December 17th in > San Francisco. Mozilla is graciously hosting us again. We've got a couple > short talks lined up: > > ? Luqman Aden will talk about using Rust to make a Minecraft Chat Client > . > > ? Alex Crichton will talk about Channels and their performance. > > ? Brian Anderson will talk about *something*. > > ? And if he's able to get it to a presentable state, Kevin Ballard will > talk about his safe Lua Bindings. > > It'll start at 7:00pm and go until 10:00pm. If you would like to attend, > please sign up here: > > http://www.meetup.com/Rust-Bay-Area/events/153010612/ > > We also might have some room for more other talks, so if you would like > to present something at this meetup, or a future one, please let me know. > > I hope you can make it! > -Erick > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.delrieu at free.fr Thu Dec 5 22:44:57 2013 From: philippe.delrieu at free.fr (Philippe Delrieu) Date: Fri, 06 Dec 2013 07:44:57 +0100 Subject: [rust-dev] new compile errors in the master since a few days In-Reply-To: References: <52A03CC5.7070500@free.fr> <52A04D1F.3040102@free.fr> <52A0E166.9060207@free.fr> <52A0F057.8090109@free.fr> Message-ID: <52A17269.2040200@free.fr> I find this message better than the current. It won't mislead me. Le 05/12/2013 22:50, Corey Richardson a ?crit : > How about "method `foo` no found and no trait in scope provided one" ? > > On Thu, Dec 5, 2013 at 4:29 PM, Philippe Delrieu > wrote: >> Perhaps the error message can be more explicit like trait not found for >> method instead of method not found. >> >> >> Le 05/12/2013 21:57, Corey Richardson a ?crit : >> >>> No, since it isn't known which trait the method should come from. It >>> could list *all* the traits that provide that method with that >>> signature, but even that wouldn't be great if you had the signature >>> off. >>> >>> On Thu, Dec 5, 2013 at 3:26 PM, Philippe Delrieu >>> wrote: >>>> I found my error. It's a classical problem. >>>> TestStruct2 implement the trait `extra::serialize::Encodable` using the >>>> generated impl by the compiler. >>>> I didn't declare : use extra::serialize::Encodable; >>>> So the compiler doesn't find it and declare the problem at the >>>> implementation. >>>> It's the same problem when you work with different file and the trait is >>>> implemented in one file and use in another. >>>> Usually I found the error but I was confused with other errors and the >>>> message wasn't clear. >>>> Is it possible to change the message by for example in this case trait >>>> `extra::serialize::Encodable` not found for encode, >>>> or to add all `use` needed when using a type and its implementation. >>>> >>>> Philippe >>>> >>>> From ezyang at mit.edu Fri Dec 6 00:11:08 2013 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 06 Dec 2013 00:11:08 -0800 Subject: [rust-dev] Safely writing iterators over idiomatic C structures Message-ID: <1386315514-sup-3583@sabre> Imagine that we have a structure of the form: typedef struct { int payload1; foo *link; int payload2; } foo; This structure is characterized by two things: 1) It is a singly linked list, and thus has a simple ownership structure which can be captured by Rust's owned pointers 2) The payload of this struct is interleaved with links, in order to save space and an extra indirection. The layout may be fixed, by virtue of being exposed by a C library. The question now is: can we write an Iterator<&mut foo> for the corresponding Rust structure foo, without using any unsafe code? There is a fundamental problem with this structure: iterator invalidation. If we are able to issue a &mut foo reference, then the link field could get mutated. Rust's borrow checker would reject this, since the only possible internal state for the iterator (a mutable reference to the next element) aliases with the mutable reference returned by next(). I am not sure how to solve this without changing the layout of the struct; perhaps there might be a way if one could selectively turn off the mutability of some fields. Suppose we are willing to change the struct, as per the extra::dlist implementation, we still fall short of a safe implementation: the internal state of the iterator utilizes a raw pointer (head), which provides a function resolve() which simply mints a mutable reference to the element in question. It seems to be using Rawlink to hide the fact that it has its fingers on a mutable borrowed reference to the list. It recovers some safety by maintaining a mutable reference to the whole list in the iterator structure as well, but it would be better if no unsafe code was necessary at all, and I certainly don't feel qualified to reason about the correctness of this code. (Though, I understand and appreciate the fact that the back pointers have to be handled unsafely.) So, is it possible? I just want (provably) safe, mutable iteration over singly-linked lists... Edward From dbau.pp at gmail.com Fri Dec 6 00:26:36 2013 From: dbau.pp at gmail.com (Huon Wilson) Date: Fri, 06 Dec 2013 19:26:36 +1100 Subject: [rust-dev] Safely writing iterators over idiomatic C structures In-Reply-To: <1386315514-sup-3583@sabre> References: <1386315514-sup-3583@sabre> Message-ID: <52A18A3C.9060606@gmail.com> On 06/12/13 19:11, Edward Z. Yang wrote: > Imagine that we have a structure of the form: > > typedef struct { > int payload1; > foo *link; > int payload2; > } foo; > > This structure is characterized by two things: > > 1) It is a singly linked list, and thus has a simple ownership > structure which can be captured by Rust's owned pointers > > 2) The payload of this struct is interleaved with links, in > order to save space and an extra indirection. The layout may > be fixed, by virtue of being exposed by a C library. > > The question now is: can we write an Iterator<&mut foo> for > the corresponding Rust structure foo, without using any unsafe code? > > There is a fundamental problem with this structure: iterator > invalidation. If we are able to issue a &mut foo reference, then the > link field could get mutated. Rust's borrow checker would reject this, > since the only possible internal state for the iterator (a mutable > reference to the next element) aliases with the mutable reference > returned by next(). I am not sure how to solve this without changing > the layout of the struct; perhaps there might be a way if one could > selectively turn off the mutability of some fields. > > Suppose we are willing to change the struct, as per the extra::dlist > implementation, we still fall short of a safe implementation: the > internal state of the iterator utilizes a raw pointer (head), which > provides a function resolve() which simply mints a mutable reference to > the element in question. It seems to be using Rawlink to hide the fact > that it has its fingers on a mutable borrowed reference to the list. It > recovers some safety by maintaining a mutable reference to the whole > list in the iterator structure as well, but it would be better if no > unsafe code was necessary at all, and I certainly don't feel qualified > to reason about the correctness of this code. (Though, I understand and > appreciate the fact that the back pointers have to be handled unsafely.) > > So, is it possible? I just want (provably) safe, mutable iteration over > singly-linked lists... > > Edward > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev One could have an Iterator<(&mut int, &mut int)>, where the references point to just the fields. Off the top of my head: struct List { payload1: int, next: Option<~Foo>, payload2: f64 } struct ListMutIterator<'a> { elem: Option<&'a mut List> } impl<'a> Iterator<(&'a mut int, &'a mut f64)> for ListMutIterator<'a> { fn next(&mut self) -> Option<(&'a mut int, &'a mut f64)> { let elem = std::util::replace(self, None); // I think this might be necessary to get around the borrow checker. let (ret, next) = match elem { Some(&List { payload1: ref mut payload1, next: ref mut next, payload2: ref mut payload2 }) => { (Some((payload1, payload2)), next.as_mut_ref()) } None => (None, None) }; *self = next; ret } } (The List pattern match will look nicer if https://github.com/mozilla/rust/issues/6137 gets solved; `List { ref mut payload1, ref mut next, ref mut payload2 }`.) I imagine this will end up being very ugly if there are more than just 2 fields before and after, although one could easily replace the tuple with a struct `ListMutRef<'a> { payload1: &'a mut int, payload2: &'a mut f64 }`. Huon From bill_myers at outlook.com Fri Dec 6 07:50:59 2013 From: bill_myers at outlook.com (Bill Myers) Date: Fri, 6 Dec 2013 15:50:59 +0000 Subject: [rust-dev] Safely writing iterators over idiomatic C structures In-Reply-To: <1386315514-sup-3583@sabre> References: <1386315514-sup-3583@sabre> Message-ID: Maybe the language should be changed to allow Iterator to be changed to have a signature like this: pub trait Iterator { ??? fn next<'a>(&'a mut self) -> Option<'a A>; } Then you could return the &mut by reborrowing and would be able to advance the iterator without issue afterwards. From danielmicay at gmail.com Fri Dec 6 11:15:18 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 6 Dec 2013 14:15:18 -0500 Subject: [rust-dev] Safely writing iterators over idiomatic C structures In-Reply-To: References: <1386315514-sup-3583@sabre> Message-ID: On Fri, Dec 6, 2013 at 10:50 AM, Bill Myers wrote: > Maybe the language should be changed to allow Iterator to be changed to have a signature like this: > pub trait Iterator { > fn next<'a>(&'a mut self) -> Option<'a A>; > } > > Then you could return the &mut by reborrowing and would be able to advance the iterator without issue afterwards. It can't be defined that way without becoming much less useful for more common cases. From simon.sapin at exyr.org Fri Dec 6 12:41:04 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Fri, 06 Dec 2013 20:41:04 +0000 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= Message-ID: <52A23660.5040500@exyr.org> We have some functions and methods such as [std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) that may succeed and give a result, or fail when the input is invalid. 1. Sometimes we assume the input is valid and don?t want to deal with the error case. Task failure works nicely. 2. Sometimes we do want to do something different on invalid input, so returning an `Option` works best. And so we end up with both `from_utf8` and `from_utf8`. This particular case is worse because we also have `from_utf8_owned` and `from_utf8_owned_opt`, to cover everything. Multiplying names like this is just not good design. I?d like to reduce this pattern. Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on the Option. I think we should rename every `foo_opt()` function or method to just `foo`, remove the old `foo()` behavior, and tell people (through documentation) to use `foo().unwrap()` if they want it back? The downsides are that unwrap is more verbose and gives less helpful error messages on task failure. But I think it?s worth it. What do you think? (PS: I?m guilty of making this worse in #10828, but I?d like to discuss this before sending pull requests with invasive API changes.) -- Simon Sapin From corey at octayn.net Fri Dec 6 12:48:22 2013 From: corey at octayn.net (Corey Richardson) Date: Fri, 6 Dec 2013 15:48:22 -0500 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: <52A23660.5040500@exyr.org> References: <52A23660.5040500@exyr.org> Message-ID: I'm in favor of this but it makes things less "pretty". Is the choice really between pretty and fast? On Fri, Dec 6, 2013 at 3:41 PM, Simon Sapin wrote: > We have some functions and methods such as > [std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) > that may succeed and give a result, or fail when the input is invalid. > > 1. Sometimes we assume the input is valid and don?t want to deal with the > error case. Task failure works nicely. > > 2. Sometimes we do want to do something different on invalid input, so > returning an `Option` works best. > > And so we end up with both `from_utf8` and `from_utf8`. This particular case > is worse because we also have `from_utf8_owned` and `from_utf8_owned_opt`, > to cover everything. > > Multiplying names like this is just not good design. I?d like to reduce this > pattern. > > Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on the > Option. I think we should rename every `foo_opt()` function or method to > just `foo`, remove the old `foo()` behavior, and tell people (through > documentation) to use `foo().unwrap()` if they want it back? > > The downsides are that unwrap is more verbose and gives less helpful error > messages on task failure. But I think it?s worth it. > > What do you think? > > (PS: I?m guilty of making this worse in #10828, but I?d like to discuss this > before sending pull requests with invasive API changes.) > > -- > Simon Sapin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From leo.testard at gmail.com Fri Dec 6 12:55:56 2013 From: leo.testard at gmail.com (=?windows-1252?Q?L=E9o_Testard?=) Date: Fri, 6 Dec 2013 21:55:56 +0100 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: References: <52A23660.5040500@exyr.org> Message-ID: <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> Hi, Just a suggestion, don't know what it's worth... For the "not helpful error message" thing, couldn't we extend the option API, to be able to specify at the creation of a None value the error string that will be displayed if one calls unwrap() on this value ? This may be useful in several situations. Leo Le 6 d?c. 2013 ? 21:48, Corey Richardson a ?crit : > I'm in favor of this but it makes things less "pretty". Is the choice > really between pretty and fast? > > On Fri, Dec 6, 2013 at 3:41 PM, Simon Sapin wrote: >> We have some functions and methods such as >> [std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) >> that may succeed and give a result, or fail when the input is invalid. >> >> 1. Sometimes we assume the input is valid and don?t want to deal with the >> error case. Task failure works nicely. >> >> 2. Sometimes we do want to do something different on invalid input, so >> returning an `Option` works best. >> >> And so we end up with both `from_utf8` and `from_utf8`. This particular case >> is worse because we also have `from_utf8_owned` and `from_utf8_owned_opt`, >> to cover everything. >> >> Multiplying names like this is just not good design. I?d like to reduce this >> pattern. >> >> Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on the >> Option. I think we should rename every `foo_opt()` function or method to >> just `foo`, remove the old `foo()` behavior, and tell people (through >> documentation) to use `foo().unwrap()` if they want it back? >> >> The downsides are that unwrap is more verbose and gives less helpful error >> messages on task failure. But I think it?s worth it. >> >> What do you think? >> >> (PS: I?m guilty of making this worse in #10828, but I?d like to discuss this >> before sending pull requests with invasive API changes.) >> >> -- >> Simon Sapin >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ezyang at mit.edu Fri Dec 6 01:15:48 2013 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 06 Dec 2013 01:15:48 -0800 Subject: [rust-dev] Safely writing iterators over idiomatic C structures In-Reply-To: <52A18A3C.9060606@gmail.com> References: <1386315514-sup-3583@sabre> <52A18A3C.9060606@gmail.com> Message-ID: <1386321238-sup-7265@sabre> Excerpts from Huon Wilson's message of 2013-12-06 00:26:36 -0800: > One could have an Iterator<(&mut int, &mut int)>, where the references > point to just the fields. Off the top of my head: Sure. (This is not so good when there are a lot of fields.) > impl<'a> Iterator<(&'a mut int, &'a mut f64)> for ListMutIterator<'a> { > fn next(&mut self) -> Option<(&'a mut int, &'a mut f64)> { > let elem = std::util::replace(self, None); // I think this > might be necessary to get around the borrow checker. > > let (ret, next) = match elem { > Some(&List { payload1: ref mut payload1, next: ref mut > next, payload2: ref mut payload2 }) => { > (Some((payload1, payload2)), next.as_mut_ref()) I fixed some of the egregious type-checking errors, but this one has me stuck. There is no as_mut_ref() in the version of Rust I'm running, and the plausible replacement mut_ref() doesn't do what I want: Huon.rs|24 col 37 error| mismatched types: expected `std::option::Option<&mut List>` but found `std::option::Option<&mut ~List>` (expected struct List but found ~-ptr) (Because, of course, the thing inside the option is a ~List, not a List). Cheers, Edward From ezyang at mit.edu Fri Dec 6 01:22:42 2013 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 06 Dec 2013 01:22:42 -0800 Subject: [rust-dev] Safely writing iterators over idiomatic C structures In-Reply-To: <1386321238-sup-7265@sabre> References: <1386315514-sup-3583@sabre> <52A18A3C.9060606@gmail.com> <1386321238-sup-7265@sabre> Message-ID: <1386321636-sup-8996@sabre> OK, with a little bit of tweaking I have come up with a version that seems to work: struct List { payload1: int, next: Option<~List>, payload2: f64 } struct ListMutIterator<'a> { elem: Option<&'a mut List> } impl<'a> Iterator<(&'a mut int, &'a mut f64)> for ListMutIterator<'a> { fn next(&mut self) -> Option<(&'a mut int, &'a mut f64)> { let elem = std::util::replace(self, ListMutIterator{elem:None}); // I think this might be necessary to get around the borrow checker. let (ret, next) = match elem { ListMutIterator{elem: Some(&List { payload1: ref mut payload1, next: ref mut next, payload2: ref mut payload2 })} => { (Some((payload1, payload2)), match *next { None => None, Some(ref mut p) => Some(&mut **p) }) } ListMutIterator{elem: None} => (None, None) }; *self = ListMutIterator{elem:next}; ret } } Perhaps dlist should be updated to use this implementation strategy? Edward From danielmicay at gmail.com Fri Dec 6 13:41:53 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 6 Dec 2013 16:41:53 -0500 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: <52A23660.5040500@exyr.org> References: <52A23660.5040500@exyr.org> Message-ID: On Fri, Dec 6, 2013 at 3:41 PM, Simon Sapin wrote: > We have some functions and methods such as > [std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) > that may succeed and give a result, or fail when the input is invalid. > > 1. Sometimes we assume the input is valid and don?t want to deal with the > error case. Task failure works nicely. > > 2. Sometimes we do want to do something different on invalid input, so > returning an `Option` works best. > > And so we end up with both `from_utf8` and `from_utf8`. This particular case > is worse because we also have `from_utf8_owned` and `from_utf8_owned_opt`, > to cover everything. > > Multiplying names like this is just not good design. I?d like to reduce this > pattern. > > Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on the > Option. I think we should rename every `foo_opt()` function or method to > just `foo`, remove the old `foo()` behavior, and tell people (through > documentation) to use `foo().unwrap()` if they want it back? > > The downsides are that unwrap is more verbose and gives less helpful error > messages on task failure. But I think it?s worth it. > > What do you think? > > (PS: I?m guilty of making this worse in #10828, but I?d like to discuss this > before sending pull requests with invasive API changes.) > > -- > Simon Sapin A stack trace already tells you where the error came from so I don't think it's an important consideration. Rust can provide stack traces on failure by default if that's desired. From simon.sapin at exyr.org Fri Dec 6 13:43:49 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Fri, 06 Dec 2013 21:43:49 +0000 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: References: <52A23660.5040500@exyr.org> Message-ID: <52A24515.6080407@exyr.org> On 06/12/2013 20:48, Corey Richardson wrote: > I'm in favor of this but it makes things less "pretty". Is the choice > really between pretty and fast? I don?t think this is about speed. My concern is that having two almost-identical names for functions that do almost the same thing is not a good design, and should be avoided if possible. -- Simon Sapin From banderson at mozilla.com Fri Dec 6 13:44:11 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 06 Dec 2013 13:44:11 -0800 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <52A23660.5040500@exyr.org> References: <52A23660.5040500@exyr.org> Message-ID: <52A2452B.7030102@mozilla.com> On 12/06/2013 12:41 PM, Simon Sapin wrote: > We have some functions and methods such as > [std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) > that may succeed and give a result, or fail when the input is invalid. > > 1. Sometimes we assume the input is valid and don?t want to deal with > the error case. Task failure works nicely. > > 2. Sometimes we do want to do something different on invalid input, so > returning an `Option` works best. > > And so we end up with both `from_utf8` and `from_utf8`. This > particular case is worse because we also have `from_utf8_owned` and > `from_utf8_owned_opt`, to cover everything. > > Multiplying names like this is just not good design. I?d like to > reduce this pattern. > > Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on > the Option. I think we should rename every `foo_opt()` function or > method to just `foo`, remove the old `foo()` behavior, and tell people > (through documentation) to use `foo().unwrap()` if they want it back? > > The downsides are that unwrap is more verbose and gives less helpful > error messages on task failure. But I think it?s worth it. > > What do you think? > > (PS: I?m guilty of making this worse in #10828, but I?d like to > discuss this before sending pull requests with invasive API changes.) > I agree in this case (and probably a lot of cases), especially since this is a relatively uncommon operation and since (I think) we're prefering 'get' to 'unwrap' and that's even shorter. There are some cases where I think failure is the right option by default though; in particular I was worried you were going to bring up the 'send' and 'recv' methods on channels which fail when disconnected. In this case I think it won't be common to handle the failure since it indicates some logic error, and these are very common operations. From simon.sapin at exyr.org Fri Dec 6 13:45:55 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Fri, 06 Dec 2013 21:45:55 +0000 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> Message-ID: <52A24593.4020203@exyr.org> On 06/12/2013 20:55, L?o Testard wrote: > Hi, > > Just a suggestion, don't know what it's worth... > > For the "not helpful error message" thing, couldn't we extend the > option API, to be able to specify at the creation of a None value > the error string that will be displayed if one calls unwrap() on this > value ? This may be useful in several situations. That would require making the memory representation of every Option bigger. Just for the (hopefully) uncommon case of task failure, it?s not worth the cost in my opinion. We could instead have .unwrap() that take an error message, but that leaves the responsibility to the user of the API. -- Simon Sapin From ecreed at cs.washington.edu Fri Dec 6 13:50:00 2013 From: ecreed at cs.washington.edu (Eric Reed) Date: Fri, 6 Dec 2013 13:50:00 -0800 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <52A24593.4020203@exyr.org> References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> Message-ID: FYI, there's already a method on Option that is unwrap() with an error message: expect(). Personally, I prefer making functions that don't fail and use Option or Result and then composing them with functions that fail for certain outputs, but I think I'm in the minority there. On Fri, Dec 6, 2013 at 1:45 PM, Simon Sapin wrote: > On 06/12/2013 20:55, L?o Testard wrote: > >> Hi, >> >> Just a suggestion, don't know what it's worth... >> >> For the "not helpful error message" thing, couldn't we extend the >> option API, to be able to specify at the creation of a None value >> the error string that will be displayed if one calls unwrap() on this >> value ? This may be useful in several situations. >> > > That would require making the memory representation of every Option > bigger. Just for the (hopefully) uncommon case of task failure, it?s not > worth the cost in my opinion. > > We could instead have .unwrap() that take an error message, but that > leaves the responsibility to the user of the API. > > > -- > Simon Sapin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sapin at exyr.org Fri Dec 6 13:50:48 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Fri, 06 Dec 2013 21:50:48 +0000 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <52A2452B.7030102@mozilla.com> References: <52A23660.5040500@exyr.org> <52A2452B.7030102@mozilla.com> Message-ID: <52A246B8.7050809@exyr.org> On 06/12/2013 21:44, Brian Anderson wrote: > I agree in this case (and probably a lot of cases), especially since > this is a relatively uncommon operation and since (I think) we're > prefering 'get' to 'unwrap' and that's even shorter. > > There are some cases where I think failure is the right option by > default though; in particular I was worried you were going to bring up > the 'send' and 'recv' methods on channels which fail when disconnected. > In this case I think it won't be common to handle the failure since it > indicates some logic error, and these are very common operations. Maybe this should be a case-by-case decision, but send/try_send and recv/try_recv have the same issue as from_utf8/from_utf8_opt of two slightly different names for almost the same thing. -- Simon Sapin From simon.sapin at exyr.org Fri Dec 6 13:52:07 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Fri, 06 Dec 2013 21:52:07 +0000 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> Message-ID: <52A24707.4020709@exyr.org> On 06/12/2013 21:50, Eric Reed wrote: > Personally, I prefer making functions that don't fail and use Option or > Result and then composing them with functions that fail for certain > outputs, but I think I'm in the minority there. Yes, this is what I?m suggesting. -- Simon Sapin From palmercox at gmail.com Fri Dec 6 16:00:53 2013 From: palmercox at gmail.com (Palmer Cox) Date: Fri, 6 Dec 2013 19:00:53 -0500 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <52A24707.4020709@exyr.org> References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> Message-ID: Why not use Result instead of Option for these types of things? Result is already defined to be able to return error codes using Err. The only way to indicate an error when returning an Option is to return None which doesn't allow for that. Also, IMO, None doesn't necessarily mean "error" to me. Lets say we have a function defined as: fn do_something(value: Option<~str>); It seems like it would be much to easy to accidentally write something like: do_something(str::from_utf8(...)) which might result in the error being hidden since do_something might not consider None to be an error input. -Palmer Cox On Fri, Dec 6, 2013 at 4:52 PM, Simon Sapin wrote: > On 06/12/2013 21:50, Eric Reed wrote: > >> Personally, I prefer making functions that don't fail and use Option or >> Result and then composing them with functions that fail for certain >> outputs, but I think I'm in the minority there. >> > > Yes, this is what I?m suggesting. > > > -- > Simon Sapin > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Dec 6 16:02:43 2013 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 6 Dec 2013 19:02:43 -0500 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> Message-ID: On Fri, Dec 6, 2013 at 7:00 PM, Palmer Cox wrote: > Why not use Result instead of Option for these types of things? Result is > already defined to be able to return error codes using Err. The only way to > indicate an error when returning an Option is to return None which doesn't > allow for that. Also, IMO, None doesn't necessarily mean "error" to me. Lets > say we have a function defined as: > > fn do_something(value: Option<~str>); > > It seems like it would be much to easy to accidentally write something like: > do_something(str::from_utf8(...)) which might result in the error being > hidden since do_something might not consider None to be an error input. > > -Palmer Cox If there's only one reason it could fail, then `Option` is the idiomatic way to report the error case. It's exactly what `Option` is used for. A stack trace can report where the error occurred if you decide to ignore the error case and use `unwrap` (or `get`, if it's renamed). From gaetan at xeberon.net Fri Dec 6 16:12:47 2013 From: gaetan at xeberon.net (Gaetan) Date: Sat, 7 Dec 2013 01:12:47 +0100 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> Message-ID: I also find the repeatition of unwrap all over the code being quite nasty Most of the time the result is just unwrapped without taking into account the error case, so i think the usage of Option or Result useless. I think a good solution exits and can make the code more maintainable, and easier to read. There should not have all these unwrap (or get) call for code we know it cannot fails, because the necessary check has been done earlier. I am in favor of two version of the api: from_str which has already done the unwrap, and a from_str_safe for instance that returns a Result or option. Or perhaps allow the propagation of Option/Result. Le 7 d?c. 2013 01:03, "Daniel Micay" a ?crit : > On Fri, Dec 6, 2013 at 7:00 PM, Palmer Cox wrote: > > Why not use Result instead of Option for these types of things? Result is > > already defined to be able to return error codes using Err. The only way > to > > indicate an error when returning an Option is to return None which > doesn't > > allow for that. Also, IMO, None doesn't necessarily mean "error" to me. > Lets > > say we have a function defined as: > > > > fn do_something(value: Option<~str>); > > > > It seems like it would be much to easy to accidentally write something > like: > > do_something(str::from_utf8(...)) which might result in the error being > > hidden since do_something might not consider None to be an error input. > > > > -Palmer Cox > > If there's only one reason it could fail, then `Option` is the > idiomatic way to report the error case. It's exactly what `Option` is > used for. A stack trace can report where the error occurred if you > decide to ignore the error case and use `unwrap` (or `get`, if it's > renamed). > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Fri Dec 6 16:21:31 2013 From: gaetan at xeberon.net (Gaetan) Date: Sat, 7 Dec 2013 01:21:31 +0100 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> Message-ID: Isnt a way for Option to unwrap implicitely when check on error state is not done ? That would make the code less verbose but still allow the dev to check for error if want? Le 7 d?c. 2013 01:12, "Gaetan" a ?crit : > I also find the repeatition of unwrap all over the code being quite nasty > > Most of the time the result is just unwrapped without taking into account > the error case, so i think the usage of Option or Result useless. > > I think a good solution exits and can make the code more maintainable, and > easier to read. There should not have all these unwrap (or get) call for > code we know it cannot fails, because the necessary check has been done > earlier. > > I am in favor of two version of the api: from_str which has already done > the unwrap, and a from_str_safe for instance that returns a Result or > option. > > Or perhaps allow the propagation of Option/Result. > Le 7 d?c. 2013 01:03, "Daniel Micay" a ?crit : > >> On Fri, Dec 6, 2013 at 7:00 PM, Palmer Cox wrote: >> > Why not use Result instead of Option for these types of things? Result >> is >> > already defined to be able to return error codes using Err. The only >> way to >> > indicate an error when returning an Option is to return None which >> doesn't >> > allow for that. Also, IMO, None doesn't necessarily mean "error" to me. >> Lets >> > say we have a function defined as: >> > >> > fn do_something(value: Option<~str>); >> > >> > It seems like it would be much to easy to accidentally write something >> like: >> > do_something(str::from_utf8(...)) which might result in the error being >> > hidden since do_something might not consider None to be an error input. >> > >> > -Palmer Cox >> >> If there's only one reason it could fail, then `Option` is the >> idiomatic way to report the error case. It's exactly what `Option` is >> used for. A stack trace can report where the error occurred if you >> decide to ignore the error case and use `unwrap` (or `get`, if it's >> renamed). >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sapin at exyr.org Fri Dec 6 16:47:55 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Sat, 07 Dec 2013 00:47:55 +0000 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> Message-ID: <52A2703B.4090608@exyr.org> On 07/12/2013 00:12, Gaetan wrote: > I am in favor of two version of the api: from_str which has already done > the unwrap, and a from_str_safe for instance that returns a Result or > option. This is what we have now. (Eg. from_utf8() and from_utf8_opt()) The point of my initial email was to argue against this. I think we should try to avoid doubling the amount of API. > Or perhaps allow the propagation of Option/Result. This is why we have methods like .map() and .and_then() -- Simon Sapin From denis.spir at gmail.com Fri Dec 6 16:49:48 2013 From: denis.spir at gmail.com (spir) Date: Sat, 07 Dec 2013 01:49:48 +0100 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: <52A23660.5040500@exyr.org> References: <52A23660.5040500@exyr.org> Message-ID: <52A270AC.8050700@gmail.com> On 12/06/2013 09:41 PM, Simon Sapin wrote: > We have some functions and methods such as > [std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) > that may succeed and give a result, or fail when the input is invalid. > > 1. Sometimes we assume the input is valid and don?t want to deal with the error > case. Task failure works nicely. > > 2. Sometimes we do want to do something different on invalid input, so returning > an `Option` works best. > > And so we end up with both `from_utf8` and `from_utf8`. This particular case is > worse because we also have `from_utf8_owned` and `from_utf8_owned_opt`, to cover > everything. > > Multiplying names like this is just not good design. I?d like to reduce this > pattern. > > Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on the > Option. I think we should rename every `foo_opt()` function or method to just > `foo`, remove the old `foo()` behavior, and tell people (through documentation) > to use `foo().unwrap()` if they want it back? > > The downsides are that unwrap is more verbose and gives less helpful error > messages on task failure. But I think it?s worth it. > > What do you think? > > (PS: I?m guilty of making this worse in #10828, but I?d like to discuss this > before sending pull requests with invasive API changes.) [A bit long, sorry, this is a topic about which i have thought for a while.] There may be a more complicated general pattern, of all kinds of functions that may not be able to perform their nominal task, due to invalid input, but the client cannot know whether the input is valid without more or less reproducing said task. Checking utf8 validity is about the same job as decoding, for instance, to reuse your example. Compare with a function computing the average value of a collection of numbers (or the sum, product, std-dev, etc...) which is passed an empty collection: here the client can know, thus: 1. if this abnormal case does not belong to the app's logic, the client should just call the func stupidly so that the func failure is a signal of logical error on the app side 2. if instead this case belongs to the app's logic, the client should first check, and never call the func in this special case Thus, despite very possible failure, there should here be only one version of the func (no *_opt), one that stupidly fails, with a stupid error msg. Back to the cases where the client cannot know before calling. To this category belong a whole series of search/find functions, and many dealing with the file system, user input, input in general. In the latter case, a func's input is in fact not (all) provided by the client. But there is the same pattern of anomalous cases which may, or not, belong to the app logic (1. or 2. above): is it correct (if special or exceptional) that such file does not exist, or such collection does not hold the searched item? Meaning, should I deal with such cases? If not, if such a case does not belong to the application logic, again I should stupidly call a func that stupidly fails with a stupid error msg, so I am told, simply and early, of my logical errors. These are true errors (not so-called exceptions), and the failure is a symptom or signal, a good thing (if, indeed, what you want is making good software). I *want* it; and want it so! I'm in favor of simple funcs doing simple tasks simply, and just failing in anomalous cases, for these reasons. [1] Remains the situation combined of such funcs, of which the client cannot know whether they will be able to perform their task, and of abnormal cases belonging to the logic of the app (there are also whole categories of maintenance and safety modes here). For such situations, it looks somewhat logical to have 2 versions, I guess. Playing a bit with words: 1. when I ask to _find_ something, I take it for granted the thing is somewhere there, and expect a location in return 2. when I ask to _search_ something, I do not take anything for granted, and expect in return _either_ "not there!" or a location This duality applies both to the so-called real world (despite blur natural language word meanings) and software worlds, and extends to all cases, it seems. We can certainly find a way, using Option or another mean, to combine both categories of situations (1. or 2.) using a single tool, but this should be very well done, and ensure that: * In cases of category 1., developers are warned about their errors exactly as if they had called a stupidly failing func. * At the semantic (conceptual) level, the duality of categories remains somehow preserved, including in source code. About the latter, in particular it should be obvious in code, without knowledge of language arcanes or weird idioms, that (or whether) the caller expects a success unconditionally -- because (and in other words that) the anomalous case just does not belong to this app; this is critical information to the reader. How to do that right? PS: I take the opportunity of again thanking the initiators of this Rust project for their welcoming and open-mindedness to such exchanges. This is really great. I'm not sure anymore Rust is the right language for me (maybe too complicated and abstract for my poor and old little mind...) but go on following the mailing list (and please keep it a mailing list! ;-) for this quality of sharing. Denis [1] I'm very much against complicated funcs, even more against ones that try to guess what you want in anomolous cases (eg return 0 as sum of no number, or 1 as product, lol!), and totally against the pretention that software should not fail, as apparently defended by Go's designers. This leads to illogical things, like their utf8 decoder, precisely, inserting codes for the replacement character U+FFFD ?, a *valid* code, instead of signaling invalid source. So that you never know the input was invalid, or whether this code belong to the source or was inserted by their func... From simon.sapin at exyr.org Fri Dec 6 16:55:19 2013 From: simon.sapin at exyr.org (Simon Sapin) Date: Sat, 07 Dec 2013 00:55:19 +0000 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: <52A270AC.8050700@gmail.com> References: <52A23660.5040500@exyr.org> <52A270AC.8050700@gmail.com> Message-ID: <52A271F7.9060804@exyr.org> On 07/12/2013 00:49, spir wrote: > About the latter, in particular it should be obvious in code, without knowledge > of language arcanes or weird idioms, that (or whether) the caller expects a > success unconditionally -- because (and in other words that) the anomalous case > just does not belong to this app; this is critical information to the reader. > How to do that right? If my proposal is accepted (returning Option is favored), then calling .unwrap() is the way to express that success is expected. unwrap() causes task failure when called with None. -- Simon Sapin From denis.spir at gmail.com Fri Dec 6 17:01:47 2013 From: denis.spir at gmail.com (spir) Date: Sat, 07 Dec 2013 02:01:47 +0100 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> Message-ID: <52A2737B.3070901@gmail.com> On 12/07/2013 01:12 AM, Gaetan wrote: > I am in favor of two version of the api: from_str which has already done > the unwrap, and a from_str_safe for instance that returns a Result or > option. This provides the important semantic information (that I've evoked at the end end of a long earlier reply in this thread) of whether func failure is expected and belongs to the logic of the present app and we must deal with it, or not. But I'm still shared on this topic for finding it also annoying, like Simon, to have to duplicate whole catogories of such funcs (of which we cannot know in advance whther they'll fail or not), if only the interface as apparently proposed by Ga?tan. Denis From denis.spir at gmail.com Fri Dec 6 17:07:28 2013 From: denis.spir at gmail.com (spir) Date: Sat, 07 Dec 2013 02:07:28 +0100 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: <52A271F7.9060804@exyr.org> References: <52A23660.5040500@exyr.org> <52A270AC.8050700@gmail.com> <52A271F7.9060804@exyr.org> Message-ID: <52A274D0.5050702@gmail.com> On 12/07/2013 01:55 AM, Simon Sapin wrote: > On 07/12/2013 00:49, spir wrote: >> About the latter, in particular it should be obvious in code, without knowledge >> of language arcanes or weird idioms, that (or whether) the caller expects a >> success unconditionally -- because (and in other words that) the anomalous case >> just does not belong to this app; this is critical information to the reader. >> How to do that right? > > If my proposal is accepted (returning Option is favored), then calling .unwrap() > is the way to express that success is expected. unwrap() causes task failure > when called with None. Maybe it's only me, but this not at at all clear to my eyes. My imagined soluton (for a totally different lang) was something like this, on the caller side: ucodes = s.utf8_decode()! // source should be correct, error on failure ucodes = s.utf8_decode()? // logical failure expected, return None or whatnot (But maybe _this_ is obscure to your eyes?) Denis From j.boggiano at seld.be Fri Dec 6 17:08:24 2013 From: j.boggiano at seld.be (Jordi Boggiano) Date: Sat, 7 Dec 2013 02:08:24 +0100 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= Message-ID: On Sat, Dec 7, 2013 at 2:01 AM, spir wrote: > On 12/07/2013 01:12 AM, Gaetan wrote: >> >> I am in favor of two version of the api: from_str which has already done >> the unwrap, and a from_str_safe for instance that returns a Result or >> option. > > This provides the important semantic information (that I've evoked at the > end end of a long earlier reply in this thread) of whether func failure is > expected and belongs to the logic of the present app and we must deal with > it, or not. > > But I'm still shared on this topic for finding it also annoying, like Simon, > to have to duplicate whole catogories of such funcs (of which we cannot know > in advance whther they'll fail or not), if only the interface as apparently > proposed by Ga?tan. Syntax sugar like this would be nice: let str = std::str::from_utf8("Parse this optimistically, and fail otherwise"); // str is a string or the task fails vs. let opt_str = std::str::from_utf?("Parse this if valid"); // note the question mark if opt_str.is_some() { .... } Problem is, this sounds scary to implement at the compiler level, if it's possible at all :) I am just throwing it out there for others to judge. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi From j.boggiano at seld.be Fri Dec 6 17:14:14 2013 From: j.boggiano at seld.be (Jordi Boggiano) Date: Sat, 7 Dec 2013 02:14:14 +0100 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <52A274D0.5050702@gmail.com> References: <52A23660.5040500@exyr.org> <52A270AC.8050700@gmail.com> <52A271F7.9060804@exyr.org> <52A274D0.5050702@gmail.com> Message-ID: On Sat, Dec 7, 2013 at 2:07 AM, spir wrote: > Maybe it's only me, but this not at at all clear to my eyes. My imagined > soluton (for a totally different lang) was something like this, on the > caller side: > > ucodes = s.utf8_decode()! // source should be correct, error > on failure > ucodes = s.utf8_decode()? // logical failure expected, return > None or whatnot > > (But maybe _this_ is obscure to your eyes?) Looks like our mails had a race condition on this one, but highlighting the cases where we expect a perfect world (i.e. !) is probably better. However, if you just call the method without anything it would be the same as calling it with ? suffix as far as I understand, so I'm not sure what the point is of keeping that one. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi From dbau.pp at gmail.com Fri Dec 6 17:14:18 2013 From: dbau.pp at gmail.com (Huon Wilson) Date: Sat, 07 Dec 2013 12:14:18 +1100 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: References: Message-ID: <52A2766A.6000105@gmail.com> On 07/12/13 12:08, Jordi Boggiano wrote: > On Sat, Dec 7, 2013 at 2:01 AM, spir wrote: >> On 12/07/2013 01:12 AM, Gaetan wrote: >>> I am in favor of two version of the api: from_str which has already done >>> the unwrap, and a from_str_safe for instance that returns a Result or >>> option. >> This provides the important semantic information (that I've evoked at the >> end end of a long earlier reply in this thread) of whether func failure is >> expected and belongs to the logic of the present app and we must deal with >> it, or not. >> >> But I'm still shared on this topic for finding it also annoying, like Simon, >> to have to duplicate whole catogories of such funcs (of which we cannot know >> in advance whther they'll fail or not), if only the interface as apparently >> proposed by Ga?tan. > Syntax sugar like this would be nice: > > let str = std::str::from_utf8("Parse this optimistically, and fail otherwise"); > // str is a string or the task fails > > vs. > > let opt_str = std::str::from_utf?("Parse this if valid"); // note the > question mark > if opt_str.is_some() { .... } > > Problem is, this sounds scary to implement at the compiler level, if > it's possible at all :) I am just throwing it out there for others to > judge. > > Cheers > I personally think a better solution is something like Haskell's do notation[1], where you can chain several computations that return Option<..> such that if any intermediate one returns None, the later ones are not evaluated and the whole expression returns None, which saves having to call .get()/.unwrap()/.expect() a lot. This can work for types like Result too (in fact, the Haskell implementation of `do` is sugar around some monad functions, so any monad can be used there; we currently don't have the power to express the monad typeclass/trait in Rust so the fully general form probably isn't possible as a syntax extension yet, although a limited version is). Huon [1]: http://en.wikibooks.org/wiki/Haskell/do_Notation From bill_myers at outlook.com Fri Dec 6 17:43:55 2013 From: bill_myers at outlook.com (Bill Myers) Date: Sat, 7 Dec 2013 01:43:55 +0000 Subject: [rust-dev] Safely writing iterators over idiomatic C structures In-Reply-To: References: <1386315514-sup-3583@sabre> , Message-ID: > It can't be defined that way without becoming much less useful for > more common cases. Any example of this? Iterators are most commonly used in for loops, and this change makes no difference in this case. Functions that transform iterators also work the same. Things like collect() don't work for all iterators, but it should be possible to make them work for iterators on types that don't have lifetimes. That is, introducing syntax like this: fn collect<'a, T:'a, U: Iterator>(iter: U) -> ~['a U] {} where the 'a bound on T means that the 'x T is convertible to 'a T for any x. From com.liigo at gmail.com Fri Dec 6 18:22:27 2013 From: com.liigo at gmail.com (Liigo Zhuang) Date: Sat, 7 Dec 2013 10:22:27 +0800 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: <52A2766A.6000105@gmail.com> References: <52A2766A.6000105@gmail.com> Message-ID: Is do-notation in Haskell similar as: try{ block } ? 2013/12/7 Huon Wilson > On 07/12/13 12:08, Jordi Boggiano wrote: > >> On Sat, Dec 7, 2013 at 2:01 AM, spir wrote: >> >>> On 12/07/2013 01:12 AM, Gaetan wrote: >>> >>>> I am in favor of two version of the api: from_str which has already done >>>> the unwrap, and a from_str_safe for instance that returns a Result or >>>> option. >>>> >>> This provides the important semantic information (that I've evoked at the >>> end end of a long earlier reply in this thread) of whether func failure >>> is >>> expected and belongs to the logic of the present app and we must deal >>> with >>> it, or not. >>> >>> But I'm still shared on this topic for finding it also annoying, like >>> Simon, >>> to have to duplicate whole catogories of such funcs (of which we cannot >>> know >>> in advance whther they'll fail or not), if only the interface as >>> apparently >>> proposed by Ga?tan. >>> >> Syntax sugar like this would be nice: >> >> let str = std::str::from_utf8("Parse this optimistically, and fail >> otherwise"); >> // str is a string or the task fails >> >> vs. >> >> let opt_str = std::str::from_utf?("Parse this if valid"); // note the >> question mark >> if opt_str.is_some() { .... } >> >> Problem is, this sounds scary to implement at the compiler level, if >> it's possible at all :) I am just throwing it out there for others to >> judge. >> >> Cheers >> >> > I personally think a better solution is something like Haskell's do > notation[1], where you can chain several computations that return > Option<..> such that if any intermediate one returns None, the later ones > are not evaluated and the whole expression returns None, which saves having > to call .get()/.unwrap()/.expect() a lot. > > This can work for types like Result too (in fact, the Haskell > implementation of `do` is sugar around some monad functions, so any monad > can be used there; we currently don't have the power to express the monad > typeclass/trait in Rust so the fully general form probably isn't possible > as a syntax extension yet, although a limited version is). > > > Huon > > [1]: http://en.wikibooks.org/wiki/Haskell/do_Notation > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Fri Dec 6 18:46:20 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 6 Dec 2013 21:46:20 -0500 Subject: [rust-dev] =?utf-8?q?Let=E2=80=99s_avoid_having_both_foo=28=29_an?= =?utf-8?b?ZCBmb29fb3B0KCk=?= In-Reply-To: References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> Message-ID: <20131207024620.GF21055@Mr-Bennet> On Fri, Dec 06, 2013 at 07:00:53PM -0500, Palmer Cox wrote: > Why not use Result instead of Option for these types of things? I agree. I've personally been moving towards `Result` in preference to `Option` when one of the branches reflects an error. It's worth noting that the compiler could still optimize this into a pointer-null-pointer representation, though I doubt it does so now. Niko From niko at alum.mit.edu Fri Dec 6 18:53:26 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 6 Dec 2013 21:53:26 -0500 Subject: [rust-dev] Safely writing iterators over idiomatic C structures In-Reply-To: References: <1386315514-sup-3583@sabre> Message-ID: <20131207025326.GG21055@Mr-Bennet> Please see: http://smallcultfollowing.com/babysteps/blog/2013/10/24/iterators-yielding-mutable-references/ http://smallcultfollowing.com/babysteps/blog/2013/10/24/iterators-yielding-mutable-references-take-2/ Those posts discuss a lot of things, but I believe the also cover the tradeoffs involved in distinguishing these two kinds of signatures. Niko On Fri, Dec 06, 2013 at 03:50:59PM +0000, Bill Myers wrote: > Maybe the language should be changed to allow Iterator to be changed to have a signature like this: > pub trait Iterator { > ??? fn next<'a>(&'a mut self) -> Option<'a A>; > } > > Then you could return the &mut by reborrowing and would be able to advance the iterator without issue afterwards. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From hatahet at gmail.com Fri Dec 6 19:04:50 2013 From: hatahet at gmail.com (Ziad Hatahet) Date: Fri, 6 Dec 2013 19:04:50 -0800 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <52A2766A.6000105@gmail.com> References: <52A2766A.6000105@gmail.com> Message-ID: I posted a question on the mailing list concerning this back in May: https://mail.mozilla.org/pipermail/rust-dev/2013-May/004176.html There were a couple of responses which implemented this in a macro. It would be nice if it were at the language level though. -- Ziad On Fri, Dec 6, 2013 at 5:14 PM, Huon Wilson wrote: > On 07/12/13 12:08, Jordi Boggiano wrote: > >> On Sat, Dec 7, 2013 at 2:01 AM, spir wrote: >> >>> On 12/07/2013 01:12 AM, Gaetan wrote: >>> >>>> I am in favor of two version of the api: from_str which has already done >>>> the unwrap, and a from_str_safe for instance that returns a Result or >>>> option. >>>> >>> This provides the important semantic information (that I've evoked at the >>> end end of a long earlier reply in this thread) of whether func failure >>> is >>> expected and belongs to the logic of the present app and we must deal >>> with >>> it, or not. >>> >>> But I'm still shared on this topic for finding it also annoying, like >>> Simon, >>> to have to duplicate whole catogories of such funcs (of which we cannot >>> know >>> in advance whther they'll fail or not), if only the interface as >>> apparently >>> proposed by Ga?tan. >>> >> Syntax sugar like this would be nice: >> >> let str = std::str::from_utf8("Parse this optimistically, and fail >> otherwise"); >> // str is a string or the task fails >> >> vs. >> >> let opt_str = std::str::from_utf?("Parse this if valid"); // note the >> question mark >> if opt_str.is_some() { .... } >> >> Problem is, this sounds scary to implement at the compiler level, if >> it's possible at all :) I am just throwing it out there for others to >> judge. >> >> Cheers >> >> > I personally think a better solution is something like Haskell's do > notation[1], where you can chain several computations that return > Option<..> such that if any intermediate one returns None, the later ones > are not evaluated and the whole expression returns None, which saves having > to call .get()/.unwrap()/.expect() a lot. > > This can work for types like Result too (in fact, the Haskell > implementation of `do` is sugar around some monad functions, so any monad > can be used there; we currently don't have the power to express the monad > typeclass/trait in Rust so the fully general form probably isn't possible > as a syntax extension yet, although a limited version is). > > > Huon > > [1]: http://en.wikibooks.org/wiki/Haskell/do_Notation > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Fri Dec 6 20:14:38 2013 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 06 Dec 2013 20:14:38 -0800 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <20131207024620.GF21055@Mr-Bennet> References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> <20131207024620.GF21055@Mr-Bennet> Message-ID: <52A2A0AE.2060409@mozilla.com> On 12/6/13 6:46 PM, Niko Matsakis wrote: > I agree. I've personally been moving towards `Result` in > preference to `Option` when one of the branches reflects an > error. It's worth noting that the compiler could still optimize this > into a pointer-null-pointer representation, though I doubt it does so > now. IIRC it does. Patrick From bjzaba at yahoo.com.au Fri Dec 6 22:15:52 2013 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Sat, 7 Dec 2013 16:15:52 +1000 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <52A2703B.4090608@exyr.org> References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> <52A2703B.4090608@exyr.org> Message-ID: <2E1A59CD-DAF0-4B81-97D8-4451FC71D52B@yahoo.com.au> On 7 Dec 2013, at 10:47 am, Simon Sapin wrote: > This is why we have methods like .map() and .and_then() I like using these higher order functions, but I run into lots of issues with moved values because we don?t have once functions. I end up having to use matches, which are awfully verbose for simple things. :( ~Brendan From oren at ben-kiki.org Fri Dec 6 22:45:49 2013 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Sat, 7 Dec 2013 08:45:49 +0200 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <2E1A59CD-DAF0-4B81-97D8-4451FC71D52B@yahoo.com.au> References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> <52A2703B.4090608@exyr.org> <2E1A59CD-DAF0-4B81-97D8-4451FC71D52B@yahoo.com.au> Message-ID: There was a whole thread about the need for once-stack-closures. They are really vital for simple programming with higher-order functions such as these. I'm not optimistic about them being added though :-( On Sat, Dec 7, 2013 at 8:15 AM, Brendan Zabarauskas wrote: > > On 7 Dec 2013, at 10:47 am, Simon Sapin wrote: > > > This is why we have methods like .map() and .and_then() > > I like using these higher order functions, but I run into lots of issues > with moved values because we don?t have once functions. I end up having to > use matches, which are awfully verbose for simple things. :( > > ~Brendan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From palmercox at gmail.com Fri Dec 6 23:00:44 2013 From: palmercox at gmail.com (Palmer Cox) Date: Sat, 7 Dec 2013 02:00:44 -0500 Subject: [rust-dev] =?windows-1252?q?Let=92s_avoid_having_both_foo=28=29_a?= =?windows-1252?q?nd_foo=5Fopt=28=29?= In-Reply-To: <52A2A0AE.2060409@mozilla.com> References: <52A23660.5040500@exyr.org> <3223E937-0D90-4080-94F4-ED85037D8589@gmail.com> <52A24593.4020203@exyr.org> <52A24707.4020709@exyr.org> <20131207024620.GF21055@Mr-Bennet> <52A2A0AE.2060409@mozilla.com> Message-ID: Especially if Result is optimized into a single word, it seems ideal to me to get rid of str::from_utf_opt(&[u8]) -> Option<~str> and just have str::from_utf(&[u8]) -> Result<~str, ()>. This makes simple programs that don't care about error handling a little more complicated, of course, since it forces them to handle the error case. Although, the only extra complication is ".unwrap()" so, its not that bad. For more complex programs that do care about error handling it makes it explicit at the call site how the error condition should be handled which I think is a big win. Return code checking is a C idiom, and there is nothing wrong with that style of error handling. However, the C compiler doesn't do much of anything to force you to check the return codes which leads to lots of code that fails to do so. Using a Result<>, however, forces the caller to do those checks. Result<> still supports various chaining functions just like Option<> to make that easier. However, you don't have to worry about accidentally passing a None to a function that takes an Option<> as an input parameter with non-error semantics. Also, I like "unwrap()" since to me, nothing about "get()" says: this is an error handling function that might lead to killing the current task. get() sounds simple and safe, buts its not if called on an Option<>. -Palmer Cox On Fri, Dec 6, 2013 at 11:14 PM, Patrick Walton wrote: > On 12/6/13 6:46 PM, Niko Matsakis wrote: > >> I agree. I've personally been moving towards `Result` in >> preference to `Option` when one of the branches reflects an >> error. It's worth noting that the compiler could still optimize this >> into a pointer-null-pointer representation, though I doubt it does so >> now. >> > > IIRC it does. > > Patrick > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qwertie256 at gmail.com Fri Dec 6 23:10:12 2013 From: qwertie256 at gmail.com (David Piepgrass) Date: Sat, 7 Dec 2013 00:10:12 -0700 Subject: [rust-dev] Higher-Kinded Types vs C++ "Combos" Message-ID: Rust newb here. I have theoretical questions. Recently I noticed that Higher-Kinded Types (HKTs) have been mentioned on the mailing list a lot, but I had no idea what a HKT was, or what it might be good for. After reading about them a little, they reminded me of C++'s "template template parameters". In C++ you can almost write something like this: template