From illissius at gmail.com Fri Mar 1 01:25:37 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Fri, 1 Mar 2013 10:25:37 +0100 Subject: [rust-dev] library editing In-Reply-To: <512FB419.3010900@mozilla.com> References: <51281661.6030005@mozilla.com> <512F8901.70508@crsr.net> <512FA6E7.4060309@mozilla.com> <512FB419.3010900@mozilla.com> Message-ID: On Thu, Feb 28, 2013 at 8:46 PM, Graydon Hoare wrote: > On 28/02/2013 10:50 AM, Graydon Hoare wrote: > >> get away with doing this (in libstd): >> >> #[vers="1.0.0"] >> pub mod foo = "github.com/user/foo#1.0"; >> >> #[vers="1.1.0"] >> pub mod foo = "github.com/user/foo#2.0"; > > Also note: in case this sounds too terrifying in terms of hacking a new > sub-dimension onto resolve, not to mention figuring out how to > (automatically?) transform minor-version bumps in the 1.x and 2.x series > of libfoo into corresponding minor-version bumps in libstd, this could > equally be accomplished manually / by convention, in terms of: > > pub mod foo_v1 = "github.com/user/foo#1.0"; > pub mod foo_v2 = "github.com/user/foo#2.0"; > pub mod foo { > pub use foo_v1::*; > } > > or even possibly > > pub mod foo { > pub mod v1 = "github.com/user/foo#1.0"; > pub mod v2 = "github.com/user/foo#2.0"; > pub use foo::v1::*; > } > > assuming foo doesn't define names v1 and v2 itself (unlikely). Our > module system is quite strong when it comes to rebinding names. Doing it > this way just involves more legwork. But it might be desirable from a > "minimizing cognitive load" perspective to make this explicit in the > code and avoid having to reason about versions when thinking about what > resolve is doing. > > -Graydon This sounds a lot like what C++ is doing with inline namespaces: http://stackoverflow.com/a/11018418 -- Your ship was destroyed in a monadic eruption. From ben.striegel at gmail.com Fri Mar 1 06:12:49 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Fri, 1 Mar 2013 09:12:49 -0500 Subject: [rust-dev] RFC: Remove custom enum variant discriminants In-Reply-To: <51303A11.9020702@mozilla.com> References: <51303A11.9020702@mozilla.com> Message-ID: So then the only changes to existing code would be: 1) Wrapping the enum definition in a macro and giving it a type. 2) Changing `foo as bar` to `foo.to_bar()`. Is this correct? Here's an example that I've modified with the new syntax: https://gist.github.com/bstrie/5064858 . It looks pretty good to me. Is the `foo.to_bar()` approach less efficient than casting? On Fri, Mar 1, 2013 at 12:18 AM, Patrick Walton wrote: > Hi everyone, > > There is currently a feature whereby custom enum variant discriminants can > be specified: > > pub enum Foo { > Bar = 1, > Baz = 2, > Boo = 3, > } > > The sole use of this is casting from the enum to an int: > > println(fmt!("%d", Bar as int)); // prints 1 > > This feature currently doesn't really meet people's needs. Chief among the > issues are: > > 1. Only ints are supported, but many enums want to correspond to different > sizes of types. > > 2. Only casting *from* an enum value is supported, not casting *to* an > enum value. Casting to an enum value is not supported because this is a > partial operation. > > 3. There is no way to have multiple values correspond to a single enum > variant. > > We could extend the syntax to support these in some way, but I'm > personally leaning toward just moving the machinery into a syntax > extension. You could write something like: > > numeric_enum!(Foo : uint { > Bar = 1, > Baz = 2 | 3, > Boo = 4 > }) > > Then the compiler would generate functions like: > > Foo::from_uint(uint) -> Result > Foo::to_uint(self) -> uint > > One could also imagine a similar syntax extension for bitfields. > > Besides the obvious advantage that it simplifies the language, we can make > the `from_foo` type return a proper Result (or use the condition system) > without building Result into the compiler. > > Thoughts? > > 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 tim.f.ford at gmail.com Fri Mar 1 08:37:08 2013 From: tim.f.ford at gmail.com (Tim Ford) Date: Fri, 1 Mar 2013 10:37:08 -0600 Subject: [rust-dev] Rust on Xen Message-ID: The OCaml-on-Xen OpenMirage (http://openmirage.org/) project is very interesting to me. The idea is that your OCaml application is compiled directly into a bootable Xen microkernel image. Rather than running inside an OS, your OCaml links to a "libOS", a library that provides all the OS services in terms of Xen hypercalls. What are your thoughts regarding whether the same could be accomplished with Rust? You'd have to reimplement the Rust runtime and many OS services, though perhaps the work done for OpenMirage could be of some help there. It seems like Rust would be a great language for this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Fri Mar 1 10:39:52 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 01 Mar 2013 13:39:52 -0500 Subject: [rust-dev] RFC: Remove custom enum variant discriminants In-Reply-To: <51303A11.9020702@mozilla.com> References: <51303A11.9020702@mozilla.com> Message-ID: <5130F5F8.30304@alum.mit.edu> Interesting idea. I'm generally in favor of moving things out of the core language. What makes me hesitate a bit here is that it would be nice if one could translate C types into Rust types that are then representation-compatible so as to ease interoperability. If we take this proposal, any C enum would have to be translated into a Rust type that uses an integer instead of an enum. This means that you'd have to "cast from" this integer any time you wanted to use the relevant field. Of course, maybe that's better, particularly since some uses of C enums (like bitsets) can't be accommodated by Rust enums. One correction, though: I believe that, today, you can cast to any numeric type, not only ints. Niko > Patrick Walton > March 1, 2013 12:18 AM > Hi everyone, > > There is currently a feature whereby custom enum variant discriminants > can be specified: > > pub enum Foo { > Bar = 1, > Baz = 2, > Boo = 3, > } > > The sole use of this is casting from the enum to an int: > > println(fmt!("%d", Bar as int)); // prints 1 > > This feature currently doesn't really meet people's needs. Chief among > the issues are: > > 1. Only ints are supported, but many enums want to correspond to > different sizes of types. > > 2. Only casting *from* an enum value is supported, not casting *to* an > enum value. Casting to an enum value is not supported because this is > a partial operation. > > 3. There is no way to have multiple values correspond to a single enum > variant. > > We could extend the syntax to support these in some way, but I'm > personally leaning toward just moving the machinery into a syntax > extension. You could write something like: > > numeric_enum!(Foo : uint { > Bar = 1, > Baz = 2 | 3, > Boo = 4 > }) > > Then the compiler would generate functions like: > > Foo::from_uint(uint) -> Result > Foo::to_uint(self) -> uint > > One could also imagine a similar syntax extension for bitfields. > > Besides the obvious advantage that it simplifies the language, we can > make the `from_foo` type return a proper Result (or use the condition > system) without building Result into the compiler. > > Thoughts? > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From graydon at mozilla.com Fri Mar 1 11:51:39 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Fri, 01 Mar 2013 11:51:39 -0800 Subject: [rust-dev] RFC: Remove custom enum variant discriminants In-Reply-To: <51303A11.9020702@mozilla.com> References: <51303A11.9020702@mozilla.com> Message-ID: <513106CB.5060201@mozilla.com> On 13-02-28 09:18 PM, Patrick Walton wrote: > There is currently a feature whereby custom enum variant discriminants > can be specified: > > pub enum Foo { > Bar = 1, > Baz = 2, > Boo = 3, > } > > The sole use of this is casting from the enum to an int: It's also to represent enums known-to-C++ with the same values when projected into rust types. > This feature currently doesn't really meet people's needs. Chief among > the issues are: > > 1. Only ints are supported, but many enums want to correspond to > different sizes of types. This much I think we need to address generally via explicit control over packing. Especially on x86, _most_ of our enums should be bytes at most. https://github.com/mozilla/rust/issues/1704 > 2. Only casting *from* an enum value is supported, not casting *to* an > enum value. Casting to an enum value is not supported because this is a > partial operation. Casting _to_ is permitted currently via transmute, which is probably a fine place to leave it. I agree it'd be nice to provide an auto_enum syntax extension that defines a bad-value condition, and produces a .from_int() safe function that hits that condition when given a bad integer. > 3. There is no way to have multiple values correspond to a single enum > variant. Is there in C++? The point of this feature has always been (to my mind) emulation of C++ where sensible. -Graydon From graydon at mozilla.com Fri Mar 1 11:58:50 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Fri, 01 Mar 2013 11:58:50 -0800 Subject: [rust-dev] Rust on Xen In-Reply-To: References: Message-ID: <5131087A.7070004@mozilla.com> On 13-03-01 08:37 AM, Tim Ford wrote: > The OCaml-on-Xen OpenMirage (http://openmirage.org/) project is very > interesting to me. The idea is that your OCaml application is compiled > directly into a bootable Xen microkernel image. Rather than running > inside an OS, your OCaml links to a "libOS", a library that provides all > the OS services in terms of Xen hypercalls. > > What are your thoughts regarding whether the same could be accomplished > with Rust? You'd have to reimplement the Rust runtime and many OS > services, though perhaps the work done for OpenMirage could be of some > help there. > > It seems like Rust would be a great language for this. Seems plausible, but we're a ways still from the runtime functions (memory, scheduling and IO) being pluggable enough to make this easy. I expect it'll be easier to experiment when the current scheduler rewrite finishes, as it's designed to support swapping out at least the event loop (IO and scheduling). -Graydon From pwalton at mozilla.com Fri Mar 1 12:04:02 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 01 Mar 2013 12:04:02 -0800 Subject: [rust-dev] RFC: Remove custom enum variant discriminants In-Reply-To: <513106CB.5060201@mozilla.com> References: <51303A11.9020702@mozilla.com> <513106CB.5060201@mozilla.com> Message-ID: <513109B2.7010000@mozilla.com> On 3/1/13 11:51 AM, Graydon Hoare wrote: > It's also to represent enums known-to-C++ with the same values when > projected into rust types. It'll always be a less-than-faithful translation, though, because C++ enum values don't have to correspond to any of the variants. You can even represent bitfields with C++ enums: enum e { a = 0x00, b = 0x01, c = 0x10, }; int main() { e x = (e)(a | c); return 0; } More importantly, the size of an enum is *undefined* in C++. So outside of C++11 `enum class` it's always dangerous to assume that a given Rust enum is bit-compatible with a C++ enum. > This much I think we need to address generally via explicit control over > packing. Especially on x86, _most_ of our enums should be bytes at most. > https://github.com/mozilla/rust/issues/1704 I'm a bit hesitant to commit to a particular bit representation of enums, since there's lots of room for compiler optimization here. For example, we might want to collapse `Option<~int>` into a nullable pointer, we might want to collapse `Result<(),~str>` into a nullable string, or we might want to collapse `Either` into 1 word, assuming that strings can never occupy the top 256 bytes of the address space. I've thought for a while that perhaps it's best to just say that the bit pattern of Rust enums is unspecified, to give us as much room as possible to play with optimizations. > Casting _to_ is permitted currently via transmute, which is probably a > fine place to leave it. I agree it'd be nice to provide an auto_enum > syntax extension that defines a bad-value condition, and produces a > .from_int() safe function that hits that condition when given a bad integer. Agreed. > >> 3. There is no way to have multiple values correspond to a single enum >> variant. > > Is there in C++? The point of this feature has always been (to my mind) > emulation of C++ where sensible. No. I guess this point is irrelevant. (Mostly I was thinking that it seems clear that we will need a syntax extension to properly support bitfields and that it is a bit odd to require a syntax extension for bitfields but to have support for explicit enum values in the language, given that they're very similar features.) Patrick From banderson at mozilla.com Fri Mar 1 13:46:58 2013 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 01 Mar 2013 13:46:58 -0800 Subject: [rust-dev] Rust on Xen In-Reply-To: References: Message-ID: <513121D2.1030603@mozilla.com> On 03/01/2013 08:37 AM, Tim Ford wrote: > The OCaml-on-Xen OpenMirage (http://openmirage.org/) project is very > interesting to me. The idea is that your OCaml application is > compiled directly into a bootable Xen microkernel image. Rather than > running inside an OS, your OCaml links to a "libOS", a library that > provides all the OS services in terms of Xen hypercalls. > > What are your thoughts regarding whether the same could be > accomplished with Rust? You'd have to reimplement the Rust runtime > and many OS services, though perhaps the work done for OpenMirage > could be of some help there. > > It seems like Rust would be a great language for this. I am interested in this. What they are doing does sound a lot like Rust and I would like us to get to the point where we can write kernel code in Rust. As Graydon mentioned though, our runtime code isn't structured to allow this yet, but we are inching closer. We probably shouldn't try to do it until after the scheduler rewrite because `core` depends on a bunch of runtime code that doesn't have a future and isn't worth porting to kernelspace. Afterword though, I expect the relationship between `core` and the scheduler to be [reversed], so that all the runtime machinery will be optional. At that point it should take just a very small platform abstraction layer to implement `core`, and we can think about the multithreading separately. [reversed]: https://github.com/mozilla/rust/issues/5157 I talked briefly with Anil (from openmirage) about this subject last year, but it would be nice to touch base again sometime. I've copied him on this thread. From siefert.david at gmail.com Fri Mar 1 21:10:58 2013 From: siefert.david at gmail.com (David Siefert) Date: Fri, 1 Mar 2013 23:10:58 -0600 Subject: [rust-dev] rust unit testing Message-ID: Hi, I'm trying to get started with rust 0.5. I've got it built and can compile+execute some simple programs. Now I want to get running with test driven development, so I just want to write, build, and run a simple unit test... according to the documentation+wiki, the following is the minimal unit test: $ cat test.rs // sample #[test] fn testFail() { fail; } And the --test option is supposed to build a harness to run everything marked with attribute #[test]: $ rustc test.rs --test test.rs:1:0: 1:0 error: unresolved name test.rs:1 // sample ^ test.rs:1:0: 1:0 error: use of undeclared module `std::test` test.rs:1 // sample ^ test.rs:1:0: 1:0 error: unresolved name: std::test::test_main test.rs:1 // sample ^ test.rs:1:0: 1:0 error: unresolved name test.rs:1 // sample ^ test.rs:1:0: 1:0 error: use of undeclared module `std::test` test.rs:1 // sample ^ test.rs:1:0: 1:0 error: use of undeclared type name `std::test::TestDesc` test.rs:1 // sample ^ Can someone point me in the right direction here? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Sat Mar 2 04:46:55 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 02 Mar 2013 07:46:55 -0500 Subject: [rust-dev] rust unit testing In-Reply-To: References: Message-ID: <5131F4BF.6070105@alum.mit.edu> You need to include "extern mod std;" at the top of your program. This will link in the standard library (as opposed to the core lib). I think that in modern versions of the compiler (i.e., the trunk) this is automatic, or at least has a better error message, but I am not sure. Niko > David Siefert > March 2, 2013 12:10 AM > Hi, > > I'm trying to get started with rust 0.5. I've got it built and can > compile+execute some simple programs. Now I want to get running with > test driven development, so I just want to write, build, and run a > simple unit test... according to the documentation+wiki, the following > is the minimal unit test: > > $ cat test.rs > // sample > #[test] > fn testFail() { > fail; > } > > And the --test option is supposed to build a harness to run everything > marked with attribute #[test]: > > $ rustc test.rs --test > test.rs:1:0: 1:0 error: unresolved name > test.rs:1 // sample > ^ > test.rs:1:0: 1:0 error: use of undeclared module `std::test` > test.rs:1 // sample > ^ > test.rs:1:0: 1:0 error: unresolved name: std::test::test_main > test.rs:1 // sample > ^ > test.rs:1:0: 1:0 error: unresolved name > test.rs:1 // sample > ^ > test.rs:1:0: 1:0 error: use of undeclared module `std::test` > test.rs:1 // sample > ^ > test.rs:1:0: 1:0 error: use of undeclared type name `std::test::TestDesc` > test.rs:1 // sample > ^ > Can someone point me in the right direction here? > > Thanks, > David > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From siefert.david at gmail.com Sat Mar 2 07:39:06 2013 From: siefert.david at gmail.com (David Siefert) Date: Sat, 2 Mar 2013 09:39:06 -0600 Subject: [rust-dev] rust unit testing In-Reply-To: <5131F4BF.6070105@alum.mit.edu> References: <5131F4BF.6070105@alum.mit.edu> Message-ID: Wow--thanks for everyone responding so quickly and helping out! This solves my problem--how can I update the documentation for at least version 0.5? Thanks, David On Sat, Mar 2, 2013 at 6:46 AM, Niko Matsakis wrote: > You need to include "extern mod std;" at the top of your program. This > will link in the standard library (as opposed to the core lib). I think > that in modern versions of the compiler (i.e., the trunk) this is > automatic, or at least has a better error message, but I am not sure. > > > Niko > > David Siefert > March 2, 2013 12:10 AM > Hi, > > I'm trying to get started with rust 0.5. I've got it built and can > compile+execute some simple programs. Now I want to get running with test > driven development, so I just want to write, build, and run a simple unit > test... according to the documentation+wiki, the following is the minimal > unit test: > > $ cat test.rs > // sample > #[test] > fn testFail() { > fail; > } > > And the --test option is supposed to build a harness to run everything > marked with attribute #[test]: > > $ rustc test.rs --test > test.rs:1:0: 1:0 error: unresolved name > test.rs:1 // sample > ^ > test.rs:1:0: 1:0 error: use of undeclared module `std::test` > test.rs:1 // sample > ^ > test.rs:1:0: 1:0 error: unresolved name: std::test::test_main > test.rs:1 // sample > ^ > test.rs:1:0: 1:0 error: unresolved name > test.rs:1 // sample > ^ > test.rs:1:0: 1:0 error: use of undeclared module `std::test` > test.rs:1 // sample > ^ > test.rs:1:0: 1:0 error: use of undeclared type name `std::test::TestDesc` > test.rs:1 // sample > ^ > Can someone point me in the right direction here? > > Thanks, > David > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From marcianx at gmail.com Sat Mar 2 10:38:59 2013 From: marcianx at gmail.com (Ashish Myles) Date: Sat, 2 Mar 2013 13:38:59 -0500 Subject: [rust-dev] How to use concat_idents! properly Message-ID: So far, I have had a difficult time finding anything definitive on this except for some rust test code. fn main() { // PART 1: works (from rust test code) let asdf_fdsa = ~"<.<"; io::println(concat_idents!(asd, f_f, dsa)); io::println(stringify!(use_mention_distinction)); // PART 2: creating a function identifier fn concat_idents!(foo, _, bar) () { // fails to compile io::println("Foo!"); } foo_bar(); // PART 3: a numeric is a bad identifier, but a good sub-identifier let asdf3 = ~">.>"; io::println(concat_idents!(asdf, 3)); // fails to compile } The first part works fine. The second part, creating a function identifier seems a perfectly valid use-case, but fails compilation, and I don't know a valid work-around. I have been unable to find a similar usage anywhere. This third part was just some wishful thinking, actually, but if there are ways to do this directly (other than changing "3" to a valid identifier like "N3"), I would love to know. (Though, this might not longer have much of a use case if/when generics eventually support integral parameters.) Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.stansifer at gmail.com Sat Mar 2 10:41:10 2013 From: paul.stansifer at gmail.com (Paul Stansifer) Date: Sat, 2 Mar 2013 13:41:10 -0500 Subject: [rust-dev] How to use concat_idents! properly In-Reply-To: References: Message-ID: `concat_idents!` is currently broken, and it's my fault. Here's a discussion of how it might be fixed in the future: https://mail.mozilla.org/pipermail/rust-dev/2013-February/003170.htmlSadly, there is no workaround. Perhaps it should be removed so that it stops confusing people? Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcianx at gmail.com Sat Mar 2 11:20:17 2013 From: marcianx at gmail.com (Ashish Myles) Date: Sat, 2 Mar 2013 14:20:17 -0500 Subject: [rust-dev] How to use concat_idents! properly In-Reply-To: References: Message-ID: On Sat, Mar 2, 2013 at 1:41 PM, Paul Stansifer wrote: > > `concat_idents!` is currently broken, and it's my fault. Here's a > discussion of how it might be fixed in the future: > https://mail.mozilla.org/pipermail/rust-dev/2013-February/003170.html Sadly, > there is no workaround. Perhaps it should be removed so that it stops > confusing people? > > Paul Thanks. So am I to understand that this is a parsing issue -- in particular concat_idents!(...) doesn't parse like an ident? If so, since macros already use "$" as special syntax for macro arguments, and there are only a handful of macro argument types, would it help for parsing if the macro argument types were made more accessible to the parser through specialized syntax? Chosen somewhat arbitrarily, one could use the following prefixes ident $$ expr $# ty $^ pat $~ block ${} so that macro arguments would be declared as $$i, $#j, $^T, etc. Then the type would be obvious to the parser and all operations between types could be language-implemented so that the parser understands the type of the expression it is dealing with. For example, concat_idents!() could be replaced by ${$$i + _ + $$j}, and the parser could happily accept it as a valid ident instead of requiring writing two macros when one should suffice. In the end, I could have something like: fn ${$$i + _ + $$j} () { io::println(ident_to_str!(${$$i + _ + $jj})) } The other types could similarly be composed: ($~p, ( $~q)) could be a composite pattern (unless patterns are already allowed to be composed to create new patterns; not checked). I couldn't come up with useful compositions of the other types that the parser would choke on. For example, it is not obvious that ident_to_str!() could be a cause for problems (for example if a string literal is expected by the parser). But if it were, $"$$i" or $"${$$i + _ + $$j}" could replace ident_to_str!($$i) or ident_to_str!(${$$i + _ + $$j}). Of course, I may be barking up the wrong tree and simply misunderstanding the underlying problem. Ashish From marcianx at gmail.com Sat Mar 2 11:29:52 2013 From: marcianx at gmail.com (Ashish Myles) Date: Sat, 2 Mar 2013 14:29:52 -0500 Subject: [rust-dev] How to use concat_idents! properly In-Reply-To: References: Message-ID: On Sat, Mar 2, 2013 at 2:20 PM, Ashish Myles wrote: > On Sat, Mar 2, 2013 at 1:41 PM, Paul Stansifer wrote: >> >> `concat_idents!` is currently broken, and it's my fault. Here's a >> discussion of how it might be fixed in the future: >> https://mail.mozilla.org/pipermail/rust-dev/2013-February/003170.html Sadly, >> there is no workaround. Perhaps it should be removed so that it stops >> confusing people? >> >> Paul > > Thanks. So am I to understand that this is a parsing issue -- in > particular concat_idents!(...) doesn't parse like an ident? If so, > since macros already use "$" as special syntax for macro arguments, > and there are only a handful of macro argument types, would it help > for parsing if the macro argument types were made more accessible to > the parser through specialized syntax? > > Chosen somewhat arbitrarily, one could use the following prefixes > ident $$ > expr $# > ty $^ > pat $~ > block ${} > so that macro arguments would be declared as $$i, $#j, $^T, etc. Then > the type would be obvious to the parser and all operations between > types could be language-implemented so that the parser understands the > type of the expression it is dealing with. > > For example, concat_idents!() could be replaced by ${$$i + _ + $$j}, > and the parser could happily accept it as a valid ident instead of > requiring writing two macros when one should suffice. In the end, I > could have something like: > fn ${$$i + _ + $$j} () { > io::println(ident_to_str!(${$$i + _ + $jj})) > } > > The other types could similarly be composed: ($~p, ( $~q)) could be a > composite pattern (unless patterns are already allowed to be composed > to create new patterns; not checked). I couldn't come up with useful > compositions of the other types that the parser would choke on. > > For example, it is not obvious that ident_to_str!() could be a cause > for problems (for example if a string literal is expected by the > parser). But if it were, $"$$i" or $"${$$i + _ + $$j}" could replace > ident_to_str!($$i) or ident_to_str!(${$$i + _ + $$j}). > > Of course, I may be barking up the wrong tree and simply > misunderstanding the underlying problem. > To allow writing general macros that return identifiers (as opposed to generating code), they could optionally be prefixed by the type they return, such as $$concat_idents!($i, _, $j) (They would also have to be defined like so.) This is, of course, going down the scary perl route to deal with parsing issues. And it might be inching closer to constexpr-like behavior. Ashish From banderson at mozilla.com Sat Mar 2 13:12:59 2013 From: banderson at mozilla.com (Brian Anderson) Date: Sat, 02 Mar 2013 13:12:59 -0800 Subject: [rust-dev] rust unit testing In-Reply-To: References: <5131F4BF.6070105@alum.mit.edu> Message-ID: <51326B5B.4030100@mozilla.com> On 03/02/2013 07:39 AM, David Siefert wrote: > Wow--thanks for everyone responding so quickly and helping out! > This solves my problem--how can I update the documentation for at > least version 0.5? > The documentation is in the markdown files in doc/, and the docs on the website are automatically updated from trunk, but we don't have any process for updating previous releases, so the 0.5 docs are pretty much set in stone at this point. From rexlen at gmail.com Sat Mar 2 16:48:36 2013 From: rexlen at gmail.com (Renato Lenzi) Date: Sun, 3 Mar 2013 01:48:36 +0100 Subject: [rust-dev] (no subject) Message-ID: Hi there. How can i cast from int to float? that is: let x = 3 let mut f = 3.0 f = f * x this doesn't work... i have to change from int to float... is this possible? Thx in advance. From pwalton at mozilla.com Sat Mar 2 16:49:11 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sat, 02 Mar 2013 16:49:11 -0800 Subject: [rust-dev] (no subject) In-Reply-To: References: Message-ID: <51329E07.6000900@mozilla.com> On 3/2/13 4:48 PM, Renato Lenzi wrote: > Hi there. > How can i cast from int to float? > that is: > let x = 3 > let mut f = 3.0 > f = f * x > > this doesn't work... i have to change from int to float... is this possible? Use `as`; e.g. `f = f * (x as float)`. Patrick From banderson at mozilla.com Sun Mar 3 20:13:03 2013 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 3 Mar 2013 20:13:03 -0800 (PST) Subject: [rust-dev] MIPS backend merged. LLVM rebuild required Message-ID: <1736998226.65921.1362370383662.JavaMail.root@mozilla.com> I just merged some very preliminary support for mips. After updating incoming your next build will have linker errors related to LLVM, and the way to fix this is with `make clean-llvm`. Good luck. https://github.com/mozilla/rust/pull/4692 From paul.stansifer at gmail.com Mon Mar 4 09:17:17 2013 From: paul.stansifer at gmail.com (Paul Stansifer) Date: Mon, 4 Mar 2013 12:17:17 -0500 Subject: [rust-dev] How to use concat_idents! properly In-Reply-To: References: Message-ID: I'm afraid it's not primarily a parsing issue; it has to do with the Rust implementation, in particular that the same AST type holds pre-expanded code (potentially containing macro invocations) and post-expanded code (in which macro invocations must not be present). Changing the identifier type to be either-an-identifier-or-a-macro-invocation-producing-an-identifier would affect way too much unrelated code. There are a number of ways around the problem, but we need to decide which one to do. Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From gwillen at nerdnet.org Mon Mar 4 09:53:50 2013 From: gwillen at nerdnet.org (Glenn Willen) Date: Mon, 4 Mar 2013 09:53:50 -0800 Subject: [rust-dev] How to use concat_idents! properly In-Reply-To: References: Message-ID: <8D2553D5-24B2-4DE2-B388-62D888923171@nerdnet.org> In the adding-macros-to-the-AST problem that keeps coming up: Does the 'unrelated' code generally run pre-macroexpansion, or post-? If the answer is 'post-macroexpansion', there may be an argument to be made for splitting the AST types apart? Glenn On Mar 4, 2013, at 9:17 AM, Paul Stansifer wrote: > I'm afraid it's not primarily a parsing issue; it has to do with the Rust implementation, in particular that the same AST type holds pre-expanded code (potentially containing macro invocations) and post-expanded code (in which macro invocations must not be present). Changing the identifier type to be either-an-identifier-or-a-macro-invocation-producing-an-identifier would affect way too much unrelated code. There are a number of ways around the problem, but we need to decide which one to do. > > Paul > !DSPAM:5134d6db129152042218820! _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > !DSPAM:5134d6db129152042218820! From paul.stansifer at gmail.com Mon Mar 4 10:36:30 2013 From: paul.stansifer at gmail.com (Paul Stansifer) Date: Mon, 4 Mar 2013 13:36:30 -0500 Subject: [rust-dev] How to use concat_idents! properly In-Reply-To: <8D2553D5-24B2-4DE2-B388-62D888923171@nerdnet.org> References: <8D2553D5-24B2-4DE2-B388-62D888923171@nerdnet.org> Message-ID: > In the adding-macros-to-the-AST problem that keeps coming up: Does the > 'unrelated' code generally run pre-macroexpansion, or post-? > > If the answer is 'post-macroexpansion', there may be an argument to be > made for splitting the AST types apart? > It is after macro expansion. However, the two AST types would be really similar to each other; you'd want to generate one from the other using macros. In fact, I attempted to do this the summer before last, but ran out of time. (It wasn't a complete waste: it helped exercise and debug the macro system.) It *might* be more practical to do it now that the macro system has improved, but it's still no small project, and I wouldn't blame anyone for vetoing making such a large change to the Rust AST out of a generally precautionary attitude. Paul > > Glenn > > On Mar 4, 2013, at 9:17 AM, Paul Stansifer wrote: > > > I'm afraid it's not primarily a parsing issue; it has to do with the > Rust implementation, in particular that the same AST type holds > pre-expanded code (potentially containing macro invocations) and > post-expanded code (in which macro invocations must not be present). > Changing the identifier type to be > either-an-identifier-or-a-macro-invocation-producing-an-identifier would > affect way too much unrelated code. There are a number of ways around the > problem, but we need to decide which one to do. > > > > Paul > > !DSPAM:5134d6db129152042218820! > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > !DSPAM:5134d6db129152042218820! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clements at brinckerhoff.org Mon Mar 4 13:53:16 2013 From: clements at brinckerhoff.org (John Clements) Date: Mon, 4 Mar 2013 13:53:16 -0800 Subject: [rust-dev] rust unit testing In-Reply-To: <5131F4BF.6070105@alum.mit.edu> References: <5131F4BF.6070105@alum.mit.edu> Message-ID: On Mar 2, 2013, at 4:46 AM, Niko Matsakis wrote: > You need to include "extern mod std;" at the top of your program. This will link in the standard library (as opposed to the core lib). I think that in modern versions of the compiler (i.e., the trunk) this is automatic, or at least has a better error message, but I am not sure. As an every-every-day user of unit testing, I can confirm that in more recent versions of Rust (e.g. the upcoming 0.6 and the github "incoming" branch), this "extern mod std;" is not required. John Clements From pshagl007 at gmail.com Tue Mar 5 02:59:04 2013 From: pshagl007 at gmail.com (piyush agarwal) Date: Tue, 5 Mar 2013 16:29:04 +0530 Subject: [rust-dev] Query Related to enum Message-ID: Hi, I have a enum for example enum A{ a = 0, b = 1, c = 2 } what I want is :- when I pass '2' , I can get c from it. Is there some built-in for this or some other way. Thanks, Piyush -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh4.seo at samsung.com Tue Mar 5 03:09:10 2013 From: sh4.seo at samsung.com (Sanghyeon Seo) Date: Tue, 05 Mar 2013 11:09:10 +0000 (GMT) Subject: [rust-dev] Query Related to enum Message-ID: <3549245.227721362481749978.JavaMail.weblogic@epml09> > enum A { > a = 0, > b = 1, > c = 2 > } > > What I want is when I pass 2, I get c from it. > Is there some built-in for this or some other way. This is issue #2132 and there is no completely satisfactory answer yet. https://github.com/mozilla/rust/issues/2132 You can use unsafe code (case::transmute), or you can do pattern matching: match number { 0 => a, 1 => b, 2 => c, _ => fail!() } From duddlf.choi at samsung.com Tue Mar 5 04:16:57 2013 From: duddlf.choi at samsung.com (=?euc-kr?B?w9a/tcDP?=) Date: Tue, 05 Mar 2013 12:16:57 +0000 (GMT) Subject: [rust-dev] query about libc.rs Message-ID: <17350897.228101362485817008.JavaMail.weblogic@epml22> I am investigating libc.rs libc::types::common::c95::... libc::types::common::posix88::... where these naming convention hierachy comes from ? and what is the difference between c95, posix01, posix88 ? From graydon at mozilla.com Tue Mar 5 08:28:46 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 05 Mar 2013 08:28:46 -0800 Subject: [rust-dev] query about libc.rs In-Reply-To: <17350897.228101362485817008.JavaMail.weblogic@epml22> References: <17350897.228101362485817008.JavaMail.weblogic@epml22> Message-ID: <51361D3E.7040006@mozilla.com> On 05/03/2013 4:16 AM, ??? wrote: > > I am investigating libc.rs > > libc::types::common::c95::... > libc::types::common::posix88::... > > where these naming convention hierachy comes from ? > and what is the difference between c95, posix01, posix88 ? There's a large block comment at the top of the file that explains the source documents. The names are picked as abbreviations for the full document names: c95 == "ISO 9899:1990 ('C95', 'ANSI C', 'Standard C'), NA1, 1995." (note: NA1 -- "normative annex #1" -- was approved in 1995) posix88 == "ISO 9945:1988 / IEEE 1003.1-1988 ('POSIX.1')." posix01 == "ISO 9945:2001 / IEEE 1003.1-2001 ('POSIX:2001', 'SUSv3')." and so forth. bsd44 is, as the comment mentions, a collection of auxiliary material that roughly corresponds to the 4.4 BSD release that is the source of most BSD-derived unixes we see today. The point of the module hierarchy in libc.rs is to make it somewhat reasonable for a single over-taxed maintainer (me) to read through standards documents and reference manuals and write down what I see in those documents, _then_ go to each platform and look for the corresponding definitions in each header file or reference manual. The alternative strategy is to start from the header files I find on a given platform and transcribe "everything", trying to guess which features are enabled or disabled on which versions or flags, which features are mandatory or optional, which conform to standards or deviate from them, etc. This latter strategy was how I initially approached writing libc interfaces, and it was very difficult, as each symbol in each operating system header (at this low level) is guarded by multiple CPP ifdef-guards and frequently several levels of indirect typedefs and inclusions of many additional files. It gets quite difficult to tell "which symbols actually exist, or are supposed to exist, on each platform", and to what degree their current values are accidental or defined by-reference to some other value that is the more-normative / more platform-agnostic / more arch-agnostic one. It's much easier (in my experience so far) to understand each platform and architecture in terms of "figuring out which standards the platform claims to conform to and how it depends on its arch", and then picking out the definitions _for those standards_, usually one at a time. It is also much easier (IME so far) to split apart the 3 separate categories within each standard: 1. "things that vary by OS" 2. "things that vary by architecture, even within a single OS" 3. "things that are OS and architecture neutral" and avoid duplicating definitions when possible. Notice for example that the constants tend to be architecture neutral and a great many of the functions are both OS and architecture neutral (though not all -- this varies by spec). It also makes it more reasonable for the libc _user_ (not usually a direct rust programmer, but a higher-level abstraction module such as os.rs) to write code to interfaces that are "more widely available" by picking modules in libc that are older and more widely supported. For example, writing to the c95 module _alone_ will guarantee a program can run on windows and linux. This is surprising, but true: windows actually supports the full c95 spec worth of interfaces in their msvcrt.dll runtime library. They do _not_ support most of the rest of the bsd or posix interfaces. Only a random subset (with many symbols doing "slightly different things" than in posix). So far, despite the organization being _cluttered_ -- which I freely admit, it's a bit overwhelming at first -- I've found this organization of libc to be much much easier to _maintain_ and get _correct_ than the alternative we had before, of "one module for each OS containing all definitions". In that case we had lots of both duplication, missing definitions and simple _bugs_ / incorrect definitions between modules. -Graydon From sh4.seo at samsung.com Tue Mar 5 10:23:59 2013 From: sh4.seo at samsung.com (Sanghyeon Seo) Date: Tue, 05 Mar 2013 18:23:59 +0000 (GMT) Subject: [rust-dev] minmax Message-ID: <29075402.231241362507839082.JavaMail.weblogic@epml09> core::iter includes min and max, so I decided to implement minmax which does 1.5 comparisons per element instead of 2 comparisons. Here is the result: https://gist.github.com/sanxiyn/5092643 It seems to work, but I couldn't figure out how to put this in core::iter, using BaseIter instead of &[T]. Any idea? Also, why can't I use < to compare Option even if Option implements Ord for T: Ord? Also, is there a better way to do this, other than using a state machine? From ben.striegel at gmail.com Tue Mar 5 13:46:59 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 5 Mar 2013 16:46:59 -0500 Subject: [rust-dev] minmax In-Reply-To: <29075402.231241362507839082.JavaMail.weblogic@epml09> References: <29075402.231241362507839082.JavaMail.weblogic@epml09> Message-ID: > Also, why can't I use < to compare Option even if Option > implements Ord for T: Ord? I actually implemented something like this back in December, that enabled you to use + on any two options as long as their types also implemented +. But... I forgot to send it upstream. :) I'll revive it later today, and do the same for < and friends. On Tue, Mar 5, 2013 at 1:23 PM, Sanghyeon Seo wrote: > core::iter includes min and max, so I decided to implement minmax > which does 1.5 comparisons per element instead of 2 comparisons. > > Here is the result: > https://gist.github.com/sanxiyn/5092643 > > It seems to work, but I couldn't figure out how to put this in core::iter, > using BaseIter instead of &[T]. Any idea? > > Also, why can't I use < to compare Option even if Option > implements Ord for T: Ord? > > Also, is there a better way to do this, other than using a state machine? > _______________________________________________ > 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 ryan.choi at samsung.com Tue Mar 5 20:42:21 2013 From: ryan.choi at samsung.com (Ryan Hyun Choi) Date: Wed, 06 Mar 2013 04:42:21 +0000 (GMT) Subject: [rust-dev] A question about using uint::range_rev() Message-ID: <8798397.492601362544940833.JavaMail.weblogic@epml01> Hi all, I have a quick question about using uint::range_rev(). I'd like to express a for statement that decrements an uint value to 0. However I cannot use the below statement, because uint::range_rev(i,j) computes values in the range [i,j). for uint::range_rev(10,0) |i| { // do something } Sure I can express the statement using a combination of a while loop and an if statment, but is there a compact (or Rust) way of expressing i,..,j? Also, I think type casting to int, use int::range(i,-1), and type cast back to uint is only tricking the compiler. Thanks a lot. Regards, Ryan ---- Ryan Hyun Choi Senior Engineer Web Platform Lab. Software R&D Center Samsung Electronics Co., Ltd email: ryan.choi at samsung.com From ben.striegel at gmail.com Tue Mar 5 21:55:11 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 6 Mar 2013 00:55:11 -0500 Subject: [rust-dev] A question about using uint::range_rev() In-Reply-To: <8798397.492601362544940833.JavaMail.weblogic@epml01> References: <8798397.492601362544940833.JavaMail.weblogic@epml01> Message-ID: Hm, well that's unfortunate... I think that range_rev might just need to be rewritten to get the values in (i, j] rather than [i, j). On Tue, Mar 5, 2013 at 11:42 PM, Ryan Hyun Choi wrote: > Hi all, > > I have a quick question about using uint::range_rev(). > I'd like to express a for statement that decrements an uint value to 0. > However I cannot use the below statement, because uint::range_rev(i,j) > computes > values in the range [i,j). > > for uint::range_rev(10,0) |i| { > // do something > } > > Sure I can express the statement using a combination of a while loop and > an if statment, > but is there a compact (or Rust) way of expressing i,..,j? Also, I think > type casting to int, use int::range(i,-1), > and type cast back to uint is only tricking the compiler. > > Thanks a lot. > > Regards, > Ryan > > > ---- > Ryan Hyun Choi > Senior Engineer > Web Platform Lab. > Software R&D Center > Samsung Electronics Co., Ltd > email: ryan.choi at samsung.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 niko at alum.mit.edu Wed Mar 6 05:45:45 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 06 Mar 2013 08:45:45 -0500 Subject: [rust-dev] A question about using uint::range_rev() In-Reply-To: References: <8798397.492601362544940833.JavaMail.weblogic@epml01> Message-ID: <51374889.8080606@alum.mit.edu> Yeah, I'm inclined to agree. Niko > Benjamin Striegel > March 6, 2013 12:55 AM > Hm, well that's unfortunate... > > I think that range_rev might just need to be rewritten to get the > values in (i, j] rather than [i, j). > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > Ryan Hyun Choi > March 5, 2013 11:42 PM > Hi all, > > I have a quick question about using uint::range_rev(). > I'd like to express a for statement that decrements an uint value to 0. > However I cannot use the below statement, because uint::range_rev(i,j) > computes > values in the range [i,j). > > for uint::range_rev(10,0) |i| { > // do something > } > > Sure I can express the statement using a combination of a while loop > and an if statment, > but is there a compact (or Rust) way of expressing i,..,j? Also, I > think type casting to int, use int::range(i,-1), > and type cast back to uint is only tricking the compiler. > > Thanks a lot. > > Regards, > Ryan > > > ---- > Ryan Hyun Choi > Senior Engineer > Web Platform Lab. > Software R&D Center > Samsung Electronics Co., Ltd > email: ryan.choi at samsung.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: -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From o.renaud at gmx.fr Wed Mar 6 06:50:08 2013 From: o.renaud at gmx.fr (Olivier Renaud) Date: Wed, 06 Mar 2013 15:50:08 +0100 Subject: [rust-dev] Re : Re: A question about using uint::range_rev() Message-ID: <20130306145008.97670@gmx.com> Hi, Would it be possible to leverage the macro system, so that a range can be expressed using an intuitive syntax ? Something like : for range!(0 <= x < size) { io::print(x); } or for range!(10 > v >= 0) { io::print(v); } ----- Message d'origine ----- De : Niko Matsakis Envoy?s : 06.03.13 14:45 ? : Benjamin Striegel Objet : Re: [rust-dev] A question about using uint::range_rev() Yeah, I'm inclined to agree. Niko ben.striegel at gmail.com March 6, 2013 12:55 AM Hm, well that's unfortunate... I think that range_rev might just need to be rewritten to get the values in (i, j] rather than [i, j). _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev ryan.choi at samsung.com March 5, 2013 11:42 PM Hi all, I have a quick question about using uint::range_rev(). I'd like to express a for statement that decrements an uint value to 0. However I cannot use the below statement, because uint::range_rev(i,j) computes values in the range [i,j). for uint::range_rev(10,0) |i| { // do something } Sure I can express the statement using a combination of a while loop and an if statment, but is there a compact (or Rust) way of expressing i,..,j? Also, I think type casting to int, use int::range(i,-1), and type cast back to uint is only tricking the compiler. Thanks a lot. Regards, Ryan ---- Ryan Hyun Choi Senior Engineer Web Platform Lab. Software R&D Center Samsung Electronics Co., Ltd email: ryan.choi at samsung.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: -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From niko at alum.mit.edu Wed Mar 6 07:55:02 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 06 Mar 2013 10:55:02 -0500 Subject: [rust-dev] Re : Re: A question about using uint::range_rev() In-Reply-To: <20130306145008.97670@gmx.com> References: <20130306145008.97670@gmx.com> Message-ID: <513766D6.9050008@alum.mit.edu> I think it'd have to be something like: ``` for_range!(0 <= x < size, { }) ``` Because the fragment `range(x, y) |x|` you're trying to replace is not an expression. Niko > Olivier Renaud > March 6, 2013 9:50 AM > Hi, > Would it be possible to leverage the macro system, so that a range can > be expressed using an intuitive syntax ? > Something like : > for range!(0 <= x < size) { > io::print(x); > } > or > > for range!(10 > v >= 0) { > io::print(v); > } > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From anil at recoil.org Sun Mar 10 04:03:28 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Sun, 10 Mar 2013 11:03:28 +0000 Subject: [rust-dev] Rust on Xen In-Reply-To: <513121D2.1030603@mozilla.com> Message-ID: <20130310110328.GI17918@dark.recoil.org> On Fri, Mar 01, 2013 at 01:46:58PM -0800, Brian Anderson wrote: > On 03/01/2013 08:37 AM, Tim Ford wrote: > >The OCaml-on-Xen OpenMirage (http://openmirage.org/) project is > >very interesting to me. The idea is that your OCaml application > >is compiled directly into a bootable Xen microkernel image. > >Rather than running inside an OS, your OCaml links to a "libOS", a > >library that provides all the OS services in terms of Xen > >hypercalls. > > > >What are your thoughts regarding whether the same could be > >accomplished with Rust? You'd have to reimplement the Rust > >runtime and many OS services, though perhaps the work done for > >OpenMirage could be of some help there. > > > >It seems like Rust would be a great language for this. > > I am interested in this. What they are doing does sound a lot like > Rust and I would like us to get to the point where we can write > kernel code in Rust. As Graydon mentioned though, our runtime code > isn't structured to allow this yet, but we are inching closer. We > probably shouldn't try to do it until after the scheduler rewrite > because `core` depends on a bunch of runtime code that doesn't have > a future and isn't worth porting to kernelspace. Afterword though, I > expect the relationship between `core` and the scheduler to be > [reversed], so that all the runtime machinery will be optional. At > that point it should take just a very small platform abstraction > layer to implement `core`, and we can think about the multithreading > separately. > > [reversed]: https://github.com/mozilla/rust/issues/5157 > > I talked briefly with Anil (from openmirage) about this subject last > year, but it would be nice to touch base again sometime. I've copied > him on this thread. We've been doing a bunch of work to make it easier to share unikernel code between different languages. Most of this is in the Xen control stack, where having a low-latency VM interface makes it easier to spawn virtual machines on-demand (instead of the seconds it currently takes in many cases). As for the actual runtimes, we've taken an extreme position in Mirage to strip away much of the C code: - cooperative threading in OCaml, with everything boiling down to a single Xen domain poll. No preemptive threading at all means that the runtime is extremely simple, but the only way to get parallelism is via multiple virtual machines. - support for 1 vCPU only. For many services such as HTTP, it's easier to spawn multiple single-vCPU VMs than it is to deal with multi-vCPU scheduling. - compile-time specialisation to let configuration directives be compiled directly into the application. Most of the Mirage libraries are 'policy-free', and the application glues it all together. This giives us a lot of flexibility when building applications, but makes the build system much more complicated. We're building a system called 'Mirari' which hides much of the build-time complexity via a config DSL, though: http://github.com/mirage/mirari - C bindings are mostly banned, which means that we've had to reimplement most protocols in pure OCaml (including device drivers). The huge upside to this is that we can get rid of almost all of the usual embedded libC. We only require a malloc and printf implementation at the moment, and should be able to get rid of the latter quite soon with a smarter Printf library. All of these restrictions can be relaxed, at the expense of greater complexity in the runtime. I imagine that's where a lot of the interoperability will come in: start with a non-preemptive boot library, add on threading support, and then bits of libC. It should be quite easy to build a multi-language unikernel that calls back from the OCaml boot+TCP stack into the Rust runtime. See this GSoC proposal: http://wiki.xen.org/wiki/GSoC_2013#Towards_a_multi-language_unikernel_substrate_for_Xen Also Xenopsd, which is the simple toolstack that Dave Scott is working on at Citrix: http://wiki.xen.org/wiki/Xenopsd You can also read more information about Mirage in the upcoming ASPLOS 2013 paper: http://anil.recoil.org/papers/2013-asplos-mirage.pdf cheers, -- Anil Madhavapeddy http://anil.recoil.org From jgabriele at fastmail.fm Sun Mar 10 17:48:14 2013 From: jgabriele at fastmail.fm (John Gabriele) Date: Sun, 10 Mar 2013 17:48:14 -0700 Subject: [rust-dev] Android apps in Rust? Message-ID: <1362962894.404.140661202566813.3ED328DB@webmail.messagingengine.com> Hi all, (2nd time sending this --- first time doesn't seem to have gone through.) What are the prospects of creating Android apps using Rust? Any plans for / interest in supporting this? I see there's a rust wiki page re. building for Android... How would such a setup work? Would JNI be involved? The NDK? Thanks! -- John Gabriele jgabriele at fastmail.fm From ysoo.son at samsung.com Mon Mar 11 00:36:05 2013 From: ysoo.son at samsung.com (=?euc-kr?B?vNW/tbz2?=) Date: Mon, 11 Mar 2013 07:36:05 +0000 (GMT) Subject: [rust-dev] A question about using condition Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201303111636305_QKNMBDIF.gif Type: image/gif Size: 14036 bytes Desc: not available URL: From banderson at mozilla.com Mon Mar 11 11:42:11 2013 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 11 Mar 2013 11:42:11 -0700 Subject: [rust-dev] Android apps in Rust? In-Reply-To: <1362962894.404.140661202566813.3ED328DB@webmail.messagingengine.com> References: <1362962894.404.140661202566813.3ED328DB@webmail.messagingengine.com> Message-ID: <513E2583.2040507@mozilla.com> On 03/10/2013 05:48 PM, John Gabriele wrote: > Hi all, > > (2nd time sending this --- first time doesn't seem to have gone > through.) > > What are the prospects of creating Android apps using Rust? Any plans > for / interest in supporting this? > > I see there's a rust wiki page re. building for Android... > > How would such a setup work? Would JNI be involved? The NDK? > > Thanks! > Yes. There is an ongoing effort to port Rust to Android and I'm sure help would be welcomed. I don't know in what timeframe you can expect to write graphical Android applications but following the instructions you found one can already run simple Rust executables on Android. The NDK will be required to build the compiler and standard libraries and, at least for now, to run the linker. You'll call Rust code through the JNI, but exactly how this will work isn't known yet. Here are the Android issues if you want to follow: https://github.com/mozilla/rust/issues?labels=A-android&page=1&state=open From jgabriele at fastmail.fm Mon Mar 11 12:35:17 2013 From: jgabriele at fastmail.fm (John Gabriele) Date: Mon, 11 Mar 2013 12:35:17 -0700 Subject: [rust-dev] Android apps in Rust? In-Reply-To: <513E2583.2040507@mozilla.com> References: <1362962894.404.140661202566813.3ED328DB@webmail.messagingengine.com> <513E2583.2040507@mozilla.com> Message-ID: <1363030517.28706.140661202957017.04C8C700@webmail.messagingengine.com> On Mon, Mar 11, 2013, at 11:42 AM, Brian Anderson wrote: > > Yes. There is an ongoing effort to port Rust to Android and I'm sure > help would be welcomed. I don't know in what timeframe you can expect to > write graphical Android applications but following the instructions you > found one can already run simple Rust executables on Android. The NDK > will be required to build the compiler and standard libraries and, at > least for now, to run the linker. You'll call Rust code through the JNI, > but exactly how this will work isn't known yet. > > Here are the Android issues if you want to follow: > > https://github.com/mozilla/rust/issues?labels=A-android&page=1&state=open Thanks for the info and the link, Brian! ---John From ysoo.son at samsung.com Mon Mar 11 17:57:19 2013 From: ysoo.son at samsung.com (=?euc-kr?B?vNW/tbz2?=) Date: Tue, 12 Mar 2013 00:57:19 +0000 (GMT) Subject: [rust-dev] A question about using condition Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201303120957297_44YDXKW4.gif Type: image/gif Size: 14036 bytes Desc: not available URL: From graydon at mozilla.com Mon Mar 11 20:31:19 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 11 Mar 2013 20:31:19 -0700 Subject: [rust-dev] A question about using condition In-Reply-To: References: Message-ID: <513EA187.1020805@mozilla.com> On 11/03/2013 5:57 PM, ??? wrote: > Hi, > > > > I have a question about using condition. > > I'd like to define a condition as borrowed pointer type because raising > an exception with a message. > > However I don't know how to use it. Is it possible? Unfortunately not; due to a limitation of type parameters (they do not carry lifetime bounds) the method we used to implement conditions does not support passing values to a condition handler by borrowed pointer. We may work around it at some point; there are a few possibilities that might work but none of them are terribly appealing. For the time being you need to pass values to conditions by value or by owning or managed pointers. -Graydon From jack.lloyd at gmail.com Tue Mar 12 10:07:07 2013 From: jack.lloyd at gmail.com (Jack Lloyd) Date: Tue, 12 Mar 2013 13:07:07 -0400 Subject: [rust-dev] Order of evaluation of struct initializers Message-ID: If two or more struct initializers have side effects, is the order that they run defined? Testing with the code below and Rust 0.5 seems to show that the order of evaluation is the order that the initialization occurs in (eg swapping the order of len and val in packet_read causes get_u16 to be called first). However I could not find this behavior mentioned in the manual and before I relied on it I wanted to make sure those semantics were stable and not just a quirk of the implementation. Thanks, Jack Example follows fn get_u8() -> u8 { io::println("get_u8"); 42 } fn get_u16() -> u16 { io::println("get_u16"); 31337 } struct Packet { len: u8, val: u16 } fn packet_read() -> Packet { Packet { // swap next two lines to swap order of evaluation len: get_u8(), val: get_u16(), } } fn main() { let _p = packet_read(); } From marijnh at gmail.com Tue Mar 12 10:44:47 2013 From: marijnh at gmail.com (Marijn Haverbeke) Date: Tue, 12 Mar 2013 18:44:47 +0100 Subject: [rust-dev] Order of evaluation of struct initializers In-Reply-To: References: Message-ID: There is code in the compiler explicitly making sure initializers run in source order, and I expect it will stay that way. So I guess this should be mentioned in the documentation as being something you can rely on. Best, Marijn From graydon at mozilla.com Tue Mar 12 12:44:55 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 12 Mar 2013 12:44:55 -0700 Subject: [rust-dev] const, static, global, mut, syntax! Message-ID: <513F85B7.2090908@mozilla.com> Hi, At today's meeting we had a a discussion about two issues that intersect, oddly, at a particular point of the syntax. The two issues are: - Removing the 'static lifetime-name -- currently used to denote the lifetime of consts -- since the only other use of the word (static fn ...) is going away when we finish with explicit-self; renaming it (probably) to 'const since that's the word used to introduce consts! - Adding mutable globals (unsafe-to-access, but needed in some corner cases for mutexes and such). This is an old bug (two years! https://github.com/mozilla/rust/issues/553 ) that we've long assumed we'd have to implement eventually. We agreed to do the former (rename 'static to 'const) and collapse all uses of the word "const" to mean this "read-only-memory" thing. But then when pushing around possible syntaxes for mutable globals, such as the following not-so-charming options: let mut x : T = v; // like in functions, but different since the RHS must be a const and can refer to values declared-after it. const mut x : T = v; // adding a modifier to 'const' but one that reads somewhat absurdly: "constant mutable"? unsafe mut x : T = v; // more random choices... We stumbled on the _opposite_ possibility for const-vs-static: maybe we should be retiring the "const" keyword and standardizing on "static", for both mutable and immutable. The following cases would then fall out: static x : T = v; // constant init, immutable, like const today static mut x : T = v; // constant init, mutable, unsafe to access With values in that scope having 'static lifetime, and the word "const" no longer appearing anywhere in the language. There are other options, probably, that we did not consider. Some people suggested putting "global" in there instead of "static". Some suggested going back to "var" rather than "let". This is an intentional (brief) request for a little syntax bikeshed-discussion to see if anything else occurs to anyone, or if anyone has strong reactions / preferences / thoughts to any of the above options. We recognize that this does not _exactly_ align with the meanings of the highly-overloaded words "const" or "static" in C/C++, but think that there's some keyword and concept overlap here that can probably be minimized. (Maybe reply for only a couple days and we'll summarize opinions and pick something thereafter. No need for it to drag on forever.) Thanks, -Graydon From illissius at gmail.com Tue Mar 12 13:21:38 2013 From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Tue, 12 Mar 2013 21:21:38 +0100 Subject: [rust-dev] const, static, global, mut, syntax! In-Reply-To: <513F85B7.2090908@mozilla.com> References: <513F85B7.2090908@mozilla.com> Message-ID: Bikeshed wheeee! The connotations/meanings I associate to these words are: const => constant, doesn't change / can't be changed static => statically known (usually "without running it", like in static types vs. dynamic types, static analysis, etc.) The desired meaning here seems to be "statically allocated". So I would go with static. Close enough! The equivalent in Rust for const as above is basically "not mut". As long as globals were forced to be immutable (constant) the two meanings overlapped, so there wasn't any glaring problem (maybe some subtle redundancy), but once you let them be mut the conflict is obvious. On Tue, Mar 12, 2013 at 8:44 PM, Graydon Hoare wrote: > Hi, > > At today's meeting we had a a discussion about two issues that > intersect, oddly, at a particular point of the syntax. The two issues are: > > - Removing the 'static lifetime-name -- currently used to denote > the lifetime of consts -- since the only other use of the word > (static fn ...) is going away when we finish with explicit-self; > renaming it (probably) to 'const since that's the word used to > introduce consts! > > - Adding mutable globals (unsafe-to-access, but needed in some > corner cases for mutexes and such). This is an old bug > (two years! https://github.com/mozilla/rust/issues/553 ) that > we've long assumed we'd have to implement eventually. > > We agreed to do the former (rename 'static to 'const) and collapse all > uses of the word "const" to mean this "read-only-memory" thing. But then > when pushing around possible syntaxes for mutable globals, such as the > following not-so-charming options: > > let mut x : T = v; // like in functions, but different since > the RHS must be a const and can refer to > values declared-after it. > > const mut x : T = v; // adding a modifier to 'const' but one that > reads somewhat absurdly: "constant mutable"? > > unsafe mut x : T = v; // more random choices... > > We stumbled on the _opposite_ possibility for const-vs-static: maybe we > should be retiring the "const" keyword and standardizing on "static", > for both mutable and immutable. The following cases would then fall out: > > static x : T = v; // constant init, immutable, like const today > > static mut x : T = v; // constant init, mutable, unsafe to access > > With values in that scope having 'static lifetime, and the word "const" > no longer appearing anywhere in the language. > > There are other options, probably, that we did not consider. Some people > suggested putting "global" in there instead of "static". Some suggested > going back to "var" rather than "let". > > This is an intentional (brief) request for a little syntax > bikeshed-discussion to see if anything else occurs to anyone, or if > anyone has strong reactions / preferences / thoughts to any of the above > options. We recognize that this does not _exactly_ align with the > meanings of the highly-overloaded words "const" or "static" in C/C++, > but think that there's some keyword and concept overlap here that can > probably be minimized. > > (Maybe reply for only a couple days and we'll summarize opinions and > pick something thereafter. No need for it to drag on forever.) > > Thanks, > > -Graydon > _______________________________________________ > 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 ben.striegel at gmail.com Tue Mar 12 14:13:51 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Tue, 12 Mar 2013 17:13:51 -0400 Subject: [rust-dev] const, static, global, mut, syntax! In-Reply-To: <513F85B7.2090908@mozilla.com> References: <513F85B7.2090908@mozilla.com> Message-ID: I'll speak up in favor of ditching both "const" and "static" for "global". global foo: int = 1; global mut bar: int = 1; &'global baz (Though not sure exactly what the 'static region is, does that last one make sense?) On Tue, Mar 12, 2013 at 3:44 PM, Graydon Hoare wrote: > Hi, > > At today's meeting we had a a discussion about two issues that > intersect, oddly, at a particular point of the syntax. The two issues are: > > - Removing the 'static lifetime-name -- currently used to denote > the lifetime of consts -- since the only other use of the word > (static fn ...) is going away when we finish with explicit-self; > renaming it (probably) to 'const since that's the word used to > introduce consts! > > - Adding mutable globals (unsafe-to-access, but needed in some > corner cases for mutexes and such). This is an old bug > (two years! https://github.com/mozilla/rust/issues/553 ) that > we've long assumed we'd have to implement eventually. > > We agreed to do the former (rename 'static to 'const) and collapse all > uses of the word "const" to mean this "read-only-memory" thing. But then > when pushing around possible syntaxes for mutable globals, such as the > following not-so-charming options: > > let mut x : T = v; // like in functions, but different since > the RHS must be a const and can refer to > values declared-after it. > > const mut x : T = v; // adding a modifier to 'const' but one that > reads somewhat absurdly: "constant mutable"? > > unsafe mut x : T = v; // more random choices... > > We stumbled on the _opposite_ possibility for const-vs-static: maybe we > should be retiring the "const" keyword and standardizing on "static", > for both mutable and immutable. The following cases would then fall out: > > static x : T = v; // constant init, immutable, like const today > > static mut x : T = v; // constant init, mutable, unsafe to access > > With values in that scope having 'static lifetime, and the word "const" > no longer appearing anywhere in the language. > > There are other options, probably, that we did not consider. Some people > suggested putting "global" in there instead of "static". Some suggested > going back to "var" rather than "let". > > This is an intentional (brief) request for a little syntax > bikeshed-discussion to see if anything else occurs to anyone, or if > anyone has strong reactions / preferences / thoughts to any of the above > options. We recognize that this does not _exactly_ align with the > meanings of the highly-overloaded words "const" or "static" in C/C++, > but think that there's some keyword and concept overlap here that can > probably be minimized. > > (Maybe reply for only a couple days and we'll summarize opinions and > pick something thereafter. No need for it to drag on forever.) > > Thanks, > > -Graydon > _______________________________________________ > 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 mozilla at mcpherrin.ca Tue Mar 12 14:37:45 2013 From: mozilla at mcpherrin.ca (Matthew McPherrin) Date: Tue, 12 Mar 2013 17:37:45 -0400 Subject: [rust-dev] const, static, global, mut, syntax! In-Reply-To: References: <513F85B7.2090908@mozilla.com> Message-ID: I like 'static' more than 'global' or 'const' for lifetime names, and I agree that const and static should be unified into a single name. 'static' scares me a bit because of C's use of it in several somewhat unrelated contexts, and so the name feels a bit polluted in my mind. But I still like it best. On Tue, Mar 12, 2013 at 5:13 PM, Benjamin Striegel wrote: > I'll speak up in favor of ditching both "const" and "static" for "global". > > global foo: int = 1; > global mut bar: int = 1; > &'global baz > > (Though not sure exactly what the 'static region is, does that last one make > sense?) > > > On Tue, Mar 12, 2013 at 3:44 PM, Graydon Hoare wrote: >> >> Hi, >> >> At today's meeting we had a a discussion about two issues that >> intersect, oddly, at a particular point of the syntax. The two issues are: >> >> - Removing the 'static lifetime-name -- currently used to denote >> the lifetime of consts -- since the only other use of the word >> (static fn ...) is going away when we finish with explicit-self; >> renaming it (probably) to 'const since that's the word used to >> introduce consts! >> >> - Adding mutable globals (unsafe-to-access, but needed in some >> corner cases for mutexes and such). This is an old bug >> (two years! https://github.com/mozilla/rust/issues/553 ) that >> we've long assumed we'd have to implement eventually. >> >> We agreed to do the former (rename 'static to 'const) and collapse all >> uses of the word "const" to mean this "read-only-memory" thing. But then >> when pushing around possible syntaxes for mutable globals, such as the >> following not-so-charming options: >> >> let mut x : T = v; // like in functions, but different since >> the RHS must be a const and can refer to >> values declared-after it. >> >> const mut x : T = v; // adding a modifier to 'const' but one that >> reads somewhat absurdly: "constant mutable"? >> >> unsafe mut x : T = v; // more random choices... >> >> We stumbled on the _opposite_ possibility for const-vs-static: maybe we >> should be retiring the "const" keyword and standardizing on "static", >> for both mutable and immutable. The following cases would then fall out: >> >> static x : T = v; // constant init, immutable, like const today >> >> static mut x : T = v; // constant init, mutable, unsafe to access >> >> With values in that scope having 'static lifetime, and the word "const" >> no longer appearing anywhere in the language. >> >> There are other options, probably, that we did not consider. Some people >> suggested putting "global" in there instead of "static". Some suggested >> going back to "var" rather than "let". >> >> This is an intentional (brief) request for a little syntax >> bikeshed-discussion to see if anything else occurs to anyone, or if >> anyone has strong reactions / preferences / thoughts to any of the above >> options. We recognize that this does not _exactly_ align with the >> meanings of the highly-overloaded words "const" or "static" in C/C++, >> but think that there's some keyword and concept overlap here that can >> probably be minimized. >> >> (Maybe reply for only a couple days and we'll summarize opinions and >> pick something thereafter. No need for it to drag on forever.) >> >> Thanks, >> >> -Graydon >> _______________________________________________ >> 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 thadguidry at gmail.com Tue Mar 12 18:02:13 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Tue, 12 Mar 2013 20:02:13 -0500 Subject: [rust-dev] const, static, global, mut, syntax! In-Reply-To: <513F85B7.2090908@mozilla.com> References: <513F85B7.2090908@mozilla.com> Message-ID: History: Static comes from the Greek "statikos" meaning fixed or unmoving. More History: Static memory or Dynamic memory (same for accesses) has been used since 1959+ TIP: Avoid overloading at all costs (the bane of other ill conceived programming languages) It sounds like everyone is really just trying to come up with a term that denotes a "lifetime" of a variable were that variable could also have many altered states 2 of which being "mutable" or "immutable" or even sets of states down the line ? So other choices are: fixed firm stable survive(d) aged living (not dead yet) live (still not dead yet) bound If your talking about coming up with a term that denotes a "scope" of a variable, then your choices are ... global Completely depends on what your really trying to denote or define. -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Tue Mar 12 21:36:54 2013 From: leebraid at gmail.com (Lee Braiden) Date: Wed, 13 Mar 2013 04:36:54 +0000 Subject: [rust-dev] const, static, global, mut, syntax! Message-ID: <7bkp5f9osou48owpvdeswm16.1363147450452@email.android.com> I think the problem is that three different things are needed, and that these need different (often pre-existing) keywords (or defaults). I'd suggest: * Global storage by default for consts * Promotion to global storage where possible and useful, for const and immutable values * A "shared" keyword for globally (or perhaps parent threadgroup- ?) visible variables, ?with atomic access by default, for the level of item defined (int, struct, etc.) * An "unsafe" keyword, used in "unsafe shared" to get what C programmers call "global". * PERHAPS some sort of Lockable interface, supporting acquire() and release(), for custom, "shared" aggregates which ned more granular locking control. --? Lee -------- Original message -------- From: Thad Guidry Date: To: Graydon Hoare Cc: rust-dev at mozilla.org Subject: Re: [rust-dev] const, static, global, mut, syntax! History: Static comes from the Greek "statikos" meaning fixed or unmoving. More History: Static memory or Dynamic memory (same for accesses) has been used since 1959+ TIP: Avoid overloading at all costs (the bane of other ill conceived programming languages) It sounds like everyone is really just trying to come up with a term that denotes a "lifetime" of a variable were that variable could also have many altered states 2 of which being "mutable" or "immutable" or even sets of states down the line ? So other choices are: fixed firm stable survive(d) aged living (not dead yet) live (still not dead yet) bound If your talking about coming up with a term that denotes a "scope" of a variable, then your choices are ... global ; Completely depends on what your really trying to denote or define. --? -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Wed Mar 13 03:33:53 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 13 Mar 2013 06:33:53 -0400 Subject: [rust-dev] ABI Opinion Poll Message-ID: <51405611.3040104@alum.mit.edu> A quick opinion poll: As some of you may know, I am working on enabling pointers to functions (as opposed to closures, which we offer now). Such pointers will be written `extern "ABI" fn(T) -> U`, where `ABI` is, well, the ABI that is expected. This naming reflects the primary use for function pointers, which is to interface with C libraries and the like. Extern fn pointers *can* also be used to point to Rust functions. To that end, I was wondering what the ABI names ought to be and whether to make the ABI mandatory or supply a default. Here are some options on the ABI names. Note that these names would also appear in extern blocks (i.e., `pub extern "cdecl" { ... }`): Option 1. Names "C", "Rust", "StdCall", etc. Option 2. Names "C", "rust", "stdcall", etc. Option 3. Names "cdecl", "rust", "stdcall", etc. And here are the options on the default: Option A. Mandatory ABI. Option B. Default to "rust" (however it winds up being spelled) Option C. Default to "cdecl" (however it winds up being spelled) I am personally leaning towards options (3) and (C). The ABI names in (3) seem most standard, and I imagine cdecl function pointers are the most common. My only hesitation is that in C++ you mark C functions as `extern "C" { ... }` not `extern "cdecl" {...}`, but as strcat pointed out, this has to do more with name mangling than calling convention. Niko From niko at alum.mit.edu Wed Mar 13 03:59:53 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 13 Mar 2013 06:59:53 -0400 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: <51405611.3040104@alum.mit.edu> References: <51405611.3040104@alum.mit.edu> Message-ID: <51405C29.5070905@alum.mit.edu> On IRC, bjz points out that this might be a reasonable place for contextual keywords rather than C++'s Special String Constants. `extern cdecl fn(...)` etc. Niko > Niko Matsakis > March 13, 2013 6:33 AM > A quick opinion poll: > > As some of you may know, I am working on enabling pointers to > functions (as opposed to closures, which we offer now). Such pointers > will be written `extern "ABI" fn(T) -> U`, where `ABI` is, well, the > ABI that is expected. This naming reflects the primary use for > function pointers, which is to interface with C libraries and the > like. Extern fn pointers *can* also be used to point to Rust functions. > > To that end, I was wondering what the ABI names ought to be and > whether to make the ABI mandatory or supply a default. > > Here are some options on the ABI names. Note that these names would > also appear in extern blocks (i.e., `pub extern "cdecl" { ... }`): > > Option 1. Names "C", "Rust", "StdCall", etc. > Option 2. Names "C", "rust", "stdcall", etc. > Option 3. Names "cdecl", "rust", "stdcall", etc. > > And here are the options on the default: > > Option A. Mandatory ABI. > Option B. Default to "rust" (however it winds up being spelled) > Option C. Default to "cdecl" (however it winds up being spelled) > > I am personally leaning towards options (3) and (C). The ABI names in > (3) seem most standard, and I imagine cdecl function pointers are the > most common. My only hesitation is that in C++ you mark C functions > as `extern "C" { ... }` not `extern "cdecl" {...}`, but as strcat > pointed out, this has to do more with name mangling than calling > convention. > > > Niko -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1306 bytes Desc: not available URL: From asb at asbradbury.org Wed Mar 13 04:00:47 2013 From: asb at asbradbury.org (Alex Bradbury) Date: Wed, 13 Mar 2013 11:00:47 +0000 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: <51405611.3040104@alum.mit.edu> References: <51405611.3040104@alum.mit.edu> Message-ID: On 13 March 2013 10:33, Niko Matsakis wrote: > Option 3. Names "cdecl", "rust", "stdcall", etc. Initially, this option appeals to me. However, don't cdecl and stdcall refer to x86 calling conventions? On ARM you'd be aliasing cdecl to aapcs to have the intended meaning. Alex From niko at alum.mit.edu Wed Mar 13 04:11:49 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 13 Mar 2013 07:11:49 -0400 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: References: <51405611.3040104@alum.mit.edu> Message-ID: <51405EF5.60501@alum.mit.edu> Alex Bradbury wrote: > Initially, this option appeals to me. However, don't cdecl and stdcall > refer to x86 calling conventions? On ARM you'd be aliasing cdecl to > aapcs to have the intended meaning. Hmm, that's a very good point. For some reason I was under the impression `cdecl` was a "cross-platform" moniker for "whatever the C compiler does". But even if that were true?and I think I was mistaken?there is the question about something like `stdcall`. One option is just to have the set of ABIs vary by target architecture. We definitely would want one (`C`?) that means "whatever the C compiler does", but beyond that #[cfg] directives and typedefs would be needed. Another option is to have all the Rust ABI-ish names have meaning on all platforms. So `C` might map to `cdecl` on x86 and `aapcs` on ARM, and likewise `Pascal` (or whatever) might map to `stdcall` on x86 and `aapcs` on ARM (presuming that anyone wanted to call obscure Windows APIs on ARM...). I lean towards the first option at the moment mostly because I worry that we won't be able to come up with smart names and consistent meanings across platforms for all ABIs we may someday want to support. Plus I don't claim any sort of encyclopedic knowledge about this sort of thing so I know I shouldn't be the one to create such a catalog. :) Niko From sh4.seo at samsung.com Wed Mar 13 05:46:15 2013 From: sh4.seo at samsung.com (Sanghyeon Seo) Date: Wed, 13 Mar 2013 12:46:15 +0000 (GMT) Subject: [rust-dev] ABI Opinion Poll Message-ID: <28492332.105141363178775521.JavaMail.weblogic@epv6ml07> > Hmm, that's a very good point. For some reason I was under the > impression `cdecl` was a "cross-platform" moniker for "whatever the C > compiler does". But even if that were true?and I think I was > mistaken?there is the question about something like `stdcall`. cdecl and stdcall are definitely x86-specific. I consider the following documentation official on the matter. (See also pcs there for ARM case.) http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html From niko at alum.mit.edu Wed Mar 13 08:54:39 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 13 Mar 2013 11:54:39 -0400 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: <28492332.105141363178775521.JavaMail.weblogic@epv6ml07> References: <28492332.105141363178775521.JavaMail.weblogic@epv6ml07> Message-ID: <5140A13F.4000705@alum.mit.edu> So, an alternative possibility might be: - Use Uppercase ABI names to indicate broad, "cross-platform" variants (e.g., C, Rust). - Use lowercase ABI names to indicate platform-specific variations (e.g., cdecl, stdcall, fastcall, aapcs). Each platform must define what it means to be a "C" function or "Rust" function (presumably: cdecl on x86, aapcs on ARM). Then the preferred thing would be to do `extern "C" fn()` and so forth. But you can use the lowercase variants if that is necessary for some reason. Invoking a function whose ABI is not defined for the current target (e.g., an attempt to call a stdcall function on ARM) would be a compile-time error. Most of the time this means you just use `extern "C"` and things will work. For weirder cases where something is somehow `stdcall` on x86 but `aapcs` on ARM (if such a thing ever happens), you can use #[cfg] directives. I envision a pattern like: #[cfg(target=x86)] // or whatever mod TheFn { type T = extern "stdcall" fn(...) -> ...; extern "stdcall" { fn the_fn(...) -> ...; } } #[cfg(target=aapcs)] // or whatever mod TheFn { type T = extern "aapcs" fn(...) -> ...; extern "stdcall" { fn the_fn(...) -> ...; } } Now I can refer to `TheFn::T` as the appropriate type of `TheFn` and `TheFn::the_fn()` to call it. A touch verbose but I honestly don't know where if ever this situation arises (maybe a port of Windows to some other architecture?) gcc allows you to associate multiple ABIs with a function definition, one per architecture, but it is unclear to me how that interacts with e.g. function pointers. My guess is that it just...doesn't. Therefore I'd prefer not to do the same. Niko > Sanghyeon Seo > March 13, 2013 8:46 AM > > cdecl and stdcall are definitely x86-specific. I consider the following > documentation official on the matter. (See also pcs there for ARM case.) > > http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From niko at alum.mit.edu Wed Mar 13 09:02:40 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 13 Mar 2013 12:02:40 -0400 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: <5140A13F.4000705@alum.mit.edu> References: <28492332.105141363178775521.JavaMail.weblogic@epv6ml07> <5140A13F.4000705@alum.mit.edu> Message-ID: <5140A320.10808@alum.mit.edu> Niko Matsakis wrote: > gcc allows you to associate multiple ABIs with a function definition, > one per architecture, but it is unclear to me how that interacts with > e.g. function pointers. My guess is that it just...doesn't. > Therefore I'd prefer not to do the same. Well, doing a bit more web searching, perhaps you can perhaps just attach attributes to function types in the same way. There is very little discussion of this, to be sure. Anyhow, just to spell out what I left implied in my previous e-mail, the alternative to that proposal is to allow multiple ABIs to be listed, and you just use the (first?) one that applies to the current target architecture. So `extern "stdcall aapcs" fn(...) -> ...` would cover the example I gave before. That's not too hard to implement, actually, so maybe that's the way to go. It avoids the need for duplicate modules and #[cfg] tricks, which I hate, and it's really almost no extra work in the compiler. It'd still be the case that `extern "C"` and `extern "Rust"` are the normal common cases: C would basically be shorthand for `cdecl aapcs` (plus whatever the defaults are on other architectures, like MIPS). So far this is my preferred plan. To summarize: - Uppercase names "C" and "Rust" for "cross-platform" ABIs - Lowercase names for other, platform-specific ABIs - Multiple ABIs are permitted, compiler will use the first that applies to the target architecture - Invoking an extern function without a suitable ABI for the current target is an error If this doesn't seem agreeable to anyone, let me know :) Niko From niko at alum.mit.edu Wed Mar 13 09:16:01 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 13 Mar 2013 12:16:01 -0400 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: <5140A320.10808@alum.mit.edu> References: <28492332.105141363178775521.JavaMail.weblogic@epv6ml07> <5140A13F.4000705@alum.mit.edu> <5140A320.10808@alum.mit.edu> Message-ID: <5140A641.9070002@alum.mit.edu> One simple improvement would be having the compiler issue an error if you either: 1. Combine a cross-platform ABI with any single-platform ABIs 2. Specify multiple single-platform ABIs that apply to the same platform. That's very easy. Oh, and two function types are only compatible if the ABI set is identical. Niko > Niko Matsakis > March 13, 2013 12:02 PM > > > > > Well, doing a bit more web searching, perhaps you can perhaps just > attach attributes to function types in the same way. There is very > little discussion of this, to be sure. > > Anyhow, just to spell out what I left implied in my previous e-mail, > the alternative to that proposal is to allow multiple ABIs to be > listed, and you just use the (first?) one that applies to the current > target architecture. So `extern "stdcall aapcs" fn(...) -> ...` would > cover the example I gave before. That's not too hard to implement, > actually, so maybe that's the way to go. It avoids the need for > duplicate modules and #[cfg] tricks, which I hate, and it's really > almost no extra work in the compiler. It'd still be the case that > `extern "C"` and `extern "Rust"` are the normal common cases: C would > basically be shorthand for `cdecl aapcs` (plus whatever the defaults > are on other architectures, like MIPS). > > So far this is my preferred plan. To summarize: > > - Uppercase names "C" and "Rust" for "cross-platform" ABIs > - Lowercase names for other, platform-specific ABIs > - Multiple ABIs are permitted, compiler will use the first that > applies to the target architecture > - Invoking an extern function without a suitable ABI for the current > target is an error > > If this doesn't seem agreeable to anyone, let me know :) > > > Niko > Niko Matsakis > March 13, 2013 11:54 AM > So, an alternative possibility might be: > > - Use Uppercase ABI names to indicate broad, "cross-platform" variants > (e.g., C, Rust). > - Use lowercase ABI names to indicate platform-specific variations > (e.g., cdecl, stdcall, fastcall, aapcs). > > Each platform must define what it means to be a "C" function or "Rust" > function (presumably: cdecl on x86, aapcs on ARM). Then the preferred > thing would be to do `extern "C" fn()` and so forth. But you can use > the lowercase variants if that is necessary for some reason. > > Invoking a function whose ABI is not defined for the current target > (e.g., an attempt to call a stdcall function on ARM) would be a > compile-time error. > > Most of the time this means you just use `extern "C"` and things will > work. For weirder cases where something is somehow `stdcall` on x86 > but `aapcs` on ARM (if such a thing ever happens), you can use #[cfg] > directives. I envision a pattern like: > > #[cfg(target=x86)] // or whatever > mod TheFn { > type T = extern "stdcall" fn(...) -> ...; > extern "stdcall" { fn the_fn(...) -> ...; } > } > > #[cfg(target=aapcs)] // or whatever > mod TheFn { > type T = extern "aapcs" fn(...) -> ...; > extern "stdcall" { fn the_fn(...) -> ...; } > } > > Now I can refer to `TheFn::T` as the appropriate type of `TheFn` and > `TheFn::the_fn()` to call it. A touch verbose but I honestly don't > know where if ever this situation arises (maybe a port of Windows to > some other architecture?) > > gcc allows you to associate multiple ABIs with a function definition, > one per architecture, but it is unclear to me how that interacts with > e.g. function pointers. My guess is that it just...doesn't. > Therefore I'd prefer not to do the same. > > > Niko > Sanghyeon Seo > March 13, 2013 8:46 AM > > cdecl and stdcall are definitely x86-specific. I consider the following > documentation official on the matter. (See also pcs there for ARM case.) > > http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1306 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From pwalton at mozilla.com Wed Mar 13 10:20:42 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 13 Mar 2013 10:20:42 -0700 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: <5140A641.9070002@alum.mit.edu> References: <28492332.105141363178775521.JavaMail.weblogic@epv6ml07> <5140A13F.4000705@alum.mit.edu> <5140A320.10808@alum.mit.edu> <5140A641.9070002@alum.mit.edu> Message-ID: <5140B56A.5000105@mozilla.com> On 3/13/13 9:16 AM, Niko Matsakis wrote: > One simple improvement would be having the compiler issue an error if > you either: > > 1. Combine a cross-platform ABI with any single-platform ABIs > 2. Specify multiple single-platform ABIs that apply to the same platform. > > That's very easy. > > Oh, and two function types are only compatible if the ABI set is identical. I guess it would be possible to use subtyping here so that e.g. `extern "aapcs cdecl" fn` is a subtype of `extern "cdecl" fn`, but that sounds like overkill. Patrick From sstangl at mozilla.com Wed Mar 13 10:36:45 2013 From: sstangl at mozilla.com (Sean Stangl) Date: Wed, 13 Mar 2013 10:36:45 -0700 (PDT) Subject: [rust-dev] ABI Opinion Poll In-Reply-To: <5140B56A.5000105@mozilla.com> Message-ID: <1955016580.2045953.1363196205813.JavaMail.root@mozilla.com> Specifying ABI on the rust side may not be desirable. For example, ARM contains the option of at least the ABIs "armeabi"/"gnueabi" and "armeabi-v7"/"gnueabi-v7". This might be OK if Rust never intends to support cross-compilation, but with a number of targets, explicit annotations would get very hairy for no real gain. But on top of that, a single ARM system may use disjoint ABIs in terms of softfp/hardfp, so autodetection wouldn't be valid since either is a valid option but the decision is significant. It might be better for Rust to just express "this uses some C calling convention", and then have the specific convention decided at configuration time by the person compiling. Sean ----- Original Message ----- From: "Patrick Walton" To: rust-dev at mozilla.org Sent: Wednesday, March 13, 2013 10:20:42 AM Subject: Re: [rust-dev] ABI Opinion Poll On 3/13/13 9:16 AM, Niko Matsakis wrote: > One simple improvement would be having the compiler issue an error if > you either: > > 1. Combine a cross-platform ABI with any single-platform ABIs > 2. Specify multiple single-platform ABIs that apply to the same platform. > > That's very easy. > > Oh, and two function types are only compatible if the ABI set is identical. I guess it would be possible to use subtyping here so that e.g. `extern "aapcs cdecl" fn` is a subtype of `extern "cdecl" fn`, but that sounds like overkill. Patrick _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev From niko at alum.mit.edu Wed Mar 13 10:54:50 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 13 Mar 2013 13:54:50 -0400 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: <1955016580.2045953.1363196205813.JavaMail.root@mozilla.com> References: <1955016580.2045953.1363196205813.JavaMail.root@mozilla.com> Message-ID: <5140BD6A.2020902@alum.mit.edu> Sean Stangl wrote: > It might be better for Rust to just express "this uses some C calling convention", and then have the specific convention decided at configuration time by the person compiling. Good point. We can't actually remove the ABI from the Rust source altogether, as we can't generate code without knowing the precise ABI, but I can see that in some cases you would want to set the ABI as a kind of configuration setting and not specified within the source. One easy way to achieve this would be with a macro or #[cfg] settings (e.g., `cfunc!(a, b -> c)` could generate `extern "aapcs" fn(a, b) -> c` and so forth). This seems like an interesting intersection with the designs for Rust's package system. Another way would be to allow ABI settings that are configuration variables (`extern c! fn(...)`) or something. Truth be told, though, however we do it probably doesn't impact me too much because I imagine that kind of think would be substituted away in front-end pass :) Also?a slight amendment to what I wrote earlier, I imagine the best rules would be to permit one cross-platform specification (C, Rust) to be combined with per-platform specifications, so that you can say "use the default on most platforms, but on ARM use (whatever)". Niko From niko at alum.mit.edu Wed Mar 13 10:56:51 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 13 Mar 2013 13:56:51 -0400 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: <5140BD6A.2020902@alum.mit.edu> References: <1955016580.2045953.1363196205813.JavaMail.root@mozilla.com> <5140BD6A.2020902@alum.mit.edu> Message-ID: <5140BDE3.9060403@alum.mit.edu> Niko Matsakis wrote: > Truth be told, though, however we do it probably doesn't impact me too > much because I imagine that kind of think would be substituted away in > front-end pass :) Also---an obvious thing is that the "meta-abi" C could be adjusted on the command line or in cfg directives. So that you can just write extern "C" everywhere and things mostly work. So basically I think this use case is covered pretty well (but thanks for raising it). Niko From ben.striegel at gmail.com Wed Mar 13 14:00:20 2013 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 13 Mar 2013 17:00:20 -0400 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: <51405611.3040104@alum.mit.edu> References: <51405611.3040104@alum.mit.edu> Message-ID: Somewhat off-topic, but why are extern functions written as extern "ABI" fn(T) -> U Rather than using an attribute? #[abi = "ABI"] extern fn(T) -> U It seems like a very bizarre special case. On Wed, Mar 13, 2013 at 6:33 AM, Niko Matsakis wrote: > A quick opinion poll: > > As some of you may know, I am working on enabling pointers to functions > (as opposed to closures, which we offer now). Such pointers will be > written `extern "ABI" fn(T) -> U`, where `ABI` is, well, the ABI that is > expected. This naming reflects the primary use for function pointers, > which is to interface with C libraries and the like. Extern fn pointers > *can* also be used to point to Rust functions. > > To that end, I was wondering what the ABI names ought to be and whether to > make the ABI mandatory or supply a default. > > Here are some options on the ABI names. Note that these names would also > appear in extern blocks (i.e., `pub extern "cdecl" { ... }`): > > Option 1. Names "C", "Rust", "StdCall", etc. > Option 2. Names "C", "rust", "stdcall", etc. > Option 3. Names "cdecl", "rust", "stdcall", etc. > > And here are the options on the default: > > Option A. Mandatory ABI. > Option B. Default to "rust" (however it winds up being spelled) > Option C. Default to "cdecl" (however it winds up being spelled) > > I am personally leaning towards options (3) and (C). The ABI names in (3) > seem most standard, and I imagine cdecl function pointers are the most > common. My only hesitation is that in C++ you mark C functions as `extern > "C" { ... }` not `extern "cdecl" {...}`, but as strcat pointed out, this > has to do more with name mangling than calling convention. > > > Niko > ______________________________**_________________ > 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 Mar 13 14:01:22 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 13 Mar 2013 14:01:22 -0700 Subject: [rust-dev] ABI Opinion Poll In-Reply-To: References: <51405611.3040104@alum.mit.edu> Message-ID: <5140E922.90306@mozilla.com> On 3/13/13 2:00 PM, Benjamin Striegel wrote: > Somewhat off-topic, but why are extern functions written as > > extern "ABI" fn(T) -> U > > Rather than using an attribute? > > #[abi = "ABI"] > extern fn(T) -> U > > It seems like a very bizarre special case. Because the ABI is part of the type and not just part of the declaration. Patrick From jld at panix.com Thu Mar 14 16:02:25 2013 From: jld at panix.com (Jed Davis) Date: Thu, 14 Mar 2013 16:02:25 -0700 Subject: [rust-dev] Order of evaluation of struct initializers In-Reply-To: References: Message-ID: <20130314230225.GA19729@panix.com> On Tue, Mar 12, 2013 at 01:07:07PM -0400, Jack Lloyd wrote: > If two or more struct initializers have side effects, is the order > that they run defined? I'm pretty sure it is, because it's actually part of the type system. See src/test/run-pass/struct-order-of-eval-2.rs: struct S { f0: ~str, f1: ~str } pub fn main() { let s = ~"Hello, world!"; let _s = S { f1: str::from_slice(s), f0: s }; } That compiles, but swap the order of the field initializers and: struct-order-of-eval-2.rs:15:44: 15:45 error: use of moved value: `s` struct-order-of-eval-2.rs:15 let _s = S { f0: s, f1: str::from_slice(s) }; ^ struct-order-of-eval-2.rs:15:21: 15:22 note: `s` moved here because it has type ~str, which is moved by default (use `copy` to override) struct-order-of-eval-2.rs:15 let _s = S { f0: s, f1: str::from_slice(s) }; ^ So it's important that the first program not be turned into the second program after the type checking is done. --Jed From loebel.marvin at gmail.com Sat Mar 16 16:27:40 2013 From: loebel.marvin at gmail.com (=?ISO-8859-1?Q?Marvin_L=F6bel?=) Date: Sun, 17 Mar 2013 00:27:40 +0100 Subject: [rust-dev] const, static, global, mut, syntax! In-Reply-To: References: <513F85B7.2090908@mozilla.com> Message-ID: <5144FFEC.4000604@googlemail.com> On 'static' vs 'global': - 'static' would feel more familiar for C/C++ people, but is also way to overloaded there. - 'global' would be more unfamiliar, but also concise: 'This thing has global scope or lifetime'. One thing I don't like about 'static' and 'global' is that they are longer and harder to pronounce compared to 'const' (by not much, granted). So how about 'glob' ? > I like 'static' more than 'global' or 'const' for lifetime names, and > I agree that const and static should be unified into a single name. > > 'static' scares me a bit because of C's use of it in several somewhat > unrelated contexts, and so the name feels a bit polluted in my mind. > > But I still like it best. > > On Tue, Mar 12, 2013 at 5:13 PM, Benjamin Striegel > wrote: >> I'll speak up in favor of ditching both "const" and "static" for "global". >> >> global foo: int = 1; >> global mut bar: int = 1; >> &'global baz >> >> (Though not sure exactly what the 'static region is, does that last one make >> sense?) >> >> >> On Tue, Mar 12, 2013 at 3:44 PM, Graydon Hoare wrote: >>> Hi, >>> >>> At today's meeting we had a a discussion about two issues that >>> intersect, oddly, at a particular point of the syntax. The two issues are: >>> >>> - Removing the 'static lifetime-name -- currently used to denote >>> the lifetime of consts -- since the only other use of the word >>> (static fn ...) is going away when we finish with explicit-self; >>> renaming it (probably) to 'const since that's the word used to >>> introduce consts! >>> >>> - Adding mutable globals (unsafe-to-access, but needed in some >>> corner cases for mutexes and such). This is an old bug >>> (two years! https://github.com/mozilla/rust/issues/553 ) that >>> we've long assumed we'd have to implement eventually. >>> >>> We agreed to do the former (rename 'static to 'const) and collapse all >>> uses of the word "const" to mean this "read-only-memory" thing. But then >>> when pushing around possible syntaxes for mutable globals, such as the >>> following not-so-charming options: >>> >>> let mut x : T = v; // like in functions, but different since >>> the RHS must be a const and can refer to >>> values declared-after it. >>> >>> const mut x : T = v; // adding a modifier to 'const' but one that >>> reads somewhat absurdly: "constant mutable"? >>> >>> unsafe mut x : T = v; // more random choices... >>> >>> We stumbled on the _opposite_ possibility for const-vs-static: maybe we >>> should be retiring the "const" keyword and standardizing on "static", >>> for both mutable and immutable. The following cases would then fall out: >>> >>> static x : T = v; // constant init, immutable, like const today >>> >>> static mut x : T = v; // constant init, mutable, unsafe to access >>> >>> With values in that scope having 'static lifetime, and the word "const" >>> no longer appearing anywhere in the language. >>> >>> There are other options, probably, that we did not consider. Some people >>> suggested putting "global" in there instead of "static". Some suggested >>> going back to "var" rather than "let". >>> >>> This is an intentional (brief) request for a little syntax >>> bikeshed-discussion to see if anything else occurs to anyone, or if >>> anyone has strong reactions / preferences / thoughts to any of the above >>> options. We recognize that this does not _exactly_ align with the >>> meanings of the highly-overloaded words "const" or "static" in C/C++, >>> but think that there's some keyword and concept overlap here that can >>> probably be minimized. >>> >>> (Maybe reply for only a couple days and we'll summarize opinions and >>> pick something thereafter. No need for it to drag on forever.) >>> >>> Thanks, >>> >>> -Graydon >>> _______________________________________________ >>> 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 steven at ashley.net.nz Sat Mar 16 17:54:03 2013 From: steven at ashley.net.nz (Steven Ashley) Date: Sun, 17 Mar 2013 13:54:03 +1300 Subject: [rust-dev] const, static, global, mut, syntax! In-Reply-To: <5144FFEC.4000604@googlemail.com> References: <513F85B7.2090908@mozilla.com> <5144FFEC.4000604@googlemail.com> Message-ID: 'glob' is a term usually associated with text matching. I think using 'glob' for 'global' would be confusing. On Mar 17, 2013 12:42 PM, "Marvin L?bel" wrote: > On 'static' vs 'global': > - 'static' would feel more familiar for C/C++ people, but is also way to > overloaded there. > - 'global' would be more unfamiliar, but also concise: 'This thing has > global scope or lifetime'. > > One thing I don't like about 'static' and 'global' is that they are longer > and harder to pronounce compared to 'const' (by not much, granted). > > So how about 'glob' ? > >> I like 'static' more than 'global' or 'const' for lifetime names, and >> I agree that const and static should be unified into a single name. >> >> 'static' scares me a bit because of C's use of it in several somewhat >> unrelated contexts, and so the name feels a bit polluted in my mind. >> >> But I still like it best. >> >> On Tue, Mar 12, 2013 at 5:13 PM, Benjamin Striegel >> wrote: >> >>> I'll speak up in favor of ditching both "const" and "static" for >>> "global". >>> >>> global foo: int = 1; >>> global mut bar: int = 1; >>> &'global baz >>> >>> (Though not sure exactly what the 'static region is, does that last one >>> make >>> sense?) >>> >>> >>> On Tue, Mar 12, 2013 at 3:44 PM, Graydon Hoare >>> wrote: >>> >>>> Hi, >>>> >>>> At today's meeting we had a a discussion about two issues that >>>> intersect, oddly, at a particular point of the syntax. The two issues >>>> are: >>>> >>>> - Removing the 'static lifetime-name -- currently used to denote >>>> the lifetime of consts -- since the only other use of the word >>>> (static fn ...) is going away when we finish with explicit-self; >>>> renaming it (probably) to 'const since that's the word used to >>>> introduce consts! >>>> >>>> - Adding mutable globals (unsafe-to-access, but needed in some >>>> corner cases for mutexes and such). This is an old bug >>>> (two years! https://github.com/mozilla/**rust/issues/553) that >>>> we've long assumed we'd have to implement eventually. >>>> >>>> We agreed to do the former (rename 'static to 'const) and collapse all >>>> uses of the word "const" to mean this "read-only-memory" thing. But then >>>> when pushing around possible syntaxes for mutable globals, such as the >>>> following not-so-charming options: >>>> >>>> let mut x : T = v; // like in functions, but different since >>>> the RHS must be a const and can refer to >>>> values declared-after it. >>>> >>>> const mut x : T = v; // adding a modifier to 'const' but one that >>>> reads somewhat absurdly: "constant mutable"? >>>> >>>> unsafe mut x : T = v; // more random choices... >>>> >>>> We stumbled on the _opposite_ possibility for const-vs-static: maybe we >>>> should be retiring the "const" keyword and standardizing on "static", >>>> for both mutable and immutable. The following cases would then fall out: >>>> >>>> static x : T = v; // constant init, immutable, like const today >>>> >>>> static mut x : T = v; // constant init, mutable, unsafe to access >>>> >>>> With values in that scope having 'static lifetime, and the word "const" >>>> no longer appearing anywhere in the language. >>>> >>>> There are other options, probably, that we did not consider. Some people >>>> suggested putting "global" in there instead of "static". Some suggested >>>> going back to "var" rather than "let". >>>> >>>> This is an intentional (brief) request for a little syntax >>>> bikeshed-discussion to see if anything else occurs to anyone, or if >>>> anyone has strong reactions / preferences / thoughts to any of the above >>>> options. We recognize that this does not _exactly_ align with the >>>> meanings of the highly-overloaded words "const" or "static" in C/C++, >>>> but think that there's some keyword and concept overlap here that can >>>> probably be minimized. >>>> >>>> (Maybe reply for only a couple days and we'll summarize opinions and >>>> pick something thereafter. No need for it to drag on forever.) >>>> >>>> Thanks, >>>> >>>> -Graydon >>>> ______________________________**_________________ >>>> 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 lucian.branescu at gmail.com Sat Mar 16 17:57:57 2013 From: lucian.branescu at gmail.com (Lucian Branescu) Date: Sun, 17 Mar 2013 00:57:57 +0000 Subject: [rust-dev] const, static, global, mut, syntax! In-Reply-To: References: <513F85B7.2090908@mozilla.com> <5144FFEC.4000604@googlemail.com> Message-ID: As long as it's semantically correct, I like global the most. I would not worry too much about C++ or similar devs being confused, since their top-level variables are thought of as "global". On 17 March 2013 00:54, Steven Ashley wrote: > 'glob' is a term usually associated with text matching. I think using > 'glob' for 'global' would be confusing. > On Mar 17, 2013 12:42 PM, "Marvin L?bel" wrote: > >> On 'static' vs 'global': >> - 'static' would feel more familiar for C/C++ people, but is also way to >> overloaded there. >> - 'global' would be more unfamiliar, but also concise: 'This thing has >> global scope or lifetime'. >> >> One thing I don't like about 'static' and 'global' is that they are >> longer and harder to pronounce compared to 'const' (by not much, granted). >> >> So how about 'glob' ? >> >>> I like 'static' more than 'global' or 'const' for lifetime names, and >>> I agree that const and static should be unified into a single name. >>> >>> 'static' scares me a bit because of C's use of it in several somewhat >>> unrelated contexts, and so the name feels a bit polluted in my mind. >>> >>> But I still like it best. >>> >>> On Tue, Mar 12, 2013 at 5:13 PM, Benjamin Striegel >>> wrote: >>> >>>> I'll speak up in favor of ditching both "const" and "static" for >>>> "global". >>>> >>>> global foo: int = 1; >>>> global mut bar: int = 1; >>>> &'global baz >>>> >>>> (Though not sure exactly what the 'static region is, does that last one >>>> make >>>> sense?) >>>> >>>> >>>> On Tue, Mar 12, 2013 at 3:44 PM, Graydon Hoare >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> At today's meeting we had a a discussion about two issues that >>>>> intersect, oddly, at a particular point of the syntax. The two issues >>>>> are: >>>>> >>>>> - Removing the 'static lifetime-name -- currently used to denote >>>>> the lifetime of consts -- since the only other use of the word >>>>> (static fn ...) is going away when we finish with explicit-self; >>>>> renaming it (probably) to 'const since that's the word used to >>>>> introduce consts! >>>>> >>>>> - Adding mutable globals (unsafe-to-access, but needed in some >>>>> corner cases for mutexes and such). This is an old bug >>>>> (two years! https://github.com/mozilla/**rust/issues/553) that >>>>> we've long assumed we'd have to implement eventually. >>>>> >>>>> We agreed to do the former (rename 'static to 'const) and collapse all >>>>> uses of the word "const" to mean this "read-only-memory" thing. But >>>>> then >>>>> when pushing around possible syntaxes for mutable globals, such as the >>>>> following not-so-charming options: >>>>> >>>>> let mut x : T = v; // like in functions, but different since >>>>> the RHS must be a const and can refer to >>>>> values declared-after it. >>>>> >>>>> const mut x : T = v; // adding a modifier to 'const' but one that >>>>> reads somewhat absurdly: "constant >>>>> mutable"? >>>>> >>>>> unsafe mut x : T = v; // more random choices... >>>>> >>>>> We stumbled on the _opposite_ possibility for const-vs-static: maybe we >>>>> should be retiring the "const" keyword and standardizing on "static", >>>>> for both mutable and immutable. The following cases would then fall >>>>> out: >>>>> >>>>> static x : T = v; // constant init, immutable, like const today >>>>> >>>>> static mut x : T = v; // constant init, mutable, unsafe to access >>>>> >>>>> With values in that scope having 'static lifetime, and the word "const" >>>>> no longer appearing anywhere in the language. >>>>> >>>>> There are other options, probably, that we did not consider. Some >>>>> people >>>>> suggested putting "global" in there instead of "static". Some suggested >>>>> going back to "var" rather than "let". >>>>> >>>>> This is an intentional (brief) request for a little syntax >>>>> bikeshed-discussion to see if anything else occurs to anyone, or if >>>>> anyone has strong reactions / preferences / thoughts to any of the >>>>> above >>>>> options. We recognize that this does not _exactly_ align with the >>>>> meanings of the highly-overloaded words "const" or "static" in C/C++, >>>>> but think that there's some keyword and concept overlap here that can >>>>> probably be minimized. >>>>> >>>>> (Maybe reply for only a couple days and we'll summarize opinions and >>>>> pick something thereafter. No need for it to drag on forever.) >>>>> >>>>> Thanks, >>>>> >>>>> -Graydon >>>>> ______________________________**_________________ >>>>> 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 doy at tozt.net Mon Mar 18 17:30:02 2013 From: doy at tozt.net (Jesse Luehrs) Date: Mon, 18 Mar 2013 19:30:02 -0500 Subject: [rust-dev] const, static, global, mut, syntax! In-Reply-To: <513F85B7.2090908@mozilla.com> References: <513F85B7.2090908@mozilla.com> Message-ID: <20130319003002.GH23176@tozt.net> On Tue, Mar 12, 2013 at 12:44:55PM -0700, Graydon Hoare wrote: > unsafe mut x : T = v; // more random choices... "unsafe mut" doesn't really make sense, since defining a global isn't unsafe, just using it is. What about just "mut x"? const x : T = v; mut y : T = v; -doy From kesserich1 at gmail.com Tue Mar 19 10:43:14 2013 From: kesserich1 at gmail.com (paul santa clara) Date: Tue, 19 Mar 2013 13:43:14 -0400 Subject: [rust-dev] TCP Socket Non-blocking IO Message-ID: Howdy, Sorry if this question is in appropriate for this forum, but I'm pretty stumped and was hoping someone could point me in the right direction. Essentially, I'm trying to figure how to go about performing a non-blocking read from TCP Socket. I see that there is a future_read fn implemented in the net_tcp module but any attempt to resolve the resulting future blocks execution. What I am really shooting for a is method to query a socket to see if there is any data available for reading and if not, go do something else for awhile. Any thoughts as to how I might accomplish this? Thanks, -Paul SC -------------- next part -------------- An HTML attachment was scrubbed... URL: From someone at mearie.org Tue Mar 19 19:01:51 2013 From: someone at mearie.org (Kang Seonghoon) Date: Wed, 20 Mar 2013 11:01:51 +0900 Subject: [rust-dev] Conditional expression Message-ID: Rust does not have a ternary operator like C's `a ? b : c`, which corresponds to Rust's `if a { b } else { c }`. I agree that ternary operators are PITA in many cases, but for simple expressions this seems a bit verbose: (an excerpt from the actual code) let nkeys = match bms.player { 2 | 3 => if isbme { ~"14" } else { ~"10" }, _ => if isbme { ~"7" } else { ~"5" } }; if haspedal { nkeys + ~"/fp" } else { nkeys } If we had a macro like this: macro_rules! iif( ($cond:expr, $then:expr, $otherwise:expr) => (if $cond { $then } else { $otherwise }) ) the code above could be rewritten as follows: let nkeys = match bms.player { 2 | 3 => iif!(isbme, ~"14", ~"10"), _ => iif!(isbme, ~"7", ~"5") }; iif!(haspedal, nkeys + ~"/fp", nkeys) This is ultimately a matter of preference, but can be a good addition to core if this pattern arises a lot and people will end up writing the same macro. Some notes: * `if!` would be the better name, but `if!(x) { y } else { z }` will be invalid then. I choose `iif!` instead because it is already used in several languages for expression-level conditionals. * I suggest not to implement two-argument version `iif!(x, y)` (which is same as `iif!(x, y, ())` by the definition). We don't want this form to be used for general blocks. -- -- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/ -- Opinions expressed in this email do not necessarily represent the views of my employer. -- From thadguidry at gmail.com Tue Mar 19 19:56:12 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Tue, 19 Mar 2013 21:56:12 -0500 Subject: [rust-dev] Conditional expression In-Reply-To: References: Message-ID: Your 1st verbose expression, as you call it, is actually very, very readable... for the cost of 2 extra chars per same line. My opinion ? Worth the cost of 2 more chars. On Tue, Mar 19, 2013 at 9:01 PM, Kang Seonghoon wrote: > Rust does not have a ternary operator like C's `a ? b : c`, which > corresponds to Rust's `if a { b } else { c }`. I agree that ternary > operators are PITA in many cases, but for simple expressions this > seems a bit verbose: (an excerpt from the actual code) > > let nkeys = match bms.player { > 2 | 3 => if isbme { ~"14" } else { ~"10" }, > _ => if isbme { ~"7" } else { ~"5" } > }; > if haspedal { nkeys + ~"/fp" } else { nkeys } > > If we had a macro like this: > > macro_rules! iif( > ($cond:expr, $then:expr, $otherwise:expr) => > (if $cond { $then } else { $otherwise }) > ) > > the code above could be rewritten as follows: > > let nkeys = match bms.player { > 2 | 3 => iif!(isbme, ~"14", ~"10"), > _ => iif!(isbme, ~"7", ~"5") > }; > iif!(haspedal, nkeys + ~"/fp", nkeys) > > This is ultimately a matter of preference, but can be a good addition > to core if this pattern arises a lot and people will end up writing > the same macro. > > Some notes: > > * `if!` would be the better name, but `if!(x) { y } else { z }` will > be invalid then. I choose `iif!` instead because it is already used in > several languages for expression-level conditionals. > * I suggest not to implement two-argument version `iif!(x, y)` (which > is same as `iif!(x, y, ())` by the definition). We don't want this > form to be used for general blocks. > > -- > -- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/ > -- Opinions expressed in this email do not necessarily represent the > views of my employer. > -- > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack at metajack.im Tue Mar 19 21:28:26 2013 From: jack at metajack.im (Jack Moffitt) Date: Tue, 19 Mar 2013 22:28:26 -0600 Subject: [rust-dev] TCP Socket Non-blocking IO In-Reply-To: References: Message-ID: > What I am really shooting for a is method to query a socket to > see if there is any data available for reading and if not, go do something > else for awhile. Rust has tasks so you can just spawn a task to handle the socket reads and do other stuff while it's blocking in other tasks. The non-blocking stuff happens for you behind the scenes by the task scheduler. In Erlang, you normally just make all your blocking calls in a process (the Erlang version of Rust tasks) and don't worry about it. Erlang's gen_tcp:recv does have a mode where it will return immediately with any available data, but I've never used it, and I don't believe its use is common. jack. From graydon at mozilla.com Tue Mar 19 22:21:22 2013 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 19 Mar 2013 22:21:22 -0700 Subject: [rust-dev] Conditional expression In-Reply-To: References: Message-ID: <51494752.1000403@mozilla.com> On 19/03/2013 7:01 PM, Kang Seonghoon wrote: > Rust does not have a ternary operator like C's `a ? b : c`, which > corresponds to Rust's `if a { b } else { c }`. I agree that ternary > operators are PITA in many cases, but for simple expressions this > seems a bit verbose: (an excerpt from the actual code) > > let nkeys = match bms.player { > 2 | 3 => if isbme { ~"14" } else { ~"10" }, > _ => if isbme { ~"7" } else { ~"5" } > }; > if haspedal { nkeys + ~"/fp" } else { nkeys } > One can macroize this somewhat if the verbosity is getting to you, but I should point out that this also works: let nkeys = match bms.player { 2 | 3 if isbme => ~"14", 2 | 3 => ~"10", _ if isbme => ~"7", _ => ~"5" }; as does a tuple match, an inverted-nesting, and several other phrasings. There are a number of equivalent ways of writing conditionals, differing only in readability. We did actually have a ternary operator for a while (after people argued for it) but then we removed it (after people argued against). > If we had a macro like this: > > macro_rules! iif( > ($cond:expr, $then:expr, $otherwise:expr) => > (if $cond { $then } else { $otherwise }) > ) > I suppose. It's not much shorter (2 chars?) and may also confuse readers (why have two forms of an if-then-else conditional?) If we see a lot of people macro-izing it I'd be willing to take the patch, but so far this is the first time anyone's mentioned wanting it as a _macro_ (though I guess there was that macro_rules! mini lisp ... kinda thought that was in jest). In general I think we want to only add stuff to the core macros if it's getting wide use. They get injected into _every_ program (at least until we have, say, lazily-loaded and crate-exported macros, *cough*). Usually when this comes up it's a call for ternary operator (which is fully 7 chars shorter) and while I understood and accepted that argument back the first time it happened, as well as its reversal on the grounds of simplification, I have a bit of a time-traveller's rule about trying not to revisit the same design choice three times. -Graydon From kesserich1 at gmail.com Thu Mar 21 09:47:55 2013 From: kesserich1 at gmail.com (paul santa clara) Date: Thu, 21 Mar 2013 12:47:55 -0400 Subject: [rust-dev] TCP Socket Non-blocking IO In-Reply-To: References: Message-ID: Hey Jack, Thanks for your response! I actually have a rust task managing the tcp socket. Most of the time, this task is content to sit around and read from the socket but on occassion, it will be prompted by another task to also write to said socket. The problem is that while the task is blocked reading a socket, it will not be able to inspect its port to see if the other task would like it write something to the socket. I'm viewing the problem as an actor style pattern wherein the socket task is instructed on behalf of other tasks to do things with the socket. Perhaps there is a cleaner way of modeling it? I suppose I could use two separate sockets - one for reading and one for writing- but this seems inefficient. Thanks, -Paul SC On Wed, Mar 20, 2013 at 12:28 AM, Jack Moffitt wrote: > > What I am really shooting for a is method to query a socket to > > see if there is any data available for reading and if not, go do > something > > else for awhile. > > Rust has tasks so you can just spawn a task to handle the socket reads > and do other stuff while it's blocking in other tasks. The > non-blocking stuff happens for you behind the scenes by the task > scheduler. In Erlang, you normally just make all your blocking calls > in a process (the Erlang version of Rust tasks) and don't worry about > it. Erlang's gen_tcp:recv does have a mode where it will return > immediately with any available data, but I've never used it, and I > don't believe its use is common. > > jack. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gwillen at nerdnet.org Thu Mar 21 10:43:30 2013 From: gwillen at nerdnet.org (gwillen@gmail.com) Date: Thu, 21 Mar 2013 13:43:30 -0400 Subject: [rust-dev] TCP Socket Non-blocking IO In-Reply-To: References: Message-ID: <78492d7b-5742-4c16-9b72-3389b9b1a2d1@email.android.com> In principle the right pattern for this might be two tasks with the same socket? I don't know if rust's socket abstraction would like that or not. paul santa clara wrote: >Hey Jack, >Thanks for your response! I actually have a rust task managing the tcp >socket. Most of the time, this task is content to sit around and read >from >the socket but on occassion, it will be prompted by another task to >also >write to said socket. The problem is that while the task is blocked >reading a socket, it will not be able to inspect its port to see if the >other task would like it write something to the socket. > I'm viewing the problem as an actor style pattern wherein the socket >task is instructed on behalf of other tasks to do things with the >socket. >Perhaps there is a cleaner way of modeling it? I suppose I could use >two >separate sockets - one for reading and one for writing- but this seems >inefficient. > >Thanks, >-Paul SC > >On Wed, Mar 20, 2013 at 12:28 AM, Jack Moffitt >wrote: > >> > What I am really shooting for a is method to query a socket to >> > see if there is any data available for reading and if not, go do >> something >> > else for awhile. >> >> Rust has tasks so you can just spawn a task to handle the socket >reads >> and do other stuff while it's blocking in other tasks. The >> non-blocking stuff happens for you behind the scenes by the task >> scheduler. In Erlang, you normally just make all your blocking calls >> in a process (the Erlang version of Rust tasks) and don't worry about >> it. Erlang's gen_tcp:recv does have a mode where it will return >> immediately with any available data, but I've never used it, and I >> don't believe its use is common. >> >> jack. >> > > >!DSPAM:514b396d299105315134984! > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev > > >!DSPAM:514b396d299105315134984! -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clements at brinckerhoff.org Thu Mar 21 12:07:52 2013 From: clements at brinckerhoff.org (John Clements) Date: Thu, 21 Mar 2013 12:07:52 -0700 Subject: [rust-dev] figuring out grammar for generics Message-ID: I'm just fixing a few bugs, and trying to make sure I understand the grammar of generics. Here's what I've got. Can someone correct me, if I'm wrong? I've lifted comments from a couple of functions, so you can ignore the words "matches" and "where". Also, the definition of 'ty' is not provided :). I'm assuming a hopefully-obvious BNF syntax. John // matches generics = ( ) | ( < > ) | ( < typaramseq > ) | ( < lifetimes > ) | ( < lifetimes , typaramseq > ) // where typaramseq = ( typaram ) | ( typaram , typaramseq ) // matches typaram = IDENT optbounds // matches optbounds = ( ( : ( boundseq )? )? ) // where boundseq = ( bound + boundseq ) | ( bound ) // and bound = ( & STATIC ) | ( ty ) From niko at alum.mit.edu Thu Mar 21 13:12:48 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 21 Mar 2013 16:12:48 -0400 Subject: [rust-dev] figuring out grammar for generics In-Reply-To: References: Message-ID: <514B69C0.1020100@alum.mit.edu> That looks about right, though (1) as we said on IRC `&static` ought to be changed to `'static` (or, eventually, any lifetime name). (2) I presume lifetimes = lifetime | lifetime, lifetimes (3) we typically allow trailing commas, and we probably do here as well (or at least probably should?). Niko > John Clements > March 21, 2013 3:07 PM > I'm just fixing a few bugs, and trying to make sure I understand the > grammar of generics. Here's what I've got. Can someone correct me, if > I'm wrong? I've lifted comments from a couple of functions, so you can > ignore the words "matches" and "where". Also, the definition of 'ty' > is not provided :). I'm assuming a hopefully-obvious BNF syntax. > > John > > > > // matches generics = ( ) | ( < > ) | ( < typaramseq > ) | ( < > lifetimes > ) | ( < lifetimes , typaramseq > ) > // where typaramseq = ( typaram ) | ( typaram , typaramseq ) > > // matches typaram = IDENT optbounds > > // matches optbounds = ( ( : ( boundseq )? )? ) > // where boundseq = ( bound + boundseq ) | ( bound ) > // and bound = ( & STATIC ) | ( ty ) > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1360 bytes Desc: not available URL: From clements at brinckerhoff.org Thu Mar 21 13:52:14 2013 From: clements at brinckerhoff.org (John Clements) Date: Thu, 21 Mar 2013 13:52:14 -0700 Subject: [rust-dev] figuring out grammar for generics In-Reply-To: <514B69C0.1020100@alum.mit.edu> References: <514B69C0.1020100@alum.mit.edu> Message-ID: <00A59151-60B5-411B-8966-00C5CE0C3C41@brinckerhoff.org> On Mar 21, 2013, at 1:12 PM, Niko Matsakis wrote: > That looks about right, though > > (1) as we said on IRC `&static` ought to be changed to `'static` (or, eventually, any lifetime name). > (2) I presume lifetimes = lifetime | lifetime, lifetimes > (3) we typically allow trailing commas, and we probably do here as well (or at least probably should?). Yes, I neglected to include the defn of lifetimes. It looks to me like the current compiler allows trailing commas after lifetimes, but not after type parameters (sigh). I'm assuming that's not the best solution. What should it be? John > > > Niko > >> John Clements March 21, 2013 3:07 PM >> I'm just fixing a few bugs, and trying to make sure I understand the grammar of generics. Here's what I've got. Can someone correct me, if I'm wrong? I've lifted comments from a couple of functions, so you can ignore the words "matches" and "where". Also, the definition of 'ty' is not provided :). I'm assuming a hopefully-obvious BNF syntax. >> >> John >> >> >> >> // matches generics = ( ) | ( < > ) | ( < typaramseq > ) | ( < lifetimes > ) | ( < lifetimes , typaramseq > ) >> // where typaramseq = ( typaram ) | ( typaram , typaramseq ) >> >> // matches typaram = IDENT optbounds >> >> // matches optbounds = ( ( : ( boundseq )? )? ) >> // where boundseq = ( bound + boundseq ) | ( bound ) >> // and bound = ( & STATIC ) | ( ty ) >> >> _______________________________________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1360 bytes Desc: not available URL: From niko at alum.mit.edu Thu Mar 21 13:56:40 2013 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 21 Mar 2013 16:56:40 -0400 Subject: [rust-dev] figuring out grammar for generics In-Reply-To: <00A59151-60B5-411B-8966-00C5CE0C3C41@brinckerhoff.org> References: <514B69C0.1020100@alum.mit.edu> <00A59151-60B5-411B-8966-00C5CE0C3C41@brinckerhoff.org> Message-ID: <514B7408.3020007@alum.mit.edu> I think we should be consistent and allow them everywhere or nowhere. Niko > John Clements > March 21, 2013 4:52 PM > > > > Yes, I neglected to include the defn of lifetimes. > > It looks to me like the current compiler allows trailing commas after > lifetimes, but not after type parameters (sigh). I'm assuming that's > not the best solution. What should it be? > > John > > > Niko Matsakis > March 21, 2013 4:12 PM > That looks about right, though > > (1) as we said on IRC `&static` ought to be changed to `'static` (or, > eventually, any lifetime name). > (2) I presume lifetimes = lifetime | lifetime, lifetimes > (3) we typically allow trailing commas, and we probably do here as > well (or at least probably should?). > > > Niko > > John Clements > March 21, 2013 3:07 PM > I'm just fixing a few bugs, and trying to make sure I understand the > grammar of generics. Here's what I've got. Can someone correct me, if > I'm wrong? I've lifted comments from a couple of functions, so you can > ignore the words "matches" and "where". Also, the definition of 'ty' > is not provided :). I'm assuming a hopefully-obvious BNF syntax. > > John > > > > // matches generics = ( ) | ( < > ) | ( < typaramseq > ) | ( < > lifetimes > ) | ( < lifetimes , typaramseq > ) > // where typaramseq = ( typaram ) | ( typaram , typaramseq ) > > // matches typaram = IDENT optbounds > > // matches optbounds = ( ( : ( boundseq )? )? ) > // where boundseq = ( bound + boundseq ) | ( bound ) > // and bound = ( & STATIC ) | ( ty ) > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1306 bytes Desc: not available URL: From jack at metajack.im Thu Mar 21 19:32:25 2013 From: jack at metajack.im (Jack Moffitt) Date: Thu, 21 Mar 2013 20:32:25 -0600 Subject: [rust-dev] TCP Socket Non-blocking IO In-Reply-To: <78492d7b-5742-4c16-9b72-3389b9b1a2d1@email.android.com> References: <78492d7b-5742-4c16-9b72-3389b9b1a2d1@email.android.com> Message-ID: > In principle the right pattern for this might be two tasks with the same > socket? I don't know if rust's socket abstraction would like that or not. I thought some more about this and I think some kind of non-blocking read will be necessary. The Erlang way I mentioned must do this in the library, as it sends each incoming packet as a message to the process that owns the socket. A similar abstraction could be done in rust, but would only really make sense if you can do periodic reads on the socket to see if there is new data, or have the socket notify you. One idea is to hand the socket functions a channel to send notifications on, and then you can just peek() on the port to see if data is ready. Another lower level idea would just be to allow a read(0) which returns any data that is available. Actually, reading the docs a bit closer, it looks like read_start() may do what you want. It returns a port which you can peek(). That may work. Alternatively, you might try calling read() with a timeout of 1, which isn't ideal, but will probably tide you over. jack. From pwalton at mozilla.com Fri Mar 22 16:51:20 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 22 Mar 2013 16:51:20 -0700 Subject: [rust-dev] RFC: Namespace enum variants under the enum Message-ID: <514CEE78.3090205@mozilla.com> Hi everyone, It's been proposed that we place enum variants under the enum itself. That is: enum Option { None, Some, } Would be accessed as: fn main() { let x = Option::None; } The advantages of this are: * Rust programmers very frequently generate ad-hoc prefixes to group variants under their namespaces. Prefixes seem to me to be the sincerest form of feature request for namespaces. (See Objective-C or Gecko `NSFoo`, GLib `g_`, etc.) * You can get the old behavior with `use` or `pub use`. * Other modules can import all variants belonging to an enum by simply writing (say) `use option::Option::*;`. This is a common thing to want and would, for example, eliminate all the `use obsolete::{ObsoleteFoo, ObsoleteBar, ...}` cruft in `parser.rs`. Note that Haskell introduced special notation for this into their `import` statements. * C++11 went the direction of enum variant namespacing with `enum class`. I worry we may be making the same mistake that led them to introduce two incompatible versions of enums. * This may clean up the `use core::option::Option` stuttering in the `option` module (and in a few related cases, like `std::list::List`). Instead of having types like `std::option::Option`, variants like `std::option::None`, and methods like `std::option::Option::is_none`, we could have simply `std::Option`, `std::Option::None`, and `std::Option::is_none` respectively. This seems to read nicer. The disadvantages are: * `::` will show up for many casual uses of enums. e.g. enum Color { Red, Green, Blue } fn main() { let x = Color::Red; match x { Color::Red => ... Color::Green => ... Color::Blue => ... } } Thoughts? This would be a very late-stage change that will break pretty much all Rust code in existence, and it has disadvantages, but the advantages seem compelling enough to consider it... Patrick From martindemello at gmail.com Fri Mar 22 17:10:21 2013 From: martindemello at gmail.com (Martin DeMello) Date: Fri, 22 Mar 2013 17:10:21 -0700 Subject: [rust-dev] RFC: Namespace enum variants under the enum In-Reply-To: <514CEE78.3090205@mozilla.com> References: <514CEE78.3090205@mozilla.com> Message-ID: Since this is breaking everything anyway, how about syntax to let the match run inside the enum namespace? e.g. enum Color { Red, Green, Blue } fn main() { let x = Color::Red; match Color::{x} { Red => ... Green => ... Blue => ... } } Or even infer that x is of type Color and let the compiler transparently allow omitting the prefix within the match. That would remove the primary source of "noisy boilerplate". martin On Fri, Mar 22, 2013 at 4:51 PM, Patrick Walton wrote: > Hi everyone, > > It's been proposed that we place enum variants under the enum itself. That > is: > > enum Option { > None, > Some, > } > > Would be accessed as: > > fn main() { > let x = Option::None; > } > > The advantages of this are: > > * Rust programmers very frequently generate ad-hoc prefixes to group > variants under their namespaces. Prefixes seem to me to be the sincerest > form of feature request for namespaces. (See Objective-C or Gecko `NSFoo`, > GLib `g_`, etc.) > > * You can get the old behavior with `use` or `pub use`. > > * Other modules can import all variants belonging to an enum by simply > writing (say) `use option::Option::*;`. This is a common thing to want and > would, for example, eliminate all the `use obsolete::{ObsoleteFoo, > ObsoleteBar, ...}` cruft in `parser.rs`. Note that Haskell introduced > special notation for this into their `import` statements. > > * C++11 went the direction of enum variant namespacing with `enum class`. I > worry we may be making the same mistake that led them to introduce two > incompatible versions of enums. > > * This may clean up the `use core::option::Option` stuttering in the > `option` module (and in a few related cases, like `std::list::List`). > Instead of having types like `std::option::Option`, variants like > `std::option::None`, and methods like `std::option::Option::is_none`, we > could have simply `std::Option`, `std::Option::None`, and > `std::Option::is_none` respectively. This seems to read nicer. > > The disadvantages are: > > * `::` will show up for many casual uses of enums. e.g. > > enum Color { Red, Green, Blue } > fn main() { > let x = Color::Red; > match x { > Color::Red => ... > Color::Green => ... > Color::Blue => ... > } > } > > Thoughts? This would be a very late-stage change that will break pretty much > all Rust code in existence, and it has disadvantages, but the advantages > seem compelling enough to consider it... > > Patrick > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From pwalton at mozilla.com Fri Mar 22 17:41:45 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 22 Mar 2013 17:41:45 -0700 Subject: [rust-dev] RFC: Namespace enum variants under the enum In-Reply-To: References: <514CEE78.3090205@mozilla.com> Message-ID: <514CFA49.5050308@mozilla.com> On 3/22/13 5:10 PM, Martin DeMello wrote: > Since this is breaking everything anyway, how about syntax to let the > match run inside the enum namespace? e.g. > > enum Color { Red, Green, Blue } > fn main() { > let x = Color::Red; > match Color::{x} { > Red => ... > Green => ... > Blue => ... > } > } Seems to add complexity to the grammar for something that could be done with `use self::Color::*;` > Or even infer that x is of type Color and let the compiler > transparently allow omitting the prefix within the match. That would intertwine name resolution and typechecking, which would add a lot of complexity to the compiler (if it's even coherent to do so; it might not be). Patrick From jeaye at arrownext.com Fri Mar 22 17:53:21 2013 From: jeaye at arrownext.com (Jeaye Wilkerson) Date: Fri, 22 Mar 2013 17:53:21 -0700 Subject: [rust-dev] RFC: Namespace enum variants under the enum In-Reply-To: <514CFA49.5050308@mozilla.com> References: <514CEE78.3090205@mozilla.com> <514CFA49.5050308@mozilla.com> Message-ID: <94E71987-AE4C-4B8B-8A61-11A65168486F@arrownext.com> This seems like it'd be a great move for organizing enums more and clearing up some redundant module resolution. I think that trying to clean things up in a 'match' would just complicate matters; I don't see the problem in either scoping the enum or 'using' it within the module. You make a great point, Patrick, about C++ and its addition of 'enum class' in C++11; I'd say it was a great move and it might be best to make the same decision as early as possible. Since I don't consider the additional scope resolution a problem, I'd say the biggest downside is probably the invalidation of nearly all existing Rust code. Jeaye On Mar 22, 2013, at 5:41 PM, Patrick Walton wrote: > On 3/22/13 5:10 PM, Martin DeMello wrote: >> Since this is breaking everything anyway, how about syntax to let the >> match run inside the enum namespace? e.g. >> >> enum Color { Red, Green, Blue } >> fn main() { >> let x = Color::Red; >> match Color::{x} { >> Red => ... >> Green => ... >> Blue => ... >> } >> } > > Seems to add complexity to the grammar for something that could be done with `use self::Color::*;` > >> Or even infer that x is of type Color and let the compiler >> transparently allow omitting the prefix within the match. > > That would intertwine name resolution and typechecking, which would add a lot of complexity to the compiler (if it's even coherent to do so; it might not be). > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From pwalton at mozilla.com Fri Mar 22 18:16:27 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 22 Mar 2013 18:16:27 -0700 Subject: [rust-dev] RFC: Namespace enum variants under the enum In-Reply-To: <514CEE78.3090205@mozilla.com> References: <514CEE78.3090205@mozilla.com> Message-ID: <514D026B.6080408@mozilla.com> On 3/22/13 4:51 PM, Patrick Walton wrote: > * `::` will show up for many casual uses of enums. e.g. > > enum Color { Red, Green, Blue } > fn main() { > let x = Color::Red; > match x { > Color::Red => ... > Color::Green => ... > Color::Blue => ... > } > } The more I think about this, the more I dislike the chattiness here. No other functional language that I know of namespaces variants under the sum type. Also notice how if you consider this analogous to object-oriented inheritance (like Scala `case class`), it's somewhat strange; Red, Green, and Blue are just "subtypes" of Color, and subtyping doesn't imply namespacing. Maybe C++11 actually did the right thing with having two forms. strcat suggested `enum mod` to opt in to namespacing the variants under the enum. That would be backwards compatible. Patrick From pnathan at vandals.uidaho.edu Fri Mar 22 19:41:16 2013 From: pnathan at vandals.uidaho.edu (Paul Nathan) Date: Fri, 22 Mar 2013 19:41:16 -0700 Subject: [rust-dev] RFC: Namespace enum variants under the enum In-Reply-To: <514CEE78.3090205@mozilla.com> References: <514CEE78.3090205@mozilla.com> Message-ID: <514D164C.1000802@vandals.uidaho.edu> On 03/22/2013 04:51 PM, Patrick Walton wrote: > Hi everyone, > > It's been proposed that we place enum variants under the enum itself. > That is: > [snip] > > * `::` will show up for many casual uses of enums. e.g. > > enum Color { Red, Green, Blue } > fn main() { > let x = Color::Red; > match x { > Color::Red => ... > Color::Green => ... > Color::Blue => ... > } > } > > I'm going to come on in and contribute to the bikeshed... I think this is pretty stanky. Everything else in your proposal seems to be really clean: less typing for a lot of things. But in this particular snippet, in-file use shouldn't, IMO, have that level of noise. I would think that local use should propagate out to the in-file namespace. -- Regards, Paul From jeaye at arrownext.com Fri Mar 22 20:03:05 2013 From: jeaye at arrownext.com (Jeaye) Date: Fri, 22 Mar 2013 20:03:05 -0700 Subject: [rust-dev] RFC: Namespace enum variants under the enum In-Reply-To: <514D164C.1000802@vandals.uidaho.edu> References: <514CEE78.3090205@mozilla.com> <514D164C.1000802@vandals.uidaho.edu> Message-ID: <514D1B69.4060606@arrownext.com> On 03/22/2013 07:41 PM, Paul Nathan wrote: > I'm going to come on in and contribute to the bikeshed... I think this > is pretty stanky. Everything else in your proposal seems to be really > clean: less typing for a lot of things. But in this particular snippet, > in-file use shouldn't, IMO, have that level of noise. I would think that > local use should propagate out to the in-file namespace. > > 'enum mod' does sounds like a fair approach to this; it flows more logically than 'enum class', too. This allows the extra verbosity to be disabled by default. I wonder, how many internals of Rust would accept this change willingly to clean up the public interface? How much can the API benefit from it (where the benefit to usercode is obvious)? Jeaye From cpeterson at mozilla.com Sat Mar 23 22:52:47 2013 From: cpeterson at mozilla.com (Chris Peterson) Date: Sat, 23 Mar 2013 22:52:47 -0700 (PDT) Subject: [rust-dev] Proposal to replace the `as` keyword with syntax In-Reply-To: <832079581.1086470.1364103989965.JavaMail.root@mozilla.com> Message-ID: <1300203672.1086488.1364104367905.JavaMail.root@mozilla.com> To reduce the number of rust keywords, I offer the lowly colon as alternative syntax for the `as` keyword. Today, the colon is used to add a type annotation to a variable declaration. I think there is a nice symmetry if the colon could also be used for type cast expressions. With a one-line code change to parser.rs, the following code compiles as expected: fn main() { // old style let a = 1u8; let _b: u16 = a as u16; // new style let a = 1: u8; let _b: u16 = a: u16; } chris From zack at z0w0.me Sun Mar 24 00:00:46 2013 From: zack at z0w0.me (Zack Corr) Date: Sun, 24 Mar 2013 17:00:46 +1000 Subject: [rust-dev] Proposal to replace the `as` keyword with syntax In-Reply-To: <1300203672.1086488.1364104367905.JavaMail.root@mozilla.com> References: <832079581.1086470.1364103989965.JavaMail.root@mozilla.com> <1300203672.1086488.1364104367905.JavaMail.root@mozilla.com> Message-ID: I was about to say something along the lines of "yuck" but after looking at it for a bit longer it actually doesn't look too bad. On 24 Mar 2013 15:52, "Chris Peterson" wrote: > To reduce the number of rust keywords, I offer the lowly colon as > alternative syntax for the `as` keyword. > > Today, the colon is used to add a type annotation to a variable > declaration. I think there is a nice symmetry if the colon could also be > used for type cast expressions. > > With a one-line code change to parser.rs, the following code compiles as > expected: > > fn main() { > // old style > let a = 1u8; > let _b: u16 = a as u16; > > // new style > let a = 1: u8; > let _b: u16 = a: u16; > } > > > chris > _______________________________________________ > 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 Sun Mar 24 01:09:57 2013 From: pwalton at mozilla.com (Patrick Walton) Date: Sun, 24 Mar 2013 01:09:57 -0700 Subject: [rust-dev] Proposal to replace the `as` keyword with syntax In-Reply-To: <1300203672.1086488.1364104367905.JavaMail.root@mozilla.com> References: <1300203672.1086488.1364104367905.JavaMail.root@mozilla.com> Message-ID: <514EB4D5.4040102@mozilla.com> On 3/23/13 10:52 PM, Chris Peterson wrote: > To reduce the number of rust keywords, I offer the lowly colon as > alternative syntax for the `as` keyword. I'd like to use the colon for type ascription (i.e. an *assertion* that a value has some type), which is different from a cast. This would be useful to help along the typechecker in cases in which it doesn't have enough information to determine the result of an expression. For example: trait Number { fn make_number() -> Self; fn incr(self) -> Self; } impl Number for int { fn make_number() -> int { 1 } fn incr(self) -> int { self + 1 } } impl Number for uint { fn make_number() -> uint { 2 } fn incr(self) -> uint { self + 1 } } fn main() { println(Number::make_number().incr().to_str()); } This results in an error because the typechecker can't tell whether 2 or 3 should be printed. But type ascription would solve it: fn main() { println(Number::make_number():int.incr().to_str()); // 2 } However, a cast to int with `as` would convert both uint and int to int and therefore it wouldn't help the typechecker enough. Patrick From thadguidry at gmail.com Sun Mar 24 07:01:26 2013 From: thadguidry at gmail.com (Thad Guidry) Date: Sun, 24 Mar 2013 09:01:26 -0500 Subject: [rust-dev] Proposal to replace the `as` keyword with syntax In-Reply-To: <1300203672.1086488.1364104367905.JavaMail.root@mozilla.com> References: <832079581.1086470.1364103989965.JavaMail.root@mozilla.com> <1300203672.1086488.1364104367905.JavaMail.root@mozilla.com> Message-ID: That's similar to Type Casts in SQL languages... for instance PostgreSQL can use AS or use 2 colons to assert the Type being cast: CAST ( expression AS type )expression::type -- -Thad http://www.freebase.com/view/en/thad_guidry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeaye at arrownext.com Sun Mar 24 20:47:40 2013 From: jeaye at arrownext.com (Jeaye) Date: Sun, 24 Mar 2013 20:47:40 -0700 Subject: [rust-dev] Proposal to replace the `as` keyword with syntax In-Reply-To: <1300203672.1086488.1364104367905.JavaMail.root@mozilla.com> References: <1300203672.1086488.1364104367905.JavaMail.root@mozilla.com> Message-ID: <514FC8DC.30507@arrownext.com> On 03/23/2013 10:52 PM, Chris Peterson wrote: > > With a one-line code change to parser.rs, the following code compiles as expected: > > fn main() { > // old style > let a = 1u8; > let _b: u16 = a as u16; > > // new style > let a = 1: u8; > let _b: u16 = a: u16; > } I really like this syntax, and it has the added benefit of being consistent with type annotations; it seems very fluent, just with the two-line example given above. +1 from me. Jeaye From clements at brinckerhoff.org Mon Mar 25 13:23:32 2013 From: clements at brinckerhoff.org (John Clements) Date: Mon, 25 Mar 2013 13:23:32 -0700 Subject: [rust-dev] JFYI: ANTLR grammar for Rust tokens Message-ID: Following an offhand comment of Patrick's on Friday, I decided to take a look and see just how easy it is to formulate an ANTLR grammar. The answer is: very, very easy. I wrote up a simple grammar for Rust tokens; it's up at https://github.com/jbclements/rust-antlr/ The tokens work great, and so does a simple token-tree parser; it can now parse large rust files into token trees. I started adding an AST-level parser, but it's just got bits & pieces of the grammar, for now. John From cpeterson at mozilla.com Mon Mar 25 16:58:45 2013 From: cpeterson at mozilla.com (Chris Peterson) Date: Mon, 25 Mar 2013 16:58:45 -0700 Subject: [rust-dev] Proposal to replace the `as` keyword with syntax In-Reply-To: <514EB4D5.4040102@mozilla.com> References: <1300203672.1086488.1364104367905.JavaMail.root@mozilla.com> <514EB4D5.4040102@mozilla.com> Message-ID: <5150E4B5.2010300@mozilla.com> On 3/24/13 1:09 AM, Patrick Walton wrote: > I'd like to use the colon for type ascription (i.e. an *assertion* > that a value has some type), which is different from a cast. This > would be useful to help along the typechecker in cases in which it > doesn't have enough information to determine the result of an > expression. For example: I see that Scala uses the colon for type ascription like you describe, so you have precedent on your side. :) http://docs.scala-lang.org/style/types.html#ascription Similar syntax is OCaml's :> for (static) upcasts and :?> for (dynamic) downcasts. That's not helpful for casting types that don't have a subtype relationship, such as u8 and u16 in my example earlier. However, rust's integral types could be special-cased such that: let big = 0x54321; let a = big :> u16; // big & 0xffff truncated like C let b = big :?> u16; // fail! runtime error because big is out of range chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From someone at mearie.org Tue Mar 26 02:24:09 2013 From: someone at mearie.org (Kang Seonghoon) Date: Tue, 26 Mar 2013 18:24:09 +0900 Subject: [rust-dev] Proposal to replace the `as` keyword with syntax Message-ID: Actually this makes more sense, due to the following analogy: // given this: let x = ~"foo"; let v; // ensures that `v` is of type `&str` v: &str = s; // ensures that `v` is of type `&str` by declaring it let w: &str = s; Patrick Walton wrote: > > On 3/23/13 10:52 PM, Chris Peterson wrote: >> To reduce the number of rust keywords, I offer the lowly colon as >> alternative syntax for the `as` keyword. > > I'd like to use the colon for type ascription (i.e. an *assertion* that > a value has some type), which is different from a cast. This would be > useful to help along the typechecker in cases in which it doesn't have > enough information to determine the result of an expression. For example: > > trait Number { > fn make_number() -> Self; > fn incr(self) -> Self; > } > > impl Number for int { > fn make_number() -> int { 1 } > fn incr(self) -> int { self + 1 } > } > > impl Number for uint { > fn make_number() -> uint { 2 } > fn incr(self) -> uint { self + 1 } > } > > fn main() { > println(Number::make_number().incr().to_str()); > } > > This results in an error because the typechecker can't tell whether 2 or > 3 should be printed. But type ascription would solve it: > > fn main() { > println(Number::make_number():int.incr().to_str()); // 2 > } > > However, a cast to int with `as` would convert both uint and int to int > and therefore it wouldn't help the typechecker enough. > > Patrick -- -- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/ -- Opinions expressed in this email do not necessarily represent the views of my employer. -- From pnkfelix at mozilla.com Tue Mar 26 07:57:38 2013 From: pnkfelix at mozilla.com (Felix S. Klock II) Date: Tue, 26 Mar 2013 15:57:38 +0100 Subject: [rust-dev] JFYI: ANTLR grammar for Rust tokens In-Reply-To: References: Message-ID: <5151B762.1070805@mozilla.com> Cool, John beat me to the punch and posted a grammar to a repository! (And better still, John's grammar looks way more complete than my own.) I went ahead and shoved my version of Rust.g4 into a branch on a fork of your repo, so that people can skim and compare the approaches. (E.g. the use of named terminals such a LPAREN versus hard-coding them as literals in the productions.) https://github.com/pnkfelix/rust-antlr/blob/pnkfelix-draft-from-rust-manual/Rust.g4 Note the above link is not expected to actually work on real rust expressions of any size. I was working by transcribing from the manual; I infer that John took a much different tack, perhaps using the parser source as a basis...? In any case, I am posting this mostly to stimulate thought as to what tack to take that will best integrate both with our code and also with our documentation. Cheers, -Felix On Mon Mar 25 21:23:32 2013, John Clements wrote: > Following an offhand comment of Patrick's on Friday, I decided to take a look and see just how easy it is to formulate an ANTLR grammar. The answer is: very, very easy. I wrote up a simple grammar for Rust tokens; it's up at > > https://github.com/jbclements/rust-antlr/ > > The tokens work great, and so does a simple token-tree parser; it can now parse large rust files into token trees. I started adding an AST-level parser, but it's just got bits & pieces of the grammar, for now. > > John > > _______________________________________________ > 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.org From clements at brinckerhoff.org Tue Mar 26 08:02:03 2013 From: clements at brinckerhoff.org (John Clements) Date: Tue, 26 Mar 2013 08:02:03 -0700 Subject: [rust-dev] JFYI: ANTLR grammar for Rust tokens In-Reply-To: <5151B762.1070805@mozilla.com> References: <5151B762.1070805@mozilla.com> Message-ID: <8FDB9AB9-704C-432C-92F1-C1EAD9F0CE0D@brinckerhoff.org> On Mar 26, 2013, at 7:57 AM, Felix S. Klock II wrote: > Cool, John beat me to the punch and posted a grammar to a repository! > > (And better still, John's grammar looks way more complete than my own.) > > I went ahead and shoved my version of Rust.g4 into a branch on a fork of your repo, so that people can skim and compare the approaches. (E.g. the use of named terminals such a LPAREN versus hard-coding them as literals in the productions.) > > https://github.com/pnkfelix/rust-antlr/blob/pnkfelix-draft-from-rust-manual/Rust.g4 > > Note the above link is not expected to actually work on real rust expressions of any size. I was working by transcribing from the manual; I infer that John took a much different tack, perhaps using the parser source as a basis...? In any case, I am posting this mostly to stimulate thought as to what tack to take that will best integrate both with our code and also with our documentation. Yes, I went entirely from lexer/parser source. I'll take a look at yours. Anyone else: is this something we're interested in? FWIW, I'm guessing that the parser generated directly from ANTLR would be not directly useful to us, but it might have value in two ways: 1) documentation, 2) verification that our language is LL(3) (or whatever), and 3) for future use when we write our own parser generator (or develop a Rust back-end for something fast like yacc). John > > Cheers, > -Felix > > > On Mon Mar 25 21:23:32 2013, John Clements wrote: >> Following an offhand comment of Patrick's on Friday, I decided to take a look and see just how easy it is to formulate an ANTLR grammar. The answer is: very, very easy. I wrote up a simple grammar for Rust tokens; it's up at >> >> https://github.com/jbclements/rust-antlr/ >> >> The tokens work great, and so does a simple token-tree parser; it can now parse large rust files into token trees. I started adding an AST-level parser, but it's just got bits & pieces of the grammar, for now. >> >> John >> >> _______________________________________________ >> 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.org > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From matthieu.monrocq at gmail.com Tue Mar 26 10:38:05 2013 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Tue, 26 Mar 2013 18:38:05 +0100 Subject: [rust-dev] JFYI: ANTLR grammar for Rust tokens In-Reply-To: <8FDB9AB9-704C-432C-92F1-C1EAD9F0CE0D@brinckerhoff.org> References: <5151B762.1070805@mozilla.com> <8FDB9AB9-704C-432C-92F1-C1EAD9F0CE0D@brinckerhoff.org> Message-ID: On Tue, Mar 26, 2013 at 4:02 PM, John Clements wrote: > > On Mar 26, 2013, at 7:57 AM, Felix S. Klock II wrote: > > > Cool, John beat me to the punch and posted a grammar to a repository! > > > > (And better still, John's grammar looks way more complete than my own.) > > > > I went ahead and shoved my version of Rust.g4 into a branch on a fork of > your repo, so that people can skim and compare the approaches. (E.g. the > use of named terminals such a LPAREN versus hard-coding them as literals in > the productions.) > > > > > https://github.com/pnkfelix/rust-antlr/blob/pnkfelix-draft-from-rust-manual/Rust.g4 > > > > Note the above link is not expected to actually work on real rust > expressions of any size. I was working by transcribing from the manual; I > infer that John took a much different tack, perhaps using the parser source > as a basis...? In any case, I am posting this mostly to stimulate thought > as to what tack to take that will best integrate both with our code and > also with our documentation. > > Yes, I went entirely from lexer/parser source. > > I'll take a look at yours. Anyone else: is this something we're interested > in? FWIW, I'm guessing that the parser generated directly from ANTLR would > be not directly useful to us, but it might have value in two ways: > 1) documentation, > 2) verification that our language is LL(3) (or whatever), and > 3) for future use when we write our own parser generator (or develop a > Rust back-end for something fast like yacc). > > John > > Graydon was definitely interested in 2); at the very least to prove that the language does not contain inherent ambiguities that had been missed so far. -- Matthieu > > > > Cheers, > > -Felix > > > > > > On Mon Mar 25 21:23:32 2013, John Clements wrote: > >> Following an offhand comment of Patrick's on Friday, I decided to take > a look and see just how easy it is to formulate an ANTLR grammar. The > answer is: very, very easy. I wrote up a simple grammar for Rust tokens; > it's up at > >> > >> https://github.com/jbclements/rust-antlr/ > >> > >> The tokens work great, and so does a simple token-tree parser; it can > now parse large rust files into token trees. I started adding an AST-level > parser, but it's just got bits & pieces of the grammar, for now. > >> > >> John > >> > >> _______________________________________________ > >> 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.org > > > > _______________________________________________ > > 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 peterhull90 at gmail.com Wed Mar 27 06:31:14 2013 From: peterhull90 at gmail.com (Peter Hull) Date: Wed, 27 Mar 2013 13:31:14 +0000 Subject: [rust-dev] JFYI: ANTLR grammar for Rust tokens In-Reply-To: <8FDB9AB9-704C-432C-92F1-C1EAD9F0CE0D@brinckerhoff.org> References: <5151B762.1070805@mozilla.com> <8FDB9AB9-704C-432C-92F1-C1EAD9F0CE0D@brinckerhoff.org> Message-ID: On Tue, Mar 26, 2013 at 3:02 PM, John Clements wrote: I'll take a look at yours. Anyone else: is this something we're interested > in? FWIW, I'm guessing that the parser generated directly from ANTLR would > be not directly useful to us, but it might have value in two ways: > Another use: if one were developing a Rust module for Eclipse or Netbeans IDE, a Java-friendly lexer/parser is needed. (I think) Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Wed Mar 27 11:46:30 2013 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 27 Mar 2013 11:46:30 -0700 Subject: [rust-dev] JFYI: ANTLR grammar for Rust tokens In-Reply-To: References: <5151B762.1070805@mozilla.com> <8FDB9AB9-704C-432C-92F1-C1EAD9F0CE0D@brinckerhoff.org> Message-ID: As always, trying to get Rust and associated projects some more exposure: http://thechangelog.com/rust-antlr-an-antlr-grammar-for-rust/ https://twitter.com/TheChangelog/status/316984377047392257 <3 <3 <3 Neat project! From clements at brinckerhoff.org Wed Mar 27 16:30:26 2013 From: clements at brinckerhoff.org (John Clements) Date: Wed, 27 Mar 2013 16:30:26 -0700 Subject: [rust-dev] JFYI: ANTLR grammar for Rust tokens In-Reply-To: References: <5151B762.1070805@mozilla.com> <8FDB9AB9-704C-432C-92F1-C1EAD9F0CE0D@brinckerhoff.org> Message-ID: On Mar 27, 2013, at 11:46 AM, Steve Klabnik wrote: > As always, trying to get Rust and associated projects some more exposure: > > http://thechangelog.com/rust-antlr-an-antlr-grammar-for-rust/ > > https://twitter.com/TheChangelog/status/316984377047392257 Whoa? publicity. scary. I did a bunch more work today on the grammar? and now ANTLR is signalling NullPointerException trying to compile it :). Thanks for the push! John From banderson at mozilla.com Sat Mar 30 23:26:25 2013 From: banderson at mozilla.com (Brian Anderson) Date: Sat, 30 Mar 2013 23:26:25 -0700 Subject: [rust-dev] 0.6 prerelease testing Message-ID: <5157D711.2080205@mozilla.com> Greetings, Here's a prerelease build of Rust 0.6: http://static.rust-lang.org/dist/rust-0.6.tar.gz http://static.rust-lang.org/dist/rust-0.6-install.exe With sha256's: ebc7ff9dd1a72c9d23e3276c94c8d34b55ff622a0eb1aea4b61d78850e1c5b7e rust-0.6.tar.gz 5ccfc062242562956f1fdfd252cf16744d704893799404774aa6a6a02065e7b0 rust-0.6-install.exe It's about time for 0.6, and it looks like all the critical features are in, so we've got a build ready for testing. This is _not_ a signed release, just a candidate. If you have some spare cycles please give this an install and report whether it does what you expect. If all goes well we will release 0.6 in the next few days. Our new integration process with bors has been keeping the tree consistently green so I feel much more confident in this release than previous ones. We mostly want to prove that the install works on platforms we tend to support (OS X 10.6+, various Linuxes, and Windows 7 & 2008) and the compiler generally behaves as expected, considering the various known issues. If you have fixes or features you are passionate about then now is the time to confirm they are working as intended. We are doing time based releases though, so there's no need to sweat the small things - there will be another one in a few months. -Brian From asb at asbradbury.org Sun Mar 31 14:21:25 2013 From: asb at asbradbury.org (Alex Bradbury) Date: Sun, 31 Mar 2013 22:21:25 +0100 Subject: [rust-dev] Rust per-process private memory overhead Message-ID: I had a quick play with Rust 0.6 built on my x86-64 machine, using ps_mem.py () to see how much private memory is required for each process. I was wondering what is the cause of the reasonably large amount of memory required for each Rust process. My test program simply prints "hello?" and sleeps for 60 seconds. I run 5 of these processes, and then collect the memory usage. A full log is below, but in summary my results for Rust (0.6RC), C (glibc 2.5 and gcc 4.7.2) and Go (1.0.3) are as follows. Results are in format Private + Shared = Total, see ps_mem.py for the memory accounting methodology. Rust: 8.9 MiB + 785.0 KiB = 9.7 MiB hello (5) C: 452.0 KiB + 55.0 KiB = 507.0 KiB hello (5) Go: 1.9 MiB + 520.0 KiB = 2.4 MiB hello (5) Any ideas as to why Rust is so heavy on memory usage (and is there an existing issue on the bug tracker?) $ cat hello.rs fn main() { io::println("hello?"); unsafe { libc::sleep(60); } } $ rustc -O hello.rs $ for i in 1 2 3 4 5; do ./hello & done $ sudo python ~/ps_mem.py | grep -i hello 8.9 MiB + 785.0 KiB = 9.7 MiB hello (5) The same for C: $ cat hello.c #include #include int main(void) { printf("hello?\n"); sleep(60); return 0; } $ gcc -O3 hello.c -o hello $ for i in 1 2 3 4 5; do ./hello & done $ sudo python ~/ps_mem.py | grep -i hello 452.0 KiB + 55.0 KiB = 507.0 KiB hello (5) The same for Go 1.0.3: $ cat hello.go package main import "fmt" import "time" func main() { fmt.Println("hello?") time.Sleep(60*time.Second) } $ go build hello.go $ for i in 1 2 3 4 5; do ./hello & done $ sudo python ~/ps_mem.py | grep -i hello 1.9 MiB + 520.0 KiB = 2.4 MiB hello (5) Thanks, Alex From banderson at mozilla.com Sun Mar 31 16:52:55 2013 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 31 Mar 2013 16:52:55 -0700 Subject: [rust-dev] 0.6 prerelease testing In-Reply-To: <5BC9FD56-E476-4ADD-8116-5D5C50791E5E@csperkins.org> References: <5157D711.2080205@mozilla.com> <5BC9FD56-E476-4ADD-8116-5D5C50791E5E@csperkins.org> Message-ID: <5158CC57.60902@mozilla.com> Thanks. `OS` is set in libuv's [build.mk] with OS ?= $(shell sh -c 'uname -s | tr "[A-Z]" "[a-z]"') Perhaps it is failing somehow, though it seems unlikely. I've opened an [issue] and will try to reproduce it. [build.mk]: https://github.com/brson/libuv/blob/master/build.mk#L21 [issue]: https://github.com/mozilla/rust/issues/5650 On 03/31/2013 06:36 AM, Colin Perkins wrote: > Hi, > > Trying to compile this on MacOS 10.7.5, I get the following build error in libuv: > > ... > ar rcs libuv.a src/unix/async.o src/unix/core.o src/unix/dl.o src/unix/error.o src/unix/fs.o src/unix/getaddrinfo.o src/unix/loop.o src/unix/loop-watcher.o src/unix/pipe.o src/unix/poll.o src/unix/process.o src/unix/signal.o src/unix/stream.o src/unix/tcp.o src/unix/thread.o src/unix/threadpool.o src/unix/timer.o src/unix/tty.o src/unix/udp.o src/fs-poll.o src/uv-common.o src/inet.o > link: rt/x86_64-apple-darwin/librustrt.dylib > Undefined symbols for architecture x86_64: > "_uv__hrtime", referenced from: > _uv_hrtime in libuv.a(core.o) > _uv__update_time in libuv.a(core.o) > _uv__loop_init in libuv.a(loop.o) > "_uv__fs_event_close", referenced from: > _uv_close in libuv.a(core.o) > "_uv__io_poll", referenced from: > _uv_run in libuv.a(core.o) > "_uv__platform_loop_init", referenced from: > _uv__loop_init in libuv.a(loop.o) > "_uv__platform_loop_delete", referenced from: > _uv__loop_delete in libuv.a(loop.o) > ld: symbol(s) not found for architecture x86_64 > collect2: ld returned 1 exit status > make: *** [rt/x86_64-apple-darwin/librustrt.dylib] Error 1 > > I can force it to build correctly by adding an "OS=darwin" around line 184 of mk/rt.mk, so it looks like the build system isn't passing the right parameters to the libuv build for some reason. > > I just tried with incoming from git, and get the same behaviour. > > Colin > > > > > On 31 Mar 2013, at 07:26, Brian Anderson wrote: >> Greetings, >> >> Here's a prerelease build of Rust 0.6: >> >> http://static.rust-lang.org/dist/rust-0.6.tar.gz >> http://static.rust-lang.org/dist/rust-0.6-install.exe >> >> With sha256's: >> >> ebc7ff9dd1a72c9d23e3276c94c8d34b55ff622a0eb1aea4b61d78850e1c5b7e rust-0.6.tar.gz >> 5ccfc062242562956f1fdfd252cf16744d704893799404774aa6a6a02065e7b0 rust-0.6-install.exe >> >> It's about time for 0.6, and it looks like all the critical features are in, so we've got a build ready for testing. This is _not_ a signed release, just a candidate. If you have some spare cycles please give this an install and report whether it does what you expect. If all goes well we will release 0.6 in the next few days. >> >> Our new integration process with bors has been keeping the tree consistently green so I feel much more confident in this release than previous ones. We mostly want to prove that the install works on platforms we tend to support (OS X 10.6+, various Linuxes, and Windows 7 & 2008) and the compiler generally behaves as expected, considering the various known issues. If you have fixes or features you are passionate about then now is the time to confirm they are working as intended. We are doing time based releases though, so there's no need to sweat the small things - there will be another one in a few months. >> >> -Brian >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >