From banderson at mozilla.com Sun Jan 1 00:20:16 2012 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 01 Jan 2012 00:20:16 -0800 (PST) Subject: [rust-dev] names needed for function types In-Reply-To: Message-ID: <10445d8f-c60c-43fd-b66c-d2406fb24d78@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > From: "Kevin Cantu" > To: "Marijn Haverbeke" > Cc: rust-dev at mozilla.org > Sent: Thursday, December 29, 2011 4:06:07 AM > Subject: Re: [rust-dev] names needed for function types > > So, if Rust did away with block, renaming block to fn, would the > behavior of fn definitions be preserved? ?Could the unified fn become > a type that could sometimes be used in places requiring a sendfn or a > lambda, but not always?? I think named fn's would not have a type. When you take their value it creates whichever function type is needed. > > Earlier, I was imagining a hierarchy like fn < sendfn < lambda < > block, where it would seem logical to just knock it down to fn < > lambda < block. But there are things I have to learn about sendfn vs. > lambda... For a long time I also imagined a complete ordering, but it's difficult to achieve. From banderson at mozilla.com Sun Jan 1 00:42:06 2012 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 01 Jan 2012 00:42:06 -0800 (PST) Subject: [rust-dev] names needed for function types In-Reply-To: <4EFDFC30.7030706@alum.mit.edu> Message-ID: <688e47de-6f37-4f48-90d9-74f7b512ae70@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > From: "Niko Matsakis" > To: "Brian Anderson" > Cc: rust-dev at mozilla.org > Sent: Friday, December 30, 2011 10:00:16 AM > Subject: Re: [rust-dev] names needed for function types > > 3. `fn[copy]` and `fn[send]`: an alternate version of #2 that I find > more visually appealing. > > Of these, I prefer `fn[copy]` and `fn[send]`. My only reservation is > that the syntax meshes reasonably somewhat awkwardly with capture > clauses in the copy case. A capture clause is used to specify > variables > you wish to copy/move out of the environment; if we moved to > `fn[copy]` > and `fn[send]`, it will also specify the kind restriction. So, you > would write: > > let block_1 = fn(x: T, y: U) -> V { ... }; // currently not > legal > but should be, I think > let boxed_closure_1 = fn[copy](x: T, y: U) -> V { ... }; > let unique_closure_1 = fn[send](x: T, y: U) -> V { ... }; > > and if you wanted to copy the variable `a` out of the environment > explicitly and move the variable `b`, you would write: > > let boxed_closure_2 = fn[copy a; move b](x: T, y: U) -> V { ... > }; > let unique_closure_2 = fn[send; copy a; move b](x: T, y: U) -> V > { > ... }; > > Here you can see that the kind restriction melded with the request to > `copy a`. How did they 'meld'? Is a copying closure just assumed once you decide to copy or move the upvars? Would 'fn[copy; copy a; move b]' still be allowed? > At the moment, explicit copies are unnecessary anyhow, but > I > personally would like to make them required for mutable local > variables > or for variables whose types are not implicitly copyable (per the no > copies proposal I sent out a while back). > > Thoughts? It's ok. I like it better than anything we've come up with so far. I know there are syntax ambiguities, but it would be more consistent if we could write 'let boxed_closure = fn(x: T, y: U) ...'. That could then be potentially extended in an obvious way to named functions as well. -Brian From niko at alum.mit.edu Sun Jan 1 07:14:34 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Sun, 01 Jan 2012 07:14:34 -0800 Subject: [rust-dev] names needed for function types In-Reply-To: <688e47de-6f37-4f48-90d9-74f7b512ae70@zimbra1.shared.sjc1.mozilla.com> References: <688e47de-6f37-4f48-90d9-74f7b512ae70@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4F00785A.3080801@alum.mit.edu> On 1/1/12 12:42 AM, Brian Anderson wrote: > How did they 'meld'? Is a copying closure just assumed once you decide to copy or move the upvars? That's how I envisioned it. If you don't say "send", then the default is a boxed closure. > Would 'fn[copy; copy a; move b]' still be allowed? I'm indifferent on that. I'd probably allow it just because it's easier to write the parser that way, but I could be persuaded to make it illegal fairly easily. It would not be preserved by the pretty printer. > It's ok. I like it better than anything we've come up with so far. I > know there are syntax ambiguities, but it would be more consistent if > we could write 'let boxed_closure = fn(x: T, y: U) ...'. That > could then be potentially extended in an obvious way to named > functions as well. Hmm, I hadn't considered "<" and ">". They look nice; in fact, I rather prefer them to "[" and "]" because they stand out more from the argument list. It need not be ambiguous to the parser as `copy`, `move`, and `send` are keywords (or could be), but it is somewhat ambiguous to the human eye. I think either syntax could easily be extended to (nested) named functions. Using "<" and ">" makes it more awkward to combine with generics. Of course, currently our implementation assumes that functions either capture their environment or define generic parameters, but not both. I am not sure if that is a restriction we will always want, however, although I suspect that you rarely need both in practice. Here is how it would look with square brackets: fn foo() { // Without generics: fn no_env(a: A, b: B) { ... } fn boxed_env[copy](a: A, b: B) { ... } fn boxed_env[copy a; move b](a: A, b: B) { ... } fn unique_env[send; copy a; move b](a: A, b: B) { ... } // With generics: fn no_env(a: A, b: B) { ... } fn boxed_env[copy](a: A, b: B) { ... } fn boxed_env[copy a; move b](a: A, b: B) { ... } fn unique_env[send; copy a; move b](a: A, b: B) { ... } } and with curly braces: fn foo() { // Without generics: fn no_env(a: A, b: B) { ... } fn boxed_env(a: A, b: B) { ... } fn boxed_env(a: A, b: B) { ... } fn unique_env(a: A, b: B) { ... } // With generics: fn no_env(a: A, b: B) { ... } fn boxed_env(a: A, b: B) { ... } fn boxed_env(a: A, b: B) { ... } fn unique_env(a: A, b: B) { ... } } Niko From niko at alum.mit.edu Sun Jan 1 09:37:26 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Sun, 01 Jan 2012 09:37:26 -0800 Subject: [rust-dev] names needed for function types In-Reply-To: <4F00785A.3080801@alum.mit.edu> References: <688e47de-6f37-4f48-90d9-74f7b512ae70@zimbra1.shared.sjc1.mozilla.com> <4F00785A.3080801@alum.mit.edu> Message-ID: <4F0099D6.9030108@alum.mit.edu> > Here is how it would look with square brackets: It occurs to me that the "capture clause" could (and probably should) go before the name, if we allowed it on nested fn item declarations: fn no_env(a: A, b: B) {...} fn boxed_env_1(a: A, b: B) {...} fn boxed_env_2(a: A, b: B) {...} fn unique_env(a: A, b: B) {...} In this way there is no ambiguity at all. (Note that we don't allow function types to have generic parameters at the moment) Niko From banderson at mozilla.com Sun Jan 1 13:32:17 2012 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 01 Jan 2012 13:32:17 -0800 (PST) Subject: [rust-dev] names needed for function types In-Reply-To: <4F0099D6.9030108@alum.mit.edu> Message-ID: <628b7949-a8cb-4981-ad30-1221de7c3906@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > From: "Niko Matsakis" > To: "Brian Anderson" > Cc: rust-dev at mozilla.org > Sent: Sunday, January 1, 2012 9:37:26 AM > Subject: Re: [rust-dev] names needed for function types > > > Here is how it would look with square brackets: > > It occurs to me that the "capture clause" could (and probably should) > go > before the name, if we allowed it on nested fn item declarations: > > fn no_env(a: A, b: B) {...} > fn boxed_env_1(a: A, b: B) {...} > fn boxed_env_2(a: A, b: B) {...} > fn unique_env(a: A, b: B) {...} > > In this way there is no ambiguity at all. (Note that we don't allow > function types to have generic parameters at the moment) > I was thinking that 'copy' and 'send' are kind bounds that apply to the environment instead of a parameter, so it would make sense to write fn boxed_env_1(...) { ... } fn boxed_env_2(a: A, b: B) { ... } The capture clause seems like a different kind of thing, so could still use []. From niko at alum.mit.edu Sun Jan 1 15:49:38 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Sun, 01 Jan 2012 15:49:38 -0800 Subject: [rust-dev] names needed for function types In-Reply-To: <628b7949-a8cb-4981-ad30-1221de7c3906@zimbra1.shared.sjc1.mozilla.com> References: <628b7949-a8cb-4981-ad30-1221de7c3906@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4F00F112.6090503@alum.mit.edu> Ah, I see. That's interesting, not how I thought of it. To me the capture clause and environment kind bound go together, as the kind bound affects the things that can legally be captured (in that sense, I rather like the way that a capture clause mirrors a parameter list: it's like a set of implicit parameters that get carried with the closure). The type parameters (and their associated kind bounds) seem like a separate thing. Niko On 1/1/12 1:32 PM, Brian Anderson wrote: > > ----- Original Message ----- >> From: "Niko Matsakis" >> To: "Brian Anderson" >> Cc: rust-dev at mozilla.org >> Sent: Sunday, January 1, 2012 9:37:26 AM >> Subject: Re: [rust-dev] names needed for function types >> >>> Here is how it would look with square brackets: >> It occurs to me that the "capture clause" could (and probably should) >> go >> before the name, if we allowed it on nested fn item declarations: >> >> fn no_env(a: A, b: B) {...} >> fn boxed_env_1(a: A, b: B) {...} >> fn boxed_env_2(a: A, b: B) {...} >> fn unique_env(a: A, b: B) {...} >> >> In this way there is no ambiguity at all. (Note that we don't allow >> function types to have generic parameters at the moment) >> > I was thinking that 'copy' and 'send' are kind bounds that apply to the environment instead of a parameter, so it would make sense to write > > fn boxed_env_1(...) { ... } > fn boxed_env_2(a: A, b: B) { ... } > > The capture clause seems like a different kind of thing, so could still use []. From marijnh at gmail.com Mon Jan 2 00:02:02 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Mon, 2 Jan 2012 09:02:02 +0100 Subject: [rust-dev] syntactic sugar for blocks in expressions In-Reply-To: <4EFCD222.1040606@alum.mit.edu> References: <4EFCD222.1040606@alum.mit.edu> Message-ID: My first reaction is 'oh god no! that complicates the rules even more!'. But then I remembered how frustrating it is to work out a proposal and have it shot down for vague knee-jerk reasons like that. So, eh, let's just try this for a while and see whether it causes more confusion than the rules we have now. From sebastian.sylvan at gmail.com Tue Jan 3 02:29:16 2012 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Tue, 3 Jan 2012 02:29:16 -0800 Subject: [rust-dev] Deca, a new language with goals that largely overlap those of Rust Message-ID: Saw this over at LtU and thought this might interest a few people here: http://code.google.com/p/decac/ And here's a paper describing it in more detail: http://decac.googlecode.com/files/Deca%20Thesis.pdf -- Sebastian Sylvan From graydon at mozilla.com Tue Jan 3 13:21:05 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 03 Jan 2012 13:21:05 -0800 Subject: [rust-dev] Deca, a new language with goals that largely overlap those of Rust In-Reply-To: References: Message-ID: <4F037141.5080303@mozilla.com> On 12-01-03 02:29 AM, Sebastian Sylvan wrote: > Saw this over at LtU and thought this might interest a few people > here: http://code.google.com/p/decac/ > And here's a paper describing it in more detail: > http://decac.googlecode.com/files/Deca%20Thesis.pdf There's some interesting stuff in there, for sure! At a glance, the scoped pointer types, treatment of extensible variants (with class encoding), and multiple-dispatch systems seem worth studying some. It's missing clearly-defined strategies for quite a bit of stuff we've focused on, mind you: - Indefinite-extent allocation (cycles, leaks, etc.: malloc/free only) - Separate compilation (linkage, versioning, etc.: whole program only) - Copy minimization (move semantics, etc.) - Concurrent execution - Failure containment - Syntactic extension - Efficient / safe environment capture - Interop with C But I'll certainly add it to the list of interesting competitors to keep an eye on. Really we ought to have such a list prominently on the website; it's good to keep us honest :) -Graydon From graydon at mozilla.com Tue Jan 3 13:30:05 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 03 Jan 2012 13:30:05 -0800 Subject: [rust-dev] names needed for function types In-Reply-To: <4EFDFC30.7030706@alum.mit.edu> References: <1875284772.18652.1324421443332.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4EFDFC30.7030706@alum.mit.edu> Message-ID: <4F03735D.6010906@mozilla.com> On 11-12-30 10:00 AM, Niko Matsakis wrote: > I like the idea that "fn" is just the type of a general closure (i.e., > "block"). I agree it's what you want most of the time. I think that > there are then three logical choices for boxed/unique closures: > > 1. `fn@` and `fn~`: this is intended to emphasize the fact that the > environment is referenced by a boxed/unique pointer. I don't know how > intuitive it is and it makes heavy use of sigils. Personally this is still my preference by a wide margin. fn is what you'll write almost-all-the-time anyways, so it's not like your program will be overwhelmed with sigils. I find the symmetry between fn@ and @ intuitive here, as with fn~ and ~. The sigil *does* describe the uniqueness / sharedness of the closure here, exactly. Especially since, inside a fn~, you can only capture ~ boxes. If you want to capture @ boxes you have to use a fn at . I agree that the previous issue we had with kinds overloading the @ and ~ sigils turned out to be much more counter-intuitive. Here the intuition you get from the sigil is the correct one. I think. I'd at least like to try it, unless there's a real chorus of dissent. I think it'll work ok. (I notice you don't mention "raw" or "native" functions in this discussion. Any thoughts on them? They're what we reserved 'fn' for last time through this mess.) > 2. `copyfn` or `sendfn`: this emphasizes the kind restrictions. This is > also nice because a `copyfn` is copyable and a `sendfn` is sendable, > whereas a plain `fn` is neither. Don't like #2 here, no. > 3. `fn[copy]` and `fn[send]`: an alternate version of #2 that I find > more visually appealing. Second choice here. They're ... ok, but the collision with capture clauses seems pretty unfortunate. -Graydon From graydon at mozilla.com Wed Jan 4 11:05:50 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Wed, 04 Jan 2012 11:05:50 -0800 Subject: [rust-dev] Documentation Message-ID: <4F04A30E.1030500@mozilla.com> Hi, I started a conversation on IRC which I'd like to make a little more formal here, concerning documentation formats. It's a subtle question because we are generating increasing quantities of information -- and will keep generating more -- and I'd like to bring a degree of systematicity to it if possible. We currently have the following docs: - A wiki on github, written in github-ese markdown - A tutorial written in hand-extended markdown and processed by hand-written javascript - A manual written in texinfo that generates PDF and HTML trees - A man page written by hand in groff - An API documentation tree generated by NaturalDocs, from comments in our library code. - A new 'rustdoc' tool that consumes attribute-docs and emits, for the moment, markdown (though it might emit something else) This is unsatisfying in a few ways: - The output looks inconsistent. - Cross references between pieces of the docs are random, dubious. - There is no central index, TOC; navigation aids are disjoint. - There is no way to acquire a bundle of "all the docs" easily. - Reading formats are inconsistent; some parts can be printed or viewed in a terminal easily, some cannot. - "Building" the docs is arduous and requires almost as many tools as building the rest of the system. So! I would like to come up with a "strategy" (loosely stated) that begins to reduce these sources of dissatisfaction. This is tricky. There are a bunch of technologies-for-docs and they all provide some, but not all, nice things we might want. I'd like to at least start by gathering beliefs about the importance of those things. Specifically, these are my concerns; how important are these concerns to the rest of you? - Generating single-bundle "print-like" documentation artifacts (pdf and epub), including internal-hyperlinks or references when in a non-link rendering ("see page 12"). - Inline-editing of docs in a browser "by everyone", wiki-style. - Viewing in a terminal (man pages, info nodes, plaintext, querying the API docs via a command like "rustdoc -q foo::bar") - Having a very-much-like-plaintext editing format. - Using "the same" format for API docs and hand-written manual, tutorial, rationale, etc. - Having a simple "build" process for the docs that uses as few tools as possible. I've looked at a variety of tools and to my understanding, few-to-none of them do all this. The *closest* I can see is texinfo-and-some-glue-code, but I'm amenable to argument on this. Markdown is a popular contender, but it seems like it's heavily slanted towards HTML output (and possibly wikis). Maybe that's ok? Maybe PDFs and "printed manuals" and such are vestigial nonsense we can consign to history? Opinions welcome, -Graydon From marijnh at gmail.com Wed Jan 4 11:24:19 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Wed, 4 Jan 2012 20:24:19 +0100 Subject: [rust-dev] Documentation In-Reply-To: <4F04A30E.1030500@mozilla.com> References: <4F04A30E.1030500@mozilla.com> Message-ID: I agree with what Matt suggested on IRC -- that non-HTML docs mostly don't matter anymore. Markdown's syntax rules are an abomination, but in practice their poorly thought-out corner cases don't really get in the way much. It has 'won' as far as HTML-near markup languages go, and almost every programmer is fluent in it. > ?- A tutorial written in hand-extended markdown and processed > ? by hand-written javascript The tutorial is actually standard markdown, with the addition of using the definition list extension (which is supported by most parsers), and doing some post-processing on code blocks to syntax-highlight them and to remove some magic directives to make it possible to execute them (thus making it easy to keep it in sync with the actual compiler). This code post-processing is completely orthogonal to the markup format we use -- something like it would have to happen in texinfo as well. (The choice of JS for the rendering script was prompted by the fact that we already have a very good Rust highlighter in JS -- the CodeMirror mode I wrote). Integrating markdown in rustdoc seems like a very good idea. In general, my vote is for more markdown. From giles at thaumas.net Wed Jan 4 11:47:50 2012 From: giles at thaumas.net (Ralph Giles) Date: Wed, 4 Jan 2012 13:47:50 -0600 Subject: [rust-dev] Documentation In-Reply-To: <4F04A30E.1030500@mozilla.com> References: <4F04A30E.1030500@mozilla.com> Message-ID: On 4 January 2012 13:05, Graydon Hoare wrote: > Maybe that's ok? Maybe PDFs and "printed manuals" and such are vestigial > nonsense we can consign to history? As someone who likes PDF, I'd say there aren't any tools which are good at producing both HTML and PDF output. I like PDF because it gives me a single file I can download and refer to later. I don't print them out every often, but it's very nice to have and refer to without needing a network connection (or waiting for round-trip latency whenever I change sections). In our codec work we've had the most success using latex directly. Being able to properly represent equations is a real win there, and our developers tend to be at least somewhat familiar with the format. The drawback is that there are no good latex to HTML tools, and one doesn't get contributions from anyone who hasn't climbed the learning curve. Going the other direction is much easier; if you don't need equations, I'd recommend starting with markdown/texinfo/doxygen, etc. and generating various output formats from that. I'd also remark that documentation is never one-size-fits-all. Extract-and-generate is a nice place to start, and certainly better than nothing, but it doesn't replace a written manpage, for example. It's more important to focus on making the documentation findable and maintainable than to have the source be in any unified format. FWIW, -r From niko at alum.mit.edu Wed Jan 4 14:14:12 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 04 Jan 2012 14:14:12 -0800 Subject: [rust-dev] handy script Message-ID: <4F04CF34.6040009@alum.mit.edu> Hello, I thought some of you might find this script handy. It searches your current working directory to try and find an appropriate rustc to run. This way you can just put this script on your path and type "rustc foo" from within a rust checkout and it will do the right thing. Niko #!/bin/bash # # Script which finds an appropriate rustc to execute based on the current # directory. We begin by walking up the set of directories until we find # one that contains "src/comp/rustc.rc". # Walk up directories looking for the main rust directory. Don't walk # past the home directory of the current user, just seems unsanitary. DIR="$PWD" while [[ "$DIR" != "/" && "$DIR" != "$HOME" ]]; do if [[ -r "$DIR/src/comp/rustc.rc" ]]; then for stage in stage3 stage2 stage1; do # Use glob to search through all architectures. # But if some stage doesn't exist, then # the glob will keep the "*" rather than return the # empty set, so we have to check within the for loop # too. for rustc in "$DIR"/build/*/$stage/bin/rustc; do if [[ -x "$rustc" ]]; then echo Running "$rustc": "$rustc" "$@" exit $? fi done done break fi DIR=$(dirname "$DIR") done # Fallback to /usr/local/bin/rustc, if any: if [[ -x /usr/local/bin/rustc ]]; then echo Running /usr/local/bin/rustc: /usr/local/bin/rustc "$@" exit $? fi echo "ERROR: Could not find an appropriate rustc to execute from dir $PWD!" exit 1 From banderson at mozilla.com Wed Jan 4 15:16:11 2012 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 04 Jan 2012 15:16:11 -0800 (PST) Subject: [rust-dev] minor things that annoy you about Rust? In-Reply-To: <4EF0D10F.9090702@alum.mit.edu> Message-ID: <56042c23-ce70-4934-9a52-3722043d8495@zimbra1.shared.sjc1.mozilla.com> I logged some of the issues brought up here on the issue tracker with the tag 'papercuts', and put some of them on the 0.1 milestone list, though not as release blockers. Hopefully we can resolve some of them. ----- Original Message ----- > From: "Niko Matsakis" > To: rust-dev at mozilla.org > Sent: Tuesday, December 20, 2011 10:16:47 AM > Subject: [rust-dev] minor things that annoy you about Rust? > > Hi, > > In preparation for the 0.1 release, Brian and I were thinking it > might > be nice to try to address small, annoying problems that come up in > everyday Rust programming. Of course, a lot of these are already the > result of compromises over contentious issues (e.g., trailing dot for > nullary tag in a pattern), but I'd still like to know what the set of > annoying things are; some of them may be easier to resolve now. Can > you > please e-mail me your favorite pet peeve(s). Thanks. > > > Niko > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From niko at alum.mit.edu Wed Jan 4 15:49:35 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 04 Jan 2012 15:49:35 -0800 Subject: [rust-dev] names needed for function types In-Reply-To: <4F03735D.6010906@mozilla.com> References: <1875284772.18652.1324421443332.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4EFDFC30.7030706@alum.mit.edu> <4F03735D.6010906@mozilla.com> Message-ID: <4F04E58F.7080408@alum.mit.edu> On 1/3/12 1:30 PM, Graydon Hoare wrote: > [Regarding fn@ and fn~]: > Personally this is still my preference by a wide margin. fn is what > you'll write almost-all-the-time anyways, so it's not like your > program will be overwhelmed with sigils. I find this fairly persuasive. The fact that `@` and `~` also correspond to the kinds of heap pointers that can be captured---as well as the way that the environment is referenced---is a very good point. > (I notice you don't mention "raw" or "native" functions in this > discussion. Any thoughts on them? They're what we reserved 'fn' for > last time through this mess.) Yeah, I've been thinking about it. The original proposal where "fn" was just a function pointer and "fn sigil" indicated a closure has a definite elegance to it, though it seems that in practice it's the wrong default. I guess the main question is when we would need to have raw/native function pointers and what we expect to do with them. At some point Marijn proposed that we just have some way to get a raw function pointer basically as an opaque value (`*void`, essentially). This would be ok for passing to C code but not useful within Rust itself. If we think we'll want to be calling native functions by pointer from within Rust, we could support a type like `native "abi" fn(T) -> U`. It's a bit of mouthful but you do need to know the ABI to call the function. This could also be used for a plain Rust function pointer (`native "rust" fn`). I had also thought something like `fnptr(T)->U` but I'm not sure where to squeeze in the ABI. Niko From dirkjan at ochtman.nl Thu Jan 5 01:39:28 2012 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Thu, 5 Jan 2012 10:39:28 +0100 Subject: [rust-dev] Documentation In-Reply-To: <4F04A30E.1030500@mozilla.com> References: <4F04A30E.1030500@mozilla.com> Message-ID: On Wed, Jan 4, 2012 at 20:05, Graydon Hoare wrote: > ?- Generating single-bundle "print-like" documentation artifacts > ? (pdf and epub), including internal-hyperlinks or references > ? when in a non-link rendering ("see page 12"). > > ?- Inline-editing of docs in a browser "by everyone", wiki-style. > > ?- Viewing in a terminal (man pages, info nodes, plaintext, querying > ? the API docs via a command like "rustdoc -q foo::bar") > > ?- Having a very-much-like-plaintext editing format. > > ?- Using "the same" format for API docs and hand-written manual, > ? tutorial, rationale, etc. > > ?- Having a simple "build" process for the docs that uses as few > ? tools as possible. > > I've looked at a variety of tools and to my understanding, few-to-none of > them do all this. As a lurker, I suggest you look at Sphinx: - It can do both HTML and PDF documentation. - It can generate latex files for further processing. - It can do API docs (though I'm not sure how much work you'd have to do to make it grok Rust). - It uses reST, which makes it easy to write simple things and possible to do complex things. - It has an extremely simple build process, although it depends on Python and Jinja (and possibly Pygments). Cheers, Dirkjan From marijnh at gmail.com Thu Jan 5 06:14:05 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 5 Jan 2012 15:14:05 +0100 Subject: [rust-dev] Interfaces! Message-ID: Interfaces and implementations are mostly working now. They aren't snapshotted yet, and there are some details such as binding methods that don't work yet, but there should be enough implemented to play with. Please file any bugs that you find in this, and assign them to me. A description of the syntax and semantics can be found at https://github.com/graydon/rust/wiki/Interfaces Best, Marijn From banderson at mozilla.com Thu Jan 5 11:03:14 2012 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 05 Jan 2012 11:03:14 -0800 (PST) Subject: [rust-dev] Interfaces! In-Reply-To: Message-ID: Very cool, Marijn. ----- Original Message ----- > From: "Marijn Haverbeke" > To: rust-dev at mozilla.org > Sent: Thursday, January 5, 2012 6:14:05 AM > Subject: [rust-dev] Interfaces! > > Interfaces and implementations are mostly working now. They aren't > snapshotted yet, and there are some details such as binding methods > that don't work yet, but there should be enough implemented to play > with. Please file any bugs that you find in this, and assign them to > me. > > A description of the syntax and semantics can be found at > https://github.com/graydon/rust/wiki/Interfaces > > Best, > Marijn > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From niko at alum.mit.edu Thu Jan 5 11:03:49 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 05 Jan 2012 11:03:49 -0800 Subject: [rust-dev] syntactic sugar for blocks in expressions In-Reply-To: <4EFCD222.1040606@alum.mit.edu> References: <4EFCD222.1040606@alum.mit.edu> Message-ID: <4F05F415.1090904@alum.mit.edu> As discussed, I have pushed the changes which allow block syntactic sugar in expressions. I think the best way to describe the rules is as follows: - In Rust, a statement is either a declaration or an expression followed by a semicolon. The result of evaluating the expression is ignored. - For certain expressions, however, the semicolon may be omitted. In that case, the result type of the expression must be unit. These expressions are (a) C-like special forms that begin with `if`, `while`, `do`, or `alt`; (b) standalone blocks `{...}`; (c) sugared calls with block arguments `expr {|| ...)`. - The value of a block expression `{a; b; c}` is the value of the final expression in the block (`c`, in this case). If a block consists of only statements (e.g., `{a; b;}`) then the value of the block is unit. When phrased this way, I think the rules seem simple enough (but then I would, wouldn't I?). So yes, let's see how it goes: if it seems to trip people up or feels too complex, I'm happy to reverse the changes and give up. Niko From niko at alum.mit.edu Thu Jan 5 11:07:45 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 05 Jan 2012 11:07:45 -0800 Subject: [rust-dev] Interfaces! In-Reply-To: References: Message-ID: <4F05F501.8000808@alum.mit.edu> This looks nice. One question: the syntax used in the docs appears inconsistent to me. If I write "impl foo for bar" does that define an impl named `foo` with no interface, or an impl of the interface `foo`? I believe the former. In that case, I write "impl of foo for bar" to get an impl of the interface `foo` named `foo` for the type `bar`? (or "impl bar_foo of foo for bar" if I want to give the impl a different name). Is that correct? Niko On 1/5/12 6:14 AM, Marijn Haverbeke wrote: > Interfaces and implementations are mostly working now. They aren't > snapshotted yet, and there are some details such as binding methods > that don't work yet, but there should be enough implemented to play > with. Please file any bugs that you find in this, and assign them to > me. > > A description of the syntax and semantics can be found at > https://github.com/graydon/rust/wiki/Interfaces > > Best, > Marijn > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From marijnh at gmail.com Thu Jan 5 11:16:39 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 5 Jan 2012 20:16:39 +0100 Subject: [rust-dev] Interfaces! In-Reply-To: <4F05F501.8000808@alum.mit.edu> References: <4F05F501.8000808@alum.mit.edu> Message-ID: > If I write "impl foo for bar" does that define an impl > named `foo` with no interface, or an impl of the interface `foo`? No interface. >?In that case, I write "impl of foo for bar" to get an impl of > the interface `foo` named `foo` for the type `bar`? Correct. How is this inconsistent? There's an optional `of` clause to specify the interface. As an abbreviation, you can leave off the proper name when you want to use the name of the interface (and you specified one). From niko at alum.mit.edu Thu Jan 5 11:18:35 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 05 Jan 2012 11:18:35 -0800 Subject: [rust-dev] Interfaces! In-Reply-To: References: <4F05F501.8000808@alum.mit.edu> Message-ID: <4F05F78B.6060103@alum.mit.edu> Sorry, the *syntax* is not inconsistent. The *docs* are inconsistent, I believe. The first example says: |// This implements an interface `iter_util` for vector types impl iter_util for [T] { fn len() -> uint { std::vec::len(self) } fn iter(f: block(T)) { for elt in self { f(elt); } } fn map(f: block(T) -> U) -> [U] { let rslt = []; for elt in self { rslt += [f(elt)]; } rslt } }| but this leading comment is incorrect. Niko On 1/5/12 11:16 AM, Marijn Haverbeke wrote: >> If I write "impl foo for bar" does that define an impl >> named `foo` with no interface, or an impl of the interface `foo`? > No interface. > >> In that case, I write "impl of foo for bar" to get an impl of >> the interface `foo` named `foo` for the type `bar`? > Correct. How is this inconsistent? There's an optional `of` clause to > specify the interface. As an abbreviation, you can leave off the > proper name when you want to use the name of the interface (and you > specified one). From niko at alum.mit.edu Thu Jan 5 11:21:02 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 05 Jan 2012 11:21:02 -0800 Subject: [rust-dev] Deca, a new language with goals that largely overlap those of Rust In-Reply-To: References: Message-ID: <4F05F81E.2020807@alum.mit.edu> On 1/3/12 2:29 AM, Sebastian Sylvan wrote: > Saw this over at LtU and thought this might interest a few people > here: http://code.google.com/p/decac/ > And here's a paper describing it in more detail: > http://decac.googlecode.com/files/Deca%20Thesis.pdf I am particularly interested in his algorithm for inference with subtyping: http://arxiv.org/abs/1104.3116 So far though I find the paper quite hard to understand. Anyhow, perhaps it may be of some use to us someday. Niko From marijnh at gmail.com Thu Jan 5 11:21:42 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 5 Jan 2012 20:21:42 +0100 Subject: [rust-dev] Interfaces! In-Reply-To: <4F05F78B.6060103@alum.mit.edu> References: <4F05F501.8000808@alum.mit.edu> <4F05F78B.6060103@alum.mit.edu> Message-ID: > |// This implements an interface `iter_util` for vector types Ah, I see what you mean now. I've updated the wiki page. From graydon at mozilla.com Thu Jan 5 15:30:32 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 05 Jan 2012 15:30:32 -0800 Subject: [rust-dev] Interfaces! In-Reply-To: References: Message-ID: <4F063298.6090001@mozilla.com> On 12-01-05 06:14 AM, Marijn Haverbeke wrote: > Interfaces and implementations are mostly working now. They aren't > snapshotted yet, and there are some details such as binding methods > that don't work yet, but there should be enough implemented to play > with. Please file any bugs that you find in this, and assign them to > me. This is great work. Thanks so much! I'm excited to give them a spin and see how they work :) -Graydon From graydon at mozilla.com Thu Jan 5 15:44:41 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 05 Jan 2012 15:44:41 -0800 Subject: [rust-dev] Assistance with packages Message-ID: <4F0635E9.8070402@mozilla.com> We're approaching a first release (which will be somewhat quiet, but enough to get the "doing releases" ball rolling) and are in need of a little volunteer help, if possible, making packages. In particular, I wonder if anyone has experience making .deb, .rpm, and OSX .dmg packages (or homebrew files, for that matter), and feels like lending a hand here. The curious part of our distribution is of course that we're self-hosting so will require either building bootstrap packages or carrying snapshots or ... something. -Graydon From rust at kudling.de Fri Jan 6 00:06:18 2012 From: rust at kudling.de (Rust) Date: Fri, 6 Jan 2012 09:06:18 +0100 (CET) Subject: [rust-dev] Assistance with packages In-Reply-To: <4F0635E9.8070402@mozilla.com> References: <4F0635E9.8070402@mozilla.com> Message-ID: <389988184.129879.1325837178550.JavaMail.open-xchange@email.1und1.de Maybe we can benefit from looking at D's installers (Linux, OS X, Windows): https://github.com/D-Programming-Language/installer? and ? GHC's OS X installer:?https://github.com/gregorycollins/haskell-platform-osx-installer ? I would not bother too much with a Homebrew formula. Someone in the Homewbrew community will write it ... and it will just install our OS X installer to the Homebrew prefix. ? Graydon Hoare hat am 6. Januar 2012 um 00:44 geschrieben: > We're approaching a first release (which will be somewhat quiet, but > enough to get the "doing releases" ball rolling) and are in need of a > little volunteer help, if possible, making packages. > > In particular, I wonder if anyone has experience making .deb, .rpm, and > OSX .dmg packages (or homebrew files, for that matter), and feels like > lending a hand here. The curious part of our distribution is of course > that we're self-hosting so will require either building bootstrap > packages or carrying snapshots or ... something. > > -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 dteller at mozilla.com Fri Jan 6 00:22:32 2012 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Fri, 06 Jan 2012 09:22:32 +0100 Subject: [rust-dev] Assistance with packages In-Reply-To: <389988184.129879.1325837178550.JavaMail.open-xchange@email.1und1.de> References: <4F0635E9.8070402@mozilla.com> <389988184.129879.1325837178550.JavaMail.open-xchange@email.1und1.de> Message-ID: <4F06AF48.40703@mozilla.com> I can try and contribute with a .dmg. Cheers, David From me at kevincantu.org Fri Jan 6 01:45:56 2012 From: me at kevincantu.org (Kevin Cantu) Date: Fri, 6 Jan 2012 01:45:56 -0800 Subject: [rust-dev] Assistance with packages In-Reply-To: <4F06AF48.40703@mozilla.com> References: <4F0635E9.8070402@mozilla.com> <389988184.129879.1325837178550.JavaMail.open-xchange@email.1und1.de> <4F06AF48.40703@mozilla.com> Message-ID: I've got an .deb file uploaded here, that I've tested on at least one other amd64 Ubuntu system: http://kevincantu.org/archive/rust/install/binary-deb/ I've just winged this one for one architecture's .deb using the checkinstall tool. Those D build scripts, however, are pretty cool. They takes binaries built for different architectures and wraps them up in properly formatted .deb or .rpm files. Tomorrow evening I'll look at that some more. I also want to figure out how to set up an Ubuntu PPA to build and distribute from source... -- Kevin Cantu Santa Barbara, CA On Fri, Jan 6, 2012 at 12:22 AM, David Rajchenbach-Teller wrote: > I can try and contribute with a .dmg. > > Cheers, > ?David > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From dteller at mozilla.com Fri Jan 6 06:55:41 2012 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Fri, 06 Jan 2012 15:55:41 +0100 Subject: [rust-dev] Typestate 2.0 ? In-Reply-To: <4EFB978F.8020608@mozilla.com> References: <1069466229.985379.1324938867926.JavaMail.open-xchange@email.1und1.de> <4EFB978F.8020608@mozilla.com> Message-ID: <4F070B6D.7070808@mozilla.com> If we wish to look at alternative type-checking mechanisms, linear typing might be a good candidate. Some variants of linear typing cover (small) subsets of dependent types (e.g. Camelot), other variants guarantee that garbage-collection is unrequired (e.g. LinearML). I know members of both teams, so if there is interest, I could try and set up a seminar/brownbag. Cheers, David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: OpenPGP digital signature URL: From martine at danga.com Fri Jan 6 17:15:59 2012 From: martine at danga.com (Evan Martin) Date: Fri, 6 Jan 2012 17:15:59 -0800 Subject: [rust-dev] unicode support and core In-Reply-To: <4ef5c892.08992a0a.04a0.ffffa203SMTPIN_ADDED@mx.google.com> References: <4ef5c892.08992a0a.04a0.ffffa203SMTPIN_ADDED@mx.google.com> Message-ID: On Sat, Dec 24, 2011 at 2:03 AM, Rust wrote: > I've opened pull request #1382 to add is_lower/uppercase() to "char". > > I wonder if and how we will be implementing to_lower/uppercase() > > 1) without including libicu in libcore > 2) without replicating libicu functionality In my experience, code that wants something like is_lower falls in one of two categories: 1) code that is implementing some well-defined specification like a lexer for a programming language, where either the ASCII rule will do or they have some complex side requirement (like how the IRC protocol has weird up/down-casing rules for punctuation) 2) code that is attempting to do some sort of human language processing, where the Unicode definition of upper/lower is unlikely to be what you want. For example to properly lowercase a character in the Unicode sense you need to know the source language of the text (as capital I lowercases differently in Turkish than others). Or consider that the return type of to_upper can't be a single char due to upper-casing ?. To elaborate on #2, let me give another example. People often want to break a string on whitespace to extract the words. You might think this leads down the rabbit hole of Unicode definitions of whitespace characters, but in practice once you're worrying about Unicode you need to handle real text properly, including both English rules ("it's" is one word) and French ("L'Acad?mie" is likely two) or even Arabic (where you can't even compute the word break programmatically). The proper thing is not make the \s regex match the Unicode definition of whitespace, but instead to use a Unicode break iterator as defined one of the monster Unicode reports (http://www.unicode.org/reports/tr29/). The worst case is when a library attempts to provide some of Unicode without doing it right. Consider C library's implementation of tolower(), which attempts to helpfully obey your locale which means when SQLite tried to lowercase a query like "INSERT INTO ..." in a Turkish locale, it helpfully corrupted all the capital I's with the Turkish dotless one and then failed to parse the query. >From these sorts of experiences I've concluded the best strategies for these sorts of APIs is to provide two forms: a simple lowercase/uppercase that only works with ASCII but clearly works in that way -- for example, only define it for the 'byte' type (or however you represent non-Unicode characters), and then punt the rest off into a monster library like ICU. From kevin at atkinson.dhs.org Fri Jan 6 22:32:21 2012 From: kevin at atkinson.dhs.org (Kevin Atkinson) Date: Fri, 6 Jan 2012 23:32:21 -0700 (MST) Subject: [rust-dev] unicode support and core In-Reply-To: References: <4ef5c892.08992a0a.04a0.ffffa203SMTPIN_ADDED@mx.google.com> Message-ID: On Fri, 6 Jan 2012, Evan Martin wrote: > On Sat, Dec 24, 2011 at 2:03 AM, Rust wrote: > From these sorts of experiences I've concluded the best strategies for > these sorts of APIs is to provide two forms: a simple > lowercase/uppercase that only works with ASCII but clearly works in > that way -- for example, only define it for the 'byte' type (or > however you represent non-Unicode characters), and then punt the rest > off into a monster library like ICU. Note that UTF-8 is backwards compatible with ASCII. Thus, ASCII-only functions such as tolower are safe to use on a UTF-8 string. From lukes.dylan at gmail.com Sat Jan 7 06:15:07 2012 From: lukes.dylan at gmail.com (Dylan Lukes) Date: Sat, 7 Jan 2012 09:15:07 -0500 Subject: [rust-dev] Assistance With Packages Message-ID: I'd be more than willing to set up a home brew formula. The script can still just pull the snapshots as it does. Shouldn't be too hard :). On Jan 6, 2012 3:00 PM, wrote: > Send Rust-dev mailing list submissions to > rust-dev at mozilla.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/rust-dev > or, via email, send a message with subject or body 'help' to > rust-dev-request at mozilla.org > > You can reach the person managing the list at > rust-dev-owner at mozilla.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rust-dev digest..." > > > Today's Topics: > > 1. Re: Interfaces! (Graydon Hoare) > 2. Assistance with packages (Graydon Hoare) > 3. Re: Assistance with packages (Rust) > 4. Re: Assistance with packages (David Rajchenbach-Teller) > 5. Re: Assistance with packages (Kevin Cantu) > 6. Re: Typestate 2.0 ? (David Rajchenbach-Teller) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 05 Jan 2012 15:30:32 -0800 > From: Graydon Hoare > To: rust-dev at mozilla.org > Subject: Re: [rust-dev] Interfaces! > Message-ID: <4F063298.6090001 at mozilla.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 12-01-05 06:14 AM, Marijn Haverbeke wrote: > > Interfaces and implementations are mostly working now. They aren't > > snapshotted yet, and there are some details such as binding methods > > that don't work yet, but there should be enough implemented to play > > with. Please file any bugs that you find in this, and assign them to > > me. > > This is great work. Thanks so much! I'm excited to give them a spin and > see how they work :) > > -Graydon > > > ------------------------------ > > Message: 2 > Date: Thu, 05 Jan 2012 15:44:41 -0800 > From: Graydon Hoare > To: "rust-dev at mozilla.org" > Subject: [rust-dev] Assistance with packages > Message-ID: <4F0635E9.8070402 at mozilla.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > We're approaching a first release (which will be somewhat quiet, but > enough to get the "doing releases" ball rolling) and are in need of a > little volunteer help, if possible, making packages. > > In particular, I wonder if anyone has experience making .deb, .rpm, and > OSX .dmg packages (or homebrew files, for that matter), and feels like > lending a hand here. The curious part of our distribution is of course > that we're self-hosting so will require either building bootstrap > packages or carrying snapshots or ... something. > > -Graydon > > > ------------------------------ > > Message: 3 > Date: Fri, 6 Jan 2012 09:06:18 +0100 (CET) > From: Rust > To: "rust-dev at mozilla.org" , Graydon Hoare > > Subject: Re: [rust-dev] Assistance with packages > Message-ID: > < > 389988184.129879.1325837178550.JavaMail.open-xchange at email.1und1.de > Content-Type: text/plain; charset="utf-8" > > Maybe we can benefit from looking at D's installers (Linux, OS X, Windows): > https://github.com/D-Programming-Language/installer? > > and > ? > GHC's OS X > installer:? > https://github.com/gregorycollins/haskell-platform-osx-installer > ? > I would not bother too much with a Homebrew formula. > Someone in the Homewbrew community will write it ... and it will just > install > our OS X installer to the Homebrew prefix. > ? > > > Graydon Hoare hat am 6. Januar 2012 um 00:44 > geschrieben: > > > We're approaching a first release (which will be somewhat quiet, but > > enough to get the "doing releases" ball rolling) and are in need of a > > little volunteer help, if possible, making packages. > > > > In particular, I wonder if anyone has experience making .deb, .rpm, and > > OSX .dmg packages (or homebrew files, for that matter), and feels like > > lending a hand here. The curious part of our distribution is of course > > that we're self-hosting so will require either building bootstrap > > packages or carrying snapshots or ... something. > > > > -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: < > http://mail.mozilla.org/pipermail/rust-dev/attachments/20120106/b6afdb29/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Fri, 06 Jan 2012 09:22:32 +0100 > From: David Rajchenbach-Teller > To: Rust > Cc: "rust-dev at mozilla.org" > Subject: Re: [rust-dev] Assistance with packages > Message-ID: <4F06AF48.40703 at mozilla.com> > Content-Type: text/plain; charset=UTF-8 > > I can try and contribute with a .dmg. > > Cheers, > David > > > ------------------------------ > > Message: 5 > Date: Fri, 6 Jan 2012 01:45:56 -0800 > From: Kevin Cantu > To: David Rajchenbach-Teller > Cc: "rust-dev at mozilla.org" > Subject: Re: [rust-dev] Assistance with packages > Message-ID: > > > Content-Type: text/plain; charset=ISO-8859-1 > > I've got an .deb file uploaded here, that I've tested on at least one > other amd64 Ubuntu system: > http://kevincantu.org/archive/rust/install/binary-deb/ > > I've just winged this one for one architecture's .deb using the > checkinstall tool. Those D build scripts, however, are pretty cool. > They takes binaries built for different architectures and wraps them > up in properly formatted .deb or .rpm files. > > Tomorrow evening I'll look at that some more. I also want to figure > out how to set up an Ubuntu PPA to build and distribute from source... > > > -- > Kevin Cantu > Santa Barbara, CA > > > > On Fri, Jan 6, 2012 at 12:22 AM, David Rajchenbach-Teller > wrote: > > I can try and contribute with a .dmg. > > > > Cheers, > > ?David > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > ------------------------------ > > Message: 6 > Date: Fri, 06 Jan 2012 15:55:41 +0100 > From: David Rajchenbach-Teller > To: David Herman > Cc: "rust-dev at mozilla.org" > Subject: Re: [rust-dev] Typestate 2.0 ? > Message-ID: <4F070B6D.7070808 at mozilla.com> > Content-Type: text/plain; charset="utf-8" > > If we wish to look at alternative type-checking mechanisms, linear > typing might be a good candidate. Some variants of linear typing cover > (small) subsets of dependent types (e.g. Camelot), other variants > guarantee that garbage-collection is unrequired (e.g. LinearML). > > I know members of both teams, so if there is interest, I could try and > set up a seminar/brownbag. > > Cheers, > David > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 487 bytes > Desc: OpenPGP digital signature > URL: < > http://mail.mozilla.org/pipermail/rust-dev/attachments/20120106/0dd9b9c2/attachment-0001.bin > > > > ------------------------------ > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > End of Rust-dev Digest, Vol 19, Issue 7 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Sat Jan 7 12:04:53 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Sat, 07 Jan 2012 12:04:53 -0800 Subject: [rust-dev] unicode support and core In-Reply-To: References: <4ef5c892.08992a0a.04a0.ffffa203SMTPIN_ADDED@mx.google.com> Message-ID: <4F08A565.8020408@mozilla.com> On 06/01/2012 5:15 PM, Evan Martin wrote: > From these sorts of experiences I've concluded the best strategies for > these sorts of APIs is to provide two forms: a simple > lowercase/uppercase that only works with ASCII but clearly works in > that way -- for example, only define it for the 'byte' type (or > however you represent non-Unicode characters), and then punt the rest > off into a monster library like ICU. Agreed. This is the strategy we're following, with one additional category: tasks that satisfy all three of these points: - Requiring some >ASCII, unicode logic - Not-requiring any linguistic or locale-related logic - Common-ish in routine 'language ignorant' data-processing tasks These, and only these, are what I'm going to put in libcore manually for char:: stuff. You might think it's an empty set, but there are a small handful of things: - Language-neutral extensions of concepts like "is a metachar' or, in our lexer, 'is an identifier'. This uses XID_Start/XID_Continue. - Normalization forms, NFKC and such. I have a conversion of this logic but it adds another couple hundred kb footprint to libcore, hoping to be able to reduce that. - Suspicious input "sanitization" by general-category whitelist. - Possibly UCA and DUCET (?) I'm not as sure this addresses any real use cases. Really any serious linguistically-aware task beyond this sort requires a linguistically-aware library and we're not in that business. This is the same reason I am mostly-disinterested in the "I need random access to unicode codepoints!" argument about whether to represent strings as utf8 vs. ucs4 in memory. If you think you need random access to unicode codepoints, you're *probably* making an algorithmic mistake. -Graydon From banderson at mozilla.com Sat Jan 7 13:21:01 2012 From: banderson at mozilla.com (Brian Anderson) Date: Sat, 07 Jan 2012 13:21:01 -0800 (PST) Subject: [rust-dev] Assistance With Packages In-Reply-To: Message-ID: <8db912ac-ed16-4225-9c00-9a801e09cc2a@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > From: "Dylan Lukes" > To: rust-dev at mozilla.org > Sent: Saturday, January 7, 2012 6:15:07 AM > Subject: Re: [rust-dev] Assistance With Packages > > > > > I'd be more than willing to set up a home brew formula. The script > can still just pull the snapshots as it does. Shouldn't be too hard > :). The snapshots are not a complete build, just enough to bootstrap. From lukes.dylan at gmail.com Sat Jan 7 13:22:47 2012 From: lukes.dylan at gmail.com (Dylan Lukes) Date: Sat, 7 Jan 2012 16:22:47 -0500 Subject: [rust-dev] Assistance With Packages In-Reply-To: <8db912ac-ed16-4225-9c00-9a801e09cc2a@zimbra1.shared.sjc1.mozilla.com> References: <8db912ac-ed16-4225-9c00-9a801e09cc2a@zimbra1.shared.sjc1.mozilla.com> Message-ID: Ah no I mean, the bootstrapping process as is should be fine for use in homebrew. We can let the bootstrap script pull its stuff in as it has been doing. On Jan 7, 2012 4:21 PM, "Brian Anderson" wrote: > ----- Original Message ----- > > From: "Dylan Lukes" > > To: rust-dev at mozilla.org > > Sent: Saturday, January 7, 2012 6:15:07 AM > > Subject: Re: [rust-dev] Assistance With Packages > > > > > > > > > > I'd be more than willing to set up a home brew formula. The script > > can still just pull the snapshots as it does. Shouldn't be too hard > > :). > > The snapshots are not a complete build, just enough to bootstrap. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at kevincantu.org Sun Jan 8 15:52:30 2012 From: me at kevincantu.org (Kevin Cantu) Date: Sun, 8 Jan 2012 15:52:30 -0800 Subject: [rust-dev] Assistance with packages In-Reply-To: References: <4F0635E9.8070402@mozilla.com> <389988184.129879.1325837178550.JavaMail.open-xchange@email.1und1.de> <4F06AF48.40703@mozilla.com> Message-ID: I now have an Ubuntu PPA set up from source (plus the Linux stage0 binaries) which should work for both i386 and amd64: https://launchpad.net/~kevincantu/+archive/rust/ Those interested in trying it out can add it like so: $ sudo add-apt-repository ppa:kevincantu/rust $ sudo apt-get update $ sudo apt-get install rust At this point, I'm still adjusting a few things and the PPA is on the same revision from Friday, d2218d9c9cb4cbd28e3de44c152f1b270f185e58, but this is a start. -- Kevin Cantu From catamorphism at gmail.com Mon Jan 9 17:36:58 2012 From: catamorphism at gmail.com (Tim Chevalier) Date: Mon, 9 Jan 2012 17:36:58 -0800 Subject: [rust-dev] "Instance Chains: Type Class Programming Without Overlapping Instances" and type classes in Rust Message-ID: Hi, Since I've been hibernating for a while, I'm not really familiar with Rust's type class system, but after discussing it with Graydon a bit, I would be curious to hear (probably from Marijn) about the similarities and differences between it and instance chains as described in this paper by some of my former colleagues: http://web.cecs.pdx.edu/~jgmorris/pubs/morris-icfp2010-instances.pdf The problem the paper addresses is in Haskell, where having multiple instances in scope for the same class and type can cause unpredictable behavior. (The paper explains the basic problem in more detail pretty well.) It seems like there's an analogous issue in Rust when you import multiple sets of methods for the same type class, which I understand is handled with a compile failure. A difference is that with instance chains, an instance is not a "first-class" thing that you can import (like an item in Rust terminology) -- rather, you use type-level if-then expressions to disambiguate which instances apply. >From a research perspective, it would be good to compare/contrast what Rust is doing with the instance chains approach, since I think they're addressing some similar problems. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt ?I cannot hide my anger to spare you guilt, nor hurt feelings, nor answering anger; for to do so insults and trivializes all our efforts. Guilt is not a response to anger; it is a response to one?s own actions or lack of action.? -- Audre Lorde From pwalton at mozilla.com Mon Jan 9 17:53:47 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 09 Jan 2012 17:53:47 -0800 Subject: [rust-dev] "Instance Chains: Type Class Programming Without Overlapping Instances" and type classes in Rust In-Reply-To: References: Message-ID: <4F0B9A2B.30503@mozilla.com> On 1/9/12 5:36 PM, Tim Chevalier wrote: > The problem the paper addresses is in Haskell, where having multiple > instances in scope for the same class and type can cause unpredictable > behavior. (The paper explains the basic problem in more detail pretty > well.) It seems like there's an analogous issue in Rust when you > import multiple sets of methods for the same type class, which I > understand is handled with a compile failure. Our discussion led to the ability to disambiguate at the call site. However, it's not entirely satisfactory: it does mean that there are some subtle traps involving things you would like to be typeclasses (like Hashable) and consistency of data types (like what happens if you create a hash table and add some keys using one type class instance for Hashable and later on try to add keys using another type class instance for it). Patrick From pwalton at mozilla.com Mon Jan 9 18:07:17 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 09 Jan 2012 18:07:17 -0800 Subject: [rust-dev] "Instance Chains: Type Class Programming Without Overlapping Instances" and type classes in Rust In-Reply-To: References: Message-ID: <4F0B9D55.9010807@mozilla.com> On 1/9/12 5:36 PM, Tim Chevalier wrote: > The problem the paper addresses is in Haskell, where having multiple > instances in scope for the same class and type can cause unpredictable > behavior. (The paper explains the basic problem in more detail pretty > well.) It seems like there's an analogous issue in Rust when you > import multiple sets of methods for the same type class, which I > understand is handled with a compile failure. A difference is that > with instance chains, an instance is not a "first-class" thing that > you can import (like an item in Rust terminology) -- rather, you use > type-level if-then expressions to disambiguate which instances apply. Skimming the paper, I don't see where the modularity problem is addressed (e.g. one module defines an instance of Show int, another module defines an instance of Show int, now the two cannot be linked). It only solves the problem in the overlapping case, in which both typeclass instances apply, but one is more specific than the other (e.g. Show [int] and Show ['a]). My initial reaction is that Rust-style named instances are the simpler solution. We make the programmer decide explicitly which implementation to use; we never try to guess. Patrick From grahame at angrygoats.net Tue Jan 10 08:55:56 2012 From: grahame at angrygoats.net (Grahame Bowland) Date: Wed, 11 Jan 2012 00:55:56 +0800 Subject: [rust-dev] CSV implementation Message-ID: Hi everyone I've written a CSV reader in Rust. I thought it might be interesting to some of you to see what a day-3 rust programmer comes up with. The code is here: https://github.com/grahame/rust-csv/ It's quite slow - it takes my machine 0.37 seconds to parse a 200kb CSV file. Oddly if I take the print statements on lines 119:122 out, it takes longer - 0.48 seconds. I'm timing with stdout redirected to /dev/null. I get four warnings like this: csv.rs:46:30: 46:31 warning: inserting an implicit copy for type [char] csv.rs:46 field(x) { ^ I can understand the need for an implicit copy when I pass 'x' to str::from_chars. However, in the 'inquote' alt branch the copy seems to be triggered by the access to 'st.quote'. I don't understand why this causes a copy to happen - could this be a bug? Cheers Grahame -------------- next part -------------- An HTML attachment was scrubbed... URL: From marijnh at gmail.com Tue Jan 10 10:09:03 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Tue, 10 Jan 2012 19:09:03 +0100 Subject: [rust-dev] CSV implementation In-Reply-To: References: Message-ID: > I can understand the need for an implicit copy when I pass 'x' to > str::from_chars. However, in the 'inquote' alt branch the copy seems to be > triggered by the access to 'st.quote'. This has to do with the reference safety checker. As soon as you refer to `st` again the checker can no longer guarantee that the `x` reference, which points at a mutable field of `st`, is still live. If you flip the statements around so that `x` is not used after `st`, the warning (and the copy) will go away. From stefan.plantikow at googlemail.com Tue Jan 10 11:08:33 2012 From: stefan.plantikow at googlemail.com (Stefan Plantikow) Date: Tue, 10 Jan 2012 20:08:33 +0100 Subject: [rust-dev] CSV implementation In-Reply-To: References: Message-ID: Hi, Am Dienstag, 10. Januar 2012 um 17:55 schrieb Grahame Bowland: > I've written a CSV reader in Rust. I thought it might be interesting to some of you to see what a day-3 rust programmer comes up with. The code is here: > https://github.com/grahame/rust-csv/ Kudos and thanks for writing code in rust. > > It's quite slow - it takes my machine 0.37 seconds to parse a 200kb CSV file. Oddly if I take the print statements on lines 119:122 out, it takes longer - 0.48 seconds. I'm timing with stdout redirected to /dev/null. > You probably want to avoid allocating row arrays in the inner loop, instead the user could be required to pass in a sufficiently sized array from the outside. Even if you allocate them in the inner loop, try to allocate them with the right size from the start instead of using "+=" as this may cause a complete copy of the vector. The more deeper issue is that your interface fixes the representation unnecessarily. A possible approach (perhaps using type classes) is to represent a CSV parser as a row iterator of field iterators that allow either getting the field contents as a string or to iterate over its chars. In this way a consumer of the CSV parser retains full control over how input is processed and unnecessary allocation may be avoided. Somewhat related: There is a ticket for overhauling the json parser and there is some weird overlap between lexing and from_str in libcore which may benefit from a unified, fast, basic way to parse simple literals. Greetings, -- Stefan Plantikow From graydon at mozilla.com Tue Jan 10 16:13:53 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 10 Jan 2012 16:13:53 -0800 Subject: [rust-dev] rust repo will be moving on github shortly Message-ID: <4F0CD441.5070504@mozilla.com> Hi, I'm moving the rust repo to the mozilla account on github, away from my personal account. This will probably break a bunch of scripts and inbound links and such. Apologies. Figure it's better to do sooner than later. Please report any breakage you observe. I'll update as much automation as I can asap. -Graydon From graydon at mozilla.com Tue Jan 10 16:19:53 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 10 Jan 2012 16:19:53 -0800 Subject: [rust-dev] rust repo will be moving on github shortly In-Reply-To: <4F0CD441.5070504@mozilla.com> References: <4F0CD441.5070504@mozilla.com> Message-ID: <4F0CD5A9.7080109@mozilla.com> On 12-01-10 04:13 PM, Graydon Hoare wrote: > I'm moving the rust repo to the mozilla account on github, away from my > personal account. This will probably break a bunch of scripts and > inbound links and such. Apologies. Figure it's better to do sooner than > later. The repo has been moved. You'll need to update all your remotes in all your workspaces to point to github.com/mozilla/rust rather than github.com/graydon/rust. Again, please let me know if you see anything else broken (or just fix the links yourself, if you have write access). -Graydon From graydon at mozilla.com Tue Jan 10 16:57:49 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 10 Jan 2012 16:57:49 -0800 Subject: [rust-dev] rust repo will be moving on github shortly In-Reply-To: <4F0CD5A9.7080109@mozilla.com> References: <4F0CD441.5070504@mozilla.com> <4F0CD5A9.7080109@mozilla.com> Message-ID: <4F0CDE8D.80807@mozilla.com> On 12-01-10 04:19 PM, Graydon Hoare wrote: > On 12-01-10 04:13 PM, Graydon Hoare wrote: > >> I'm moving the rust repo to the mozilla account on github, away from my >> personal account. This will probably break a bunch of scripts and >> inbound links and such. Apologies. Figure it's better to do sooner than >> later. > > The repo has been moved. You'll need to update all your remotes in all > your workspaces to point to github.com/mozilla/rust rather than > github.com/graydon/rust. Two followup caveats: - If you were a direct collaborator before (had push/pull and/or admin access to graydon/rust) you may have been dropped. Contact me to remind me. This is not open season on new admins though; I will double-check! - If you forked from graydon/rust, github may still have you as forked from graydon/rust not mozilla/rust. You can redirect this either by manually editing git files or, it seems, it might update automatically next time you do a push to your own origin? In any case, I have a graydon/rust repo like everyone else now (forked from mozilla/rust) so if you happen to mis-file a pull req against me it's not a big deal :) More breakage notices to come if we find any you need to be aware of. -Graydon From as at hacks.yi.org Tue Jan 10 17:26:37 2012 From: as at hacks.yi.org (austin seipp) Date: Tue, 10 Jan 2012 19:26:37 -0600 Subject: [rust-dev] rust repo will be moving on github shortly In-Reply-To: <4F0CDE8D.80807@mozilla.com> References: <4F0CD441.5070504@mozilla.com> <4F0CD5A9.7080109@mozilla.com> <4F0CDE8D.80807@mozilla.com> Message-ID: I'll just go ahead and note that the Wiki sidebar on GitHub is going to need some changing. While all the pages are now in the `mozilla/rust` repository - as you would expect, and can verify by looking at the list of pages - the sidebar still makes references to the `graydon/rust` repository. So that should be fixed The sidebar is a custom bit of markdown that can't be directly edited through the wiki, so I guess you (Graydon) or someone with direct access will need to fix this. After that, all the subsequent wiki links can start being fixed. On Tue, Jan 10, 2012 at 6:57 PM, Graydon Hoare wrote: > On 12-01-10 04:19 PM, Graydon Hoare wrote: >> >> On 12-01-10 04:13 PM, Graydon Hoare wrote: >> >>> I'm moving the rust repo to the mozilla account on github, away from my >>> personal account. This will probably break a bunch of scripts and >>> inbound links and such. Apologies. Figure it's better to do sooner than >>> later. >> >> >> The repo has been moved. You'll need to update all your remotes in all >> your workspaces to point to github.com/mozilla/rust rather than >> github.com/graydon/rust. > > > Two followup caveats: > > ?- If you were a direct collaborator before (had push/pull and/or > ? ?admin access to graydon/rust) you may have been dropped. Contact me > ? ?to remind me. This is not open season on new admins though; I will > ? ?double-check! > > ?- If you forked from graydon/rust, github may still have you as > ? ?forked from graydon/rust not mozilla/rust. You can redirect this > ? ?either by manually editing git files or, it seems, it might update > ? ?automatically next time you do a push to your own origin? > > In any case, I have a graydon/rust repo like everyone else now (forked from > mozilla/rust) so if you happen to mis-file a pull req against me it's not a > big deal :) > > More breakage notices to come if we find any you need to be aware of. > > > -Graydon > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- Regards, Austin From graydon at mozilla.com Tue Jan 10 17:35:30 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 10 Jan 2012 17:35:30 -0800 Subject: [rust-dev] rust repo will be moving on github shortly In-Reply-To: References: <4F0CD441.5070504@mozilla.com> <4F0CD5A9.7080109@mozilla.com> <4F0CDE8D.80807@mozilla.com> Message-ID: <4F0CE762.4050705@mozilla.com> On 12-01-10 05:26 PM, austin seipp wrote: > I'll just go ahead and note that the Wiki sidebar on GitHub is going > to need some changing. While all the pages are now in the > `mozilla/rust` repository - as you would expect, and can verify by > looking at the list of pages - the sidebar still makes references to > the `graydon/rust` repository. So that should be fixed > > The sidebar is a custom bit of markdown that can't be directly edited > through the wiki, so I guess you (Graydon) or someone with direct > access will need to fix this. After that, all the subsequent wiki > links can start being fixed. Fixed, hopefully. (wikis in git, perl -i -pe works, yay) -Graydon From giles at thaumas.net Tue Jan 10 21:39:59 2012 From: giles at thaumas.net (Ralph Giles) Date: Tue, 10 Jan 2012 21:39:59 -0800 Subject: [rust-dev] rust repo will be moving on github shortly In-Reply-To: <4F0CE762.4050705@mozilla.com> References: <4F0CD441.5070504@mozilla.com> <4F0CD5A9.7080109@mozilla.com> <4F0CDE8D.80807@mozilla.com> <4F0CE762.4050705@mozilla.com> Message-ID: On 10 January 2012 17:35, Graydon Hoare wrote: > Fixed, hopefully. There were still a few references to the graydon repo in the wiki. I've attempted to fix them. -r From zackcorr95 at gmail.com Wed Jan 11 18:37:20 2012 From: zackcorr95 at gmail.com (Zack Corr) Date: Thu, 12 Jan 2012 12:37:20 +1000 Subject: [rust-dev] My early endeavours in Rust Message-ID: G'day, Firstly, I absolutely love Rust so far. You're doing great work. Rust programs run fast, almost akin to C speeds. I love the syntax too, it's clear and simplistic. The only dislike (actually more of an annoyance rather than a dislike) I have so far is some of the standard APIs are a bit inconsistent from module to module (eg. some times there's a function such as `create` but other times `mk_x`, sometimes there's `from_str` and sometimes there's just `str`) but I understand that this is really early before release so that is not important at all. I've made a few little things with rust that I thought I would share in-case someone would want them. I've made Cairo bindings for Rust . It's a lightning faster vector graphics library, allowing you to render it into (only PNG at the moment) images, SVG and PDF files (I also added .ttf font loading via FreeType). Due to me wanting to get to know rust, my love for libcairo and rust's close similarity to C, it felt only right to make it. At some point in time I may add a utility into it so that you can render into GUI windows, so you could make a 2d game with it. I'll add this to cargo-central once it comes. I've made Mersenne Twister and linear congruential random number generators for Rust . They were just a test, as I wanted to see how the native (C) ISAAC generator would run against generators written in Rust, and I really wanted a generator that could be seeded by the user (I might be missing something here, there might be a way to do this with the std::rand one already). Of course, the results are just like you would guess running 100 tests: native ISAAC comes out first with around 40.1k nano seconds, LCG second with around 63.9k ns, and MT19937 comes last with 76.2k ns. Note: this is on my pretty terrible laptop, it might be a bit more accurate on others, and it uses a cheap benchmarking method. And finally, I added ipv6 parsing and formatting to the net library. It was just for fun, and it seems to work on all of the addresses I tried. Note: It doesn't format into the substitution format of addresses, because I thought it would be better to keep it formal. Anyway, thanks for the hard work [continuing to make]/[making] Rust, I absolutely love it and I certainly prefer it over the other compiled languages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rust at kudling.de Thu Jan 12 07:30:32 2012 From: rust at kudling.de (Rust) Date: Thu, 12 Jan 2012 16:30:32 +0100 (CET) Subject: [rust-dev] Iterators, lists, vectors Message-ID: <201539446.1742.1326382232447.JavaMail.open-xchange@email.1und1.de Hi, ? i wonder how we will "replicate" Haskell's lazy lists. ? For example: `str::split` splits a string and returns a list/vector of sub-strings. But maybe we don't want to duplicate those sub-strings in memory and we don't want to create such an intermediate list/vector if we just plan to iterate over it.? ? We could add a `str::split_iter` which calls a block instead. But then we'd need to duplicate every function: one returning a list/vector, and the other taking a block. => interface explosion? ? Am i missing something (e.g. that strings are immutable and the list of strings are just "pointers" to the orignal string)? Do we need lazy sequences? Any other idea? ? Bye, Lenny? -------------- next part -------------- An HTML attachment was scrubbed... URL: From graydon at mozilla.com Thu Jan 12 09:47:30 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 12 Jan 2012 09:47:30 -0800 Subject: [rust-dev] Iterators, lists, vectors In-Reply-To: <201539446.1742.1326382232447.JavaMail.open-xchange@email.1und1.de References: <201539446.1742.1326382232447.JavaMail.open-xchange@email.1und1.de Message-ID: <4F0F1CB2.5080008@mozilla.com> On 12/01/2012 7:30 AM, Rust wrote: > i wonder how we will "replicate" Haskell's lazy lists. I'm not in any hurry to do so. They're nice and composable, but they're an efficiency nightmare. > For example: `str::split` splits a string and returns a list/vector of > sub-strings. > > But maybe we don't want to duplicate those sub-strings in memory and we > don't want to create such an intermediate list/vector > > if we just plan to iterate over it. > > We could add a `str::split_iter` which calls a block instead. > > But then we'd need to duplicate every function: one returning a > list/vector, and the other taking a block. > > => interface explosion Maybe for a few of the most-common APIs you get some duplication, yes. More generally though, I think block-centric is best, and perhaps provide a standard vec method that appends-to-a-vec everything fed to it. Then use that (or hand-code a block): vec x = []; hashtbl.keys(bind x.append) // with a helper hashtbl.keys() { |k| x += k; } // manually A lot of our existing APIs aren't block-centric because we wrote them before we had blocks. I mean, the one generalizes to the other pretty easily anyways. Block-centric style is effectively having the programmer manually perform loop fusion or deforestation. I realize "human compiler" tasks like this are distasteful to people who want infinitely smart compilers, but IME a lot of things "smart" compilers advertise, they hit confounding requirements over, and have to de-optimize from their best case. For us, we can be sure that: hashtbl.keys() { |k| k.elts() { |e| if (e > x) { foo(e); } } } will not allocate. That's actually pretty great, and I think we've boiled the syntax down to a level where it's no less readable than the vec-centric style: let ks = hashtbl.keys(); for k in ks { let es = e.elts(); for e in es { if (e > x) { foo(e); } } } This style is actually longer, so ... I'm not terribly put off suggesting APIs follow the former style by preference. > Am i missing something (e.g. that strings are immutable and the list of > strings are just "pointers" to the orignal string)? No. Though we'll be doing some optimizations around constants like that eventually. A dynamically constructed string is certainly not a constant! > Do we need lazy sequences? Please no. > Any other idea? I'm fine with a block-centric style. -Graydon From arcata at gmail.com Thu Jan 12 10:12:33 2012 From: arcata at gmail.com (Joe Groff) Date: Thu, 12 Jan 2012 10:12:33 -0800 Subject: [rust-dev] Iterators, lists, vectors In-Reply-To: <4f0efc9d.29afec0a.4177.ffffedeeSMTPIN_ADDED@mx.google.com> References: <4f0efc9d.29afec0a.4177.ffffedeeSMTPIN_ADDED@mx.google.com> Message-ID: On Thu, Jan 12, 2012 at 7:30 AM, Rust wrote: > For example: `str::split` splits a string and returns a list/vector of > sub-strings. In C++ or D you could have a lazy split with an STL iterator/Phobos range adapter that turns an iterator over objects into an iterator over slices. Now that Rust has typeclasses, could a similar design work? -Joe From niko at alum.mit.edu Thu Jan 12 10:18:17 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 12 Jan 2012 10:18:17 -0800 Subject: [rust-dev] Iterators, lists, vectors In-Reply-To: <4F0F1CB2.5080008@mozilla.com> References: <201539446.1742.1326382232447.JavaMail.open-xchange@email.1und1.de <4F0F1CB2.5080008@mozilla.com> Message-ID: <4F0F23E9.40309@alum.mit.edu> On 1/12/12 9:47 AM, Graydon Hoare wrote: > More generally though, I think block-centric is best, and perhaps > provide a standard vec method that appends-to-a-vec everything fed to it. +1. I was beginning to work on a generic iter module that provided meta-programming features for blocks. One of them would be to_list: type iterfn = block(block(t: T)); fn to_list(iter: iterfn) -> [T] { let result = []; iter {|i| result += [i]; } ret result; } I believe you could then use this like: let keys = to_list(bind hash.keys(_)); or with an appropriate interface/impl pair: let keys = bind hash.keys(_).to_list(); or even: let keys = hash.keys.to_list(); if we implemented the syntax that "hash.keys" where "keys" is a method. Niko From rust at kudling.de Thu Jan 12 12:29:08 2012 From: rust at kudling.de (Rust) Date: Thu, 12 Jan 2012 21:29:08 +0100 (CET) Subject: [rust-dev] Iterators, lists, vectors In-Reply-To: <4F0F23E9.40309@alum.mit.edu> References: <201539446.1742.1326382232447.JavaMail.open-xchange@email.1und1.de <4F0F1CB2.5080008@mozilla.com> <4F0F23E9.40309@alum.mit.edu> Message-ID: <1540526680.26838.1326400149089.JavaMail.open-xchange@email.1und1.de ? Niko Matsakis hat am 12. Januar 2012 um 19:18 geschrieben: > On 1/12/12 9:47 AM, Graydon Hoare wrote: > > More generally though, I think block-centric is best, and perhaps > > provide a standard vec method that appends-to-a-vec everything fed to it. [...] > or even: > >? ? ? let keys = hash.keys.to_list(); ? Actually, this sounds like a good compromise to me. I'm looking forward to this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.fawcett at gmail.com Thu Jan 12 13:10:57 2012 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Thu, 12 Jan 2012 16:10:57 -0500 Subject: [rust-dev] tutorial on interfaces: bounded type parameters Message-ID: Hi folks, The following paragraph appears in the new tutorial on interfaces: The useful thing about value polymorphism is that it does not have to be static. If object-oriented languages only let you call a method on an object when they knew exactly which sub-type it had, that would not get you very far. To be able to call methods on types that aren't known at compile time, it is possible to specify 'bounds' for type parameters. Note the phrase "aren't known at compile time." That reads as if bounded types offer runtime polymorphism. (They don't, do they?) Cheers, Graham From marijnh at gmail.com Thu Jan 12 13:17:51 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 12 Jan 2012 22:17:51 +0100 Subject: [rust-dev] tutorial on interfaces: bounded type parameters In-Reply-To: References: Message-ID: > Note the phrase "aren't known at compile time." That reads as if bounded types > offer runtime polymorphism. (They don't, do they?) They do. From graydon at mozilla.com Thu Jan 12 13:18:11 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 12 Jan 2012 13:18:11 -0800 Subject: [rust-dev] tutorial on interfaces: bounded type parameters In-Reply-To: References: Message-ID: <4F0F4E13.1090603@mozilla.com> On 12/01/2012 1:10 PM, Graham Fawcett wrote: > Note the phrase "aren't known at compile time." That reads as if bounded types > offer runtime polymorphism. (They don't, do they?) They do! :) The very interesting thing about the way interfaces worked out is that they managed to unify a whole pile of concepts at once: - Static overload dispatch (a la C++ non-virtual methods) - Per-type dynamic dispatch (a la typeclasses, caller passes vtbl) - Per-value dynamic dispatch (a la C++ virtual methods, @val has vtbl) - Separate type kinds (compiler provides impl of reserved iface) This broad applicability of the *same* language-UI concept was sort of the winning argument about why they were worth trying. The theory is that much of the time the user doesn't *really* care which of these is happening under the hood, and don't need to: they just want whichever makes sense given what they've written. So it's nice that they can all emerge semi-coherently from the same construct, when used in varying contexts. I've still not given them a serious exploration but I am pretty excited. -Graydon From niko at alum.mit.edu Thu Jan 12 13:56:02 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 12 Jan 2012 13:56:02 -0800 Subject: [rust-dev] My early endeavours in Rust In-Reply-To: References: Message-ID: <4F0F56F2.3090801@alum.mit.edu> This is great to hear. Glad you are enjoying Rust. Maybe we can get your various projects into Cargo, our nascent package manager? Niko On 1/11/12 6:37 PM, Zack Corr wrote: > G'day, > Firstly, I absolutely love Rust so far. You're doing great work. Rust > programs run fast, almost akin to C speeds. I love the syntax too, > it's clear and simplistic. The only dislike (actually more of an > annoyance rather than a dislike) I have so far is some of the standard > APIs are a bit inconsistent from module to module (eg. some times > there's a function such as `create` but other times `mk_x`, sometimes > there's `from_str` and sometimes there's just `str`) but I understand > that this is really early before release so that is not important at > all. I've made a few little things with rust that I thought I would > share in-case someone would want them. > > I've made Cairo bindings for Rust > . It's a lightning faster vector > graphics library, allowing you to render it into (only PNG at the > moment) images, SVG and PDF files (I also added .ttf font loading via > FreeType). Due to me wanting to get to know rust, my love for libcairo > and rust's close similarity to C, it felt only right to make it. At > some point in time I may add a utility into it so that you can render > into GUI windows, so you could make a 2d game with it. I'll add this > to cargo-central once it comes. > > I've made Mersenne Twister and linear congruential random number > generators for Rust . They were > just a test, as I wanted to see how the native (C) ISAAC generator > would run against generators written in Rust, and I really wanted a > generator that could be seeded by the user (I might be missing > something here, there might be a way to do this with the std::rand one > already). Of course, the results are just like you would guess running > 100 tests: native ISAAC comes out first with around 40.1k nano > seconds, LCG second with around 63.9k ns, and MT19937 comes last with > 76.2k ns. Note: this is on my pretty terrible laptop, it might be a > bit more accurate on others, and it uses a cheap benchmarking method. > > And finally, I added ipv6 parsing and formatting to the net library > . It was just for fun, and it seems > to work on all of the addresses I tried. Note: It doesn't format into > the substitution format of addresses, because I thought it would be > better to keep it formal. > > Anyway, thanks for the hard work [continuing to make]/[making] Rust, I > absolutely love it and I certainly prefer it over the other compiled > languages. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From niko at alum.mit.edu Thu Jan 12 13:59:03 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 12 Jan 2012 13:59:03 -0800 Subject: [rust-dev] tutorial on interfaces: bounded type parameters In-Reply-To: References: Message-ID: <4F0F57A7.8060009@alum.mit.edu> On 1/12/12 1:17 PM, Marijn Haverbeke wrote: >> Note the phrase "aren't known at compile time." That reads as if bounded types >> offer runtime polymorphism. (They don't, do they?) > They do. They do and they don't. I think what Graham means is that if I write a function: inter X { ... } fn foo(x: [T]) { ... } The function foo() is compiled without knowledge of what T is, but it can only be applied to one T at a time. In other words, the list is always a list of values of one type (i.e., T). This is polymorphic but in a somewhat more limited sense than a C++ object. However, we also allow values to be *cast* to the interface type, so you can write: fn foo(x: [X]) { ... } and now the function foo() accepts a list whose contents may be of many different types, all of which support the interface X. Niko From banderson at mozilla.com Thu Jan 12 14:26:57 2012 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 12 Jan 2012 14:26:57 -0800 (PST) Subject: [rust-dev] My early endeavours in Rust In-Reply-To: Message-ID: <9b3148de-9779-446e-939c-8bf39543306f@zimbra1.shared.sjc1.mozilla.com> Very cool. Are you going to submit a pull request for the ipv6 parsing? I know you said 'just for fun', but it looks comparable to the ipv4 code already there, so why not? ----- Original Message ----- > From: "Zack Corr" > To: Rust-dev at mozilla.org > Sent: Wednesday, January 11, 2012 6:37:20 PM > Subject: [rust-dev] My early endeavours in Rust > > > > G'day, > Firstly, I absolutely love Rust so far. You're doing great work. Rust > programs run fast, almost akin to C speeds. I love the syntax too, > it's clear and simplistic. The only dislike (actually more of an > annoyance rather than a dislike) I have so far is some of the > standard APIs are a bit inconsistent from module to module (eg. some > times there's a function such as `create` but other times `mk_x`, > sometimes there's `from_str` and sometimes there's just `str`) but I > understand that this is really early before release so that is not > important at all. I've made a few little things with rust that I > thought I would share in-case someone would want them. > > I've made Cairo bindings for Rust . It's a lightning faster vector > graphics library, allowing you to render it into (only PNG at the > moment) images, SVG and PDF files (I also added .ttf font loading > via FreeType). Due to me wanting to get to know rust, my love for > libcairo and rust's close similarity to C, it felt only right to > make it. At some point in time I may add a utility into it so that > you can render into GUI windows, so you could make a 2d game with > it. I'll add this to cargo-central once it comes. > > > I've made Mersenne Twister and linear congruential random number > generators for Rust . They were just a test, as I wanted to see how > the native (C) ISAAC generator would run against generators written > in Rust, and I really wanted a generator that could be seeded by the > user (I might be missing something here, there might be a way to do > this with the std::rand one already). Of course, the results are > just like you would guess running 100 tests: native ISAAC comes out > first with around 40.1k nano seconds, LCG second with around 63.9k > ns, and MT19937 comes last with 76.2k ns. Note: this is on my pretty > terrible laptop, it might be a bit more accurate on others, and it > uses a cheap benchmarking method. > > > And finally, I added ipv6 parsing and formatting to the net library . > It was just for fun, and it seems to work on all of the addresses I > tried. Note: It doesn't format into the substitution format of > addresses, because I thought it would be better to keep it formal. > > > Anyway, thanks for the hard work [continuing to make]/[making] Rust, > I absolutely love it and I certainly prefer it over the other > compiled languages. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From niko at alum.mit.edu Thu Jan 12 14:28:22 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 12 Jan 2012 14:28:22 -0800 Subject: [rust-dev] closure types Message-ID: <4F0F5E86.803@alum.mit.edu> So, based on our recent discussions, I was planning to have `fn(T)->U` be the stack closure type (i.e., block) and `fn@` and `fn~` be the boxed and unique closure types respectively. `native fn` would be a bare function. But this design has never seemed quite right to me: for example, is there an explicit syntax for declaring a stack closure? If so, what is it? `fn() { ... }`? Now I am thinking that it makes more sense for the type `fn(T)->U` to refer to "any kind of closure" (a kind of abstract supertype). Then there are three "concrete" closure types `fn@`, `fn~`, and `fn&`, each of which are subtypes of `fn(T) -> U`. Bare functions are still `native fn(T)->U`. In some way this is more complex (4 types, not 3) but it also feels simpler and cleaner to me. Thoughts? I have the changes needed to implement either scheme waiting to be pushed. I just didn't push them yet because I didn't feel 100% at ease with the original scheme. Also, below is my best effort to adapt the tutorial to this idea, which may or may not be a good explanation. Niko ---- ## Closures Named functions, like those in the previous section, do not close over their environment. Rust also includes support for closures, which are functions that can access variables in the scope in which they are created. There are several forms of closures, each with its own role. The most common type is called a 'stack closure' (written `fn&`), this is a closure which has full access to its environment. fn call_block_with_ten(b: fn&(int)) { b(10); } let x = 20; call_block_with_ten(fn&(arg: int) { #info("x=%d, arg=%d", x, arg); }); This defines a function that accepts a stack closure, and then calls it with a simple closure that executes a log statement, accessing both its argument and the variable `x` from its environment. Because stack closures are actually allocated in the stack frame of the function where they appear, they are very lightweight and efficient. However, they can only be used in a restricted way so as to ensure that they do not survive the scope in which they were created. They are allowed to appear in function argument position and in call position, but nowhere else. Note: there is a [more compact, Ruby-like syntax](#shorthand) for blocks which infers the types of the arguments. See below for details. ### Boxed closures When you need to store a closure in a data structure, a block will not do, since the compiler will refuse to let you store it. For this purpose, Rust provides a type of closure that has an arbitrary lifetime, written `fn@` (boxed closure, analogous to the `@` pointer type described in the next section). A boxed closure does not directly access its environment, but merely copies out the values that it closes over into a private data structure. This means that it can not assign to these variables, and will not 'see' updates to them. This code creates a closure that adds a given string to its argument, returns it from a function, and then calls it: use std; fn mk_appender(suffix: str) -> fn@(str) -> str { let f = fn@(s: str) -> str { s + suffix }; ret f; } fn main() { let shout = mk_appender("!"); std::io::println(shout("hey ho, let's go")); } ### Closure compatibility It often happens that you want to write a function which can accept any kind of closure (e.g., either a stack or a boxed closure). In these cases, you can use the type `fn` without any sigil. Thus, when writing a higher-order function that wants to do nothing with its function argument beyond calling it, you should almost always specify the type of that argument as `fn`, so that callers have the flexibility to pass whatever they want. fn call_twice(f: fn()) { f(); f(); } call_twice(fn&() { "I am a block"; }); call_twice(fn@() { "I am a boxed closure"; }); fn bare_function() { "I am a plain function"; } call_twice(bare_function); `fn()` types are subject to the same restrictions as block types; that is, they may only be passed as parameters or called. ### Unique closures Unique closures, written `fn~` in analogy to the `~` pointer type (see next section), hold on to things that can safely be sent between processes. They copy the values they close over, much like boxed closures, but they also 'own' them?meaning no other code can access them. Unique closures mostly exist for spawning new [tasks](task.html). ### Shorthand syntax Rust provides a compact closure syntax which can be used to represent any kind of closure. The syntax is similar to Ruby or Smalltalk, where the arguments are placed in pipes (`|`). For example, `{|arg1, arg| body}` defines a closure with two arguments. This syntax is intended for use in function calls: the kind of of closure (stack, boxed, unique) and the types of the arguments will be inferred based on what the function expects to receive. As a further simplification, if the final parameter to a function is a closure, the closure need not be placed within parenthesis. You could, for example, write... let doubled = vec::map([1, 2, 3]) {|x| x*2}; `vec::map` is a function in the core library that applies its last argument to every element of a vector, producing a new vector. Even when a closure takes no parameters, you must still write the bars for the parameter list, as in `{|| ...}`. From banderson at mozilla.com Thu Jan 12 15:49:49 2012 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 12 Jan 2012 15:49:49 -0800 (PST) Subject: [rust-dev] closure types In-Reply-To: <4F0F5E86.803@alum.mit.edu> Message-ID: I like your new proposal but feel like the tutorial goes backwards. It should say 'pass a function around with type 'fn'; build functions with {|x| }; oh, but you might also be interested in all these caveats'. ----- Original Message ----- > From: "Niko Matsakis" > To: rust-dev at mozilla.org > Sent: Thursday, January 12, 2012 2:28:22 PM > Subject: [rust-dev] closure types > > So, based on our recent discussions, I was planning to have > `fn(T)->U` > be the stack closure type (i.e., block) and `fn@` and `fn~` be the > boxed > and unique closure types respectively. `native fn` would be a bare > function. But this design has never seemed quite right to me: for > example, is there an explicit syntax for declaring a stack closure? > If > so, what is it? `fn() { ... }`? > > Now I am thinking that it makes more sense for the type `fn(T)->U` to > refer to "any kind of closure" (a kind of abstract supertype). Then > there are three "concrete" closure types `fn@`, `fn~`, and `fn&`, > each > of which are subtypes of `fn(T) -> U`. Bare functions are still > `native > fn(T)->U`. > > In some way this is more complex (4 types, not 3) but it also feels > simpler and cleaner to me. Thoughts? > > I have the changes needed to implement either scheme waiting to be > pushed. I just didn't push them yet because I didn't feel 100% at > ease > with the original scheme. Also, below is my best effort to adapt the > tutorial to this idea, which may or may not be a good explanation. > > > Niko > > ---- > > > ## Closures > > Named functions, like those in the previous section, do not close > over > their environment. Rust also includes support for closures, which are > functions that can access variables in the scope in which they are > created. > > There are several forms of closures, each with its own role. The most > common type is called a 'stack closure' (written `fn&`), this is a > closure which has full access to its environment. > > fn call_block_with_ten(b: fn&(int)) { b(10); } > > let x = 20; > call_block_with_ten(fn&(arg: int) { > #info("x=%d, arg=%d", x, arg); > }); > > This defines a function that accepts a stack closure, and then calls > it with a simple closure that executes a log statement, accessing > both > its argument and the variable `x` from its environment. > > Because stack closures are actually allocated in the stack frame of > the function where they appear, they are very lightweight and > efficient. However, they can only be used in a restricted way so as > to ensure that they do not survive the scope in which they were > created. They are allowed to appear in function argument position and > in call position, but nowhere else. > > Note: there is a [more compact, Ruby-like syntax](#shorthand) for > blocks which infers the types of the arguments. See below for > details. > > ### Boxed closures > > When you need to store a closure in a data structure, a block will > not > do, since the compiler will refuse to let you store it. For this > purpose, Rust provides a type of closure that has an arbitrary > lifetime, written `fn@` (boxed closure, analogous to the `@` pointer > type described in the next section). > > A boxed closure does not directly access its environment, but merely > copies out the values that it closes over into a private data > structure. This means that it can not assign to these variables, and > will not 'see' updates to them. > > This code creates a closure that adds a given string to its argument, > returns it from a function, and then calls it: > > use std; > > fn mk_appender(suffix: str) -> fn@(str) -> str { > let f = fn@(s: str) -> str { s + suffix }; > ret f; > } > > fn main() { > let shout = mk_appender("!"); > std::io::println(shout("hey ho, let's go")); > } > > ### Closure compatibility > > It often happens that you want to write a function which can accept > any kind of closure (e.g., either a stack or a boxed closure). In > these cases, you can use the type `fn` without any sigil. Thus, when > writing a higher-order function that wants to do nothing with its > function argument beyond calling it, you should almost always specify > the type of that argument as `fn`, so that callers have the > flexibility to pass whatever they want. > > fn call_twice(f: fn()) { f(); f(); } > call_twice(fn&() { "I am a block"; }); > call_twice(fn@() { "I am a boxed closure"; }); > fn bare_function() { "I am a plain function"; } > call_twice(bare_function); > > `fn()` types are subject to the same restrictions as block types; > that > is, they may only be passed as parameters or called. > > ### Unique closures > > > > Unique closures, written `fn~` in analogy to the `~` pointer type > (see > next section), hold on to things that can safely be sent between > processes. They copy the values they close over, much like boxed > closures, but they also 'own' them?meaning no other code can access > them. Unique closures mostly exist for spawning new > [tasks](task.html). > > ### Shorthand syntax > > > > Rust provides a compact closure syntax which can be used to represent > any kind of closure. The syntax is similar to Ruby or Smalltalk, > where the arguments are placed in pipes (`|`). For example, `{|arg1, > arg| body}` defines a closure with two arguments. This syntax is > intended for use in function calls: the kind of of closure (stack, > boxed, unique) and the types of the arguments will be inferred based > on what the function expects to receive. > > As a further simplification, if the final parameter to a function is > a > closure, the closure need not be placed within parenthesis. You > could, > for example, write... > > let doubled = vec::map([1, 2, 3]) {|x| x*2}; > > `vec::map` is a function in the core library that applies its last > argument to every element of a vector, producing a new vector. > > Even when a closure takes no parameters, you must still write the > bars > for the parameter list, as in `{|| ...}`. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From banderson at mozilla.com Thu Jan 12 15:52:29 2012 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 12 Jan 2012 15:52:29 -0800 (PST) Subject: [rust-dev] closure types In-Reply-To: Message-ID: <0c2cf9bd-7513-44ad-8dd6-d0c3ca1e3f5b@zimbra1.shared.sjc1.mozilla.com> Maybe the tutorial section on functions should completely gloss over fn~, and save it for the section on tasks. It is just a tutorial, it doesn't have to justify every inch of the language. ----- Original Message ----- > From: "Brian Anderson" > To: "Niko Matsakis" > Cc: rust-dev at mozilla.org > Sent: Thursday, January 12, 2012 3:49:49 PM > Subject: Re: [rust-dev] closure types > > I like your new proposal but feel like the tutorial goes backwards. > It should say 'pass a function around with type 'fn'; build > functions with {|x| }; oh, but you might also be interested in all > these caveats'. > > ----- Original Message ----- > > From: "Niko Matsakis" > > To: rust-dev at mozilla.org > > Sent: Thursday, January 12, 2012 2:28:22 PM > > Subject: [rust-dev] closure types > > > > So, based on our recent discussions, I was planning to have > > `fn(T)->U` > > be the stack closure type (i.e., block) and `fn@` and `fn~` be the > > boxed > > and unique closure types respectively. `native fn` would be a bare > > function. But this design has never seemed quite right to me: for > > example, is there an explicit syntax for declaring a stack closure? > > If > > so, what is it? `fn() { ... }`? > > > > Now I am thinking that it makes more sense for the type `fn(T)->U` > > to > > refer to "any kind of closure" (a kind of abstract supertype). Then > > there are three "concrete" closure types `fn@`, `fn~`, and `fn&`, > > each > > of which are subtypes of `fn(T) -> U`. Bare functions are still > > `native > > fn(T)->U`. > > > > In some way this is more complex (4 types, not 3) but it also feels > > simpler and cleaner to me. Thoughts? > > > > I have the changes needed to implement either scheme waiting to be > > pushed. I just didn't push them yet because I didn't feel 100% at > > ease > > with the original scheme. Also, below is my best effort to adapt > > the > > tutorial to this idea, which may or may not be a good explanation. > > > > > > Niko > > > > ---- > > > > > > ## Closures > > > > Named functions, like those in the previous section, do not close > > over > > their environment. Rust also includes support for closures, which > > are > > functions that can access variables in the scope in which they are > > created. > > > > There are several forms of closures, each with its own role. The > > most > > common type is called a 'stack closure' (written `fn&`), this is a > > closure which has full access to its environment. > > > > fn call_block_with_ten(b: fn&(int)) { b(10); } > > > > let x = 20; > > call_block_with_ten(fn&(arg: int) { > > #info("x=%d, arg=%d", x, arg); > > }); > > > > This defines a function that accepts a stack closure, and then > > calls > > it with a simple closure that executes a log statement, accessing > > both > > its argument and the variable `x` from its environment. > > > > Because stack closures are actually allocated in the stack frame of > > the function where they appear, they are very lightweight and > > efficient. However, they can only be used in a restricted way so as > > to ensure that they do not survive the scope in which they were > > created. They are allowed to appear in function argument position > > and > > in call position, but nowhere else. > > > > Note: there is a [more compact, Ruby-like syntax](#shorthand) for > > blocks which infers the types of the arguments. See below for > > details. > > > > ### Boxed closures > > > > When you need to store a closure in a data structure, a block will > > not > > do, since the compiler will refuse to let you store it. For this > > purpose, Rust provides a type of closure that has an arbitrary > > lifetime, written `fn@` (boxed closure, analogous to the `@` > > pointer > > type described in the next section). > > > > A boxed closure does not directly access its environment, but > > merely > > copies out the values that it closes over into a private data > > structure. This means that it can not assign to these variables, > > and > > will not 'see' updates to them. > > > > This code creates a closure that adds a given string to its > > argument, > > returns it from a function, and then calls it: > > > > use std; > > > > fn mk_appender(suffix: str) -> fn@(str) -> str { > > let f = fn@(s: str) -> str { s + suffix }; > > ret f; > > } > > > > fn main() { > > let shout = mk_appender("!"); > > std::io::println(shout("hey ho, let's go")); > > } > > > > ### Closure compatibility > > > > It often happens that you want to write a function which can accept > > any kind of closure (e.g., either a stack or a boxed closure). In > > these cases, you can use the type `fn` without any sigil. Thus, > > when > > writing a higher-order function that wants to do nothing with its > > function argument beyond calling it, you should almost always > > specify > > the type of that argument as `fn`, so that callers have the > > flexibility to pass whatever they want. > > > > fn call_twice(f: fn()) { f(); f(); } > > call_twice(fn&() { "I am a block"; }); > > call_twice(fn@() { "I am a boxed closure"; }); > > fn bare_function() { "I am a plain function"; } > > call_twice(bare_function); > > > > `fn()` types are subject to the same restrictions as block types; > > that > > is, they may only be passed as parameters or called. > > > > ### Unique closures > > > > > > > > Unique closures, written `fn~` in analogy to the `~` pointer type > > (see > > next section), hold on to things that can safely be sent between > > processes. They copy the values they close over, much like boxed > > closures, but they also 'own' them?meaning no other code can access > > them. Unique closures mostly exist for spawning new > > [tasks](task.html). > > > > ### Shorthand syntax > > > > > > > > Rust provides a compact closure syntax which can be used to > > represent > > any kind of closure. The syntax is similar to Ruby or Smalltalk, > > where the arguments are placed in pipes (`|`). For example, > > `{|arg1, > > arg| body}` defines a closure with two arguments. This syntax is > > intended for use in function calls: the kind of of closure (stack, > > boxed, unique) and the types of the arguments will be inferred > > based > > on what the function expects to receive. > > > > As a further simplification, if the final parameter to a function > > is > > a > > closure, the closure need not be placed within parenthesis. You > > could, > > for example, write... > > > > let doubled = vec::map([1, 2, 3]) {|x| x*2}; > > > > `vec::map` is a function in the core library that applies its last > > argument to every element of a vector, producing a new vector. > > > > Even when a closure takes no parameters, you must still write the > > bars > > for the parameter list, as in `{|| ...}`. > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > From niko at alum.mit.edu Thu Jan 12 16:04:13 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 12 Jan 2012 16:04:13 -0800 Subject: [rust-dev] closure types In-Reply-To: References: Message-ID: <4F0F74FD.8080800@alum.mit.edu> On 1/12/12 3:49 PM, Brian Anderson wrote: > I like your new proposal but feel like the tutorial goes backwards. It should say 'pass a function around with type 'fn'; build functions with {|x| }; oh, but you might also be interested in all these caveats'. Yeah, probably. To be fair that's kind of how Marijn had it and I kind of messed it up. It's the typical computer scientist tendency to build up from the low-level details when you ought to explain by lowering down... Niko From graydon at mozilla.com Thu Jan 12 16:06:22 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 12 Jan 2012 16:06:22 -0800 Subject: [rust-dev] closure types In-Reply-To: <4F0F74FD.8080800@alum.mit.edu> References: <4F0F74FD.8080800@alum.mit.edu> Message-ID: <4F0F757E.9040004@mozilla.com> On 12-01-12 04:04 PM, Niko Matsakis wrote: > Yeah, probably. To be fair that's kind of how Marijn had it and I kind > of messed it up. It's the typical computer scientist tendency to build > up from the low-level details when you ought to explain by lowering down... You want to be working on the "new" reference manual! It starts with the EBNF notation and moves up to octets from there :) (committing trial version of it in a bit) -Graydon From zackcorr95 at gmail.com Thu Jan 12 17:27:27 2012 From: zackcorr95 at gmail.com (Zack Corr) Date: Fri, 13 Jan 2012 11:27:27 +1000 Subject: [rust-dev] My early endeavours in Rust In-Reply-To: <9b3148de-9779-446e-939c-8bf39543306f@zimbra1.shared.sjc1.mozilla.com> References: <9b3148de-9779-446e-939c-8bf39543306f@zimbra1.shared.sjc1.mozilla.com> Message-ID: @Graham: That is really strange. I can only assume that there's some sort of stricter type-casting in the bleeding edge version. Easy to fix, regardless. @Niko: Yes please. I just figured that it wasn't ready because I didn't really find any information on it. @Brian: I thought about it, but I can't do it until tomorrow. My internet is currently broken so I can't actually (correctly) fork Rust without a 40 hour download. Should be fine tomorrow, meanwhile I'll clean it up and make sure it's completely working (and make it format to the substitution format). Zack PS. I apologize if I do anything wrong with the mailing list, this is my first time participating in one. From marijnh at gmail.com Fri Jan 13 03:04:47 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 13 Jan 2012 12:04:47 +0100 Subject: [rust-dev] The obj system is no more Message-ID: So I've always had a difficult relationship with the obj system, or rather its implementation. I couldn't help grinding my teeth every time I ran into a special case for obj values in the trans pass or had to scroll past some long, ugly block of code for the ast::expr_anon_obj case in some code. Now that we have a viable alternative to objs, and no one objected to removing them, I jumped at the chance and converted all uses of objs to some other approach -- and finally, earlier today, removed support for the obj system from the compiler completely. May it rest in peace. From dteller at mozilla.com Fri Jan 13 04:25:28 2012 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Fri, 13 Jan 2012 13:25:28 +0100 Subject: [rust-dev] Student projects/internships Message-ID: <4F1022B8.7070102@mozilla.com> Dear list, As some of you know, I am one of the persons in charge of relationships to Universities. As a big fan of Rust, I would love submitting Rust-related student projects and/or internships. From the top of my heads, I am considering the following topics, and I would like to hear your thoughts about them and the general idea of getting Rust in the hands of students: - writing a modern http server (or an irc server) in Rust; - contributing to some of the "easy" bugs; - getting Rust to produce Android binaries (it doesn't yet, does it?); - developing a web framework for Rust; - adding high-level bindings to a number of system-level libraries (e.g. nss); - ... Any thoughts? Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: OpenPGP digital signature URL: From rust at kudling.de Fri Jan 13 06:25:41 2012 From: rust at kudling.de (Rust) Date: Fri, 13 Jan 2012 15:25:41 +0100 (CET) Subject: [rust-dev] Student projects/internships In-Reply-To: <4F1022B8.7070102@mozilla.com> References: <4F1022B8.7070102@mozilla.com> Message-ID: <53648143.786206.1326464741158.JavaMail.open-xchange@email.1und1.de Hi, ? i think that is a good idea. ? OTOH the core and standard libraries are still in flux: - we will probably switch a significant portion to interfaces and iterators - we should make the naming consistent ? I don't know whether people should write too much code that will break later on. ? Maybe work should be focused on improving the Rust infrastructure at this point in time: - improve RustDoc to replace NaturalDocs? - core/std library cleanups and additions: https://github.com/mozilla/rust/wiki/Note-wanted-libraries - bug fixing ? Bye, Lenny? ? David Rajchenbach-Teller hat am 13. Januar 2012 um 13:25 geschrieben: >? ? ? ? ?Dear list, > >? As some of you know, I am one of the persons in charge of relationships > to Universities. As a big fan of Rust, I would love submitting > Rust-related student projects and/or internships. > > From the top of my heads, I am considering the following topics, and I > would like to hear your thoughts about them and the general idea of > getting Rust in the hands of students: > - writing a modern http server (or an irc server) in Rust; > - contributing to some of the "easy" bugs; > - getting Rust to produce Android binaries (it doesn't yet, does it?); > - developing a web framework for Rust; > - adding high-level bindings to a number of system-level libraries (e.g. > nss); > - ... > > Any thoughts? > > Cheers, >? David > > -- > David Rajchenbach-Teller, PhD >? Performance Team, Mozilla > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruant.d at gmail.com Fri Jan 13 07:11:24 2012 From: bruant.d at gmail.com (David Bruant) Date: Fri, 13 Jan 2012 16:11:24 +0100 Subject: [rust-dev] Student projects/internships In-Reply-To: <4f103eeb.29afec0a.634e.ffffae67SMTPIN_ADDED@mx.google.com> References: <4F1022B8.7070102@mozilla.com> <4f103eeb.29afec0a.634e.ffffae67SMTPIN_ADDED@mx.google.com> Message-ID: <4F10499C.7040808@gmail.com> Hi, I recently dove into Rust to understand what it was, and what it was for. I am under the impression that the Rust syntax is now quite stable (stable enough to write a Rust compiler in Rust). If it's the case, what about a C-to-Rust or C++-to-Rust compiler? It would enable to leverage some existing code. The Rust All Hands Winter 2011 presentation [1] say that some components are planned to be written (slide 39). Such components (parallel aspect aside) already exist in Gecko in C++. Having a (partial) automation of the C++ to Rust transition would probably be beneficial. Of course, very much like projects like Emscripten (C/C++-to-JavaScript compiler), there is a need to rework the generated code, but at least a good share of the transition is already done. It could also be an occasion to see how the Rust compiler perform with generated code, with code written with other style than the current contributors, etc. David [1] http://www.slideshare.net/pcwalton/rust-all-hands-winter-2011 Le 13/01/2012 15:25, Rust a ?crit : > > Hi, > > i think that is a good idea. > > OTOH the core and standard libraries are still in flux: > > - we will probably switch a significant portion to interfaces and > iterators > > - we should make the naming consistent > > I don't know whether people should write too much code that will break > later on. > > Maybe work should be focused on improving the Rust infrastructure at > this point in time: > > - improve RustDoc to replace NaturalDocs > > - core/std library cleanups and additions: > https://github.com/mozilla/rust/wiki/Note-wanted-libraries > > - bug fixing > > Bye, > > Lenny > > > David Rajchenbach-Teller hat am 13. Januar 2012 > um 13:25 geschrieben: > > > Dear list, > > > > As some of you know, I am one of the persons in charge of > relationships > > to Universities. As a big fan of Rust, I would love submitting > > Rust-related student projects and/or internships. > > > > From the top of my heads, I am considering the following topics, and I > > would like to hear your thoughts about them and the general idea of > > getting Rust in the hands of students: > > - writing a modern http server (or an irc server) in Rust; > > - contributing to some of the "easy" bugs; > > - getting Rust to produce Android binaries (it doesn't yet, does it?); > > - developing a web framework for Rust; > > - adding high-level bindings to a number of system-level libraries > (e.g. > > nss); > > - ... > > > > Any thoughts? > > > > Cheers, > > David > > > > -- > > David Rajchenbach-Teller, PhD > > Performance Team, Mozilla > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From dteller at mozilla.com Fri Jan 13 07:33:19 2012 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Fri, 13 Jan 2012 16:33:19 +0100 Subject: [rust-dev] Student projects/internships In-Reply-To: <4F10499C.7040808@gmail.com> References: <4F1022B8.7070102@mozilla.com> <4f103eeb.29afec0a.634e.ffffae67SMTPIN_ADDED@mx.google.com> <4F10499C.7040808@gmail.com> Message-ID: <4F104EBF.8010403@mozilla.com> On Fri Jan 13 16:11:24 2012, David Bruant wrote: > Hi, > > I recently dove into Rust to understand what it was, and what it was for. > I am under the impression that the Rust syntax is now quite stable > (stable enough to write a Rust compiler in Rust). > > If it's the case, what about a C-to-Rust or C++-to-Rust compiler? > It would enable to leverage some existing code. > The Rust All Hands Winter 2011 presentation [1] say that some > components are planned to be written (slide 39). Such components > (parallel aspect aside) already exist in Gecko in C++. Having a > (partial) automation of the C++ to Rust transition would probably be > beneficial. > > Of course, very much like projects like Emscripten > (C/C++-to-JavaScript compiler), there is a need to rework the > generated code, but at least a good share of the transition is already > done. > It could also be an occasion to see how the Rust compiler perform with > generated code, with code written with other style than the current > contributors, etc. > > David > > [1] http://www.slideshare.net/pcwalton/rust-all-hands-winter-2011 I am extremely wary of source-to-source translators, as in my experience, they tend to generate code that is unreadable, unreadable error messages, and itself produces silent errors. On the other hand, writing, say, a concurrent HTML5 parser might be a nice way to demonstrate the power of Rust. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla From bruant.d at gmail.com Fri Jan 13 07:50:59 2012 From: bruant.d at gmail.com (David Bruant) Date: Fri, 13 Jan 2012 16:50:59 +0100 Subject: [rust-dev] Student projects/internships In-Reply-To: <4F104EBF.8010403@mozilla.com> References: <4F1022B8.7070102@mozilla.com> <4f103eeb.29afec0a.634e.ffffae67SMTPIN_ADDED@mx.google.com> <4F10499C.7040808@gmail.com> <4F104EBF.8010403@mozilla.com> Message-ID: <4F1052E3.7050005@gmail.com> Le 13/01/2012 16:33, David Rajchenbach-Teller a ?crit : > I am extremely wary of source-to-source translators, as in my > experience, they tend to generate code that is unreadable, unreadable > error messages, and itself produces silent errors. I share your concern, but do they tend to do this because of the nature of the exercise or because of how it's done? If it's inherent to the nature of the exercise (which is not an obvious statement), the idea is to thrown away. If it's because of how it's done, then, the project just needs feedback from people like you who have been disappointed by previous experiences. > On the other hand, writing, say, a concurrent HTML5 parser might be a > nice way to demonstrate the power of Rust. I agree it would be a nice way to demontrate the power of Rust. But I was thinking about the bigger picture. The Rust All Hands Winter 2011 presentation slide 37 [3] shows a very ambitious project. I'm sure we agree that re-doing all this work from scratch while there already exists a C++ browser would be an error [1] [2]. Consequently, a C++-to-Rust compiler seems to be a necessity to achieve the goal in slide 37, doesn't it? If it can be of any influence, an HTML5 event-based parser written in JavaScript can be found at: https://github.com/aredridel/html5 David [1] http://www.slideshare.net/BrendanEich/msr-talk-7782102 slide 23 [2] http://www.joelonsoftware.com/articles/fog0000000069.html [3] http://www.slideshare.net/pcwalton/rust-all-hands-winter-2011 From mbrubeck at mozilla.com Fri Jan 13 08:04:25 2012 From: mbrubeck at mozilla.com (mbrubeck) Date: Fri, 13 Jan 2012 08:04:25 -0800 Subject: [rust-dev] Student projects/internships In-Reply-To: <4F10499C.7040808@gmail.com> References: <4F1022B8.7070102@mozilla.com> <4f103eeb.29afec0a.634e.ffffae67SMTPIN_ADDED@mx.google.com> <4F10499C.7040808@gmail.com> Message-ID: <4F105609.6060505@mozilla.com> On 01/13/2012 07:11 AM, David Bruant wrote: > If it's the case, what about a C-to-Rust or C++-to-Rust compiler? > It would enable to leverage some existing code. > The Rust All Hands Winter 2011 presentation [1] say that some > components are planned to be written (slide 39). Such components > (parallel aspect aside) already exist in Gecko in C++. Having a > (partial) automation of the C++ to Rust transition would probably be > beneficial. Unlike JavaScript code, Rust code can link directly to C/C++ libraries (and vice-versa). So you can already build programs that include both Rust and C++ code, without the performance hit of a source-to-source compiler. There's no need to translate existing code into Rust to leverage it; just use it directly, or write a small wrapper library. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruant.d at gmail.com Fri Jan 13 10:39:04 2012 From: bruant.d at gmail.com (David Bruant) Date: Fri, 13 Jan 2012 19:39:04 +0100 Subject: [rust-dev] Student projects/internships In-Reply-To: <4F105609.6060505@mozilla.com> References: <4F1022B8.7070102@mozilla.com> <4f103eeb.29afec0a.634e.ffffae67SMTPIN_ADDED@mx.google.com> <4F10499C.7040808@gmail.com> <4F105609.6060505@mozilla.com> Message-ID: <4F107A48.5030904@gmail.com> Le 13/01/2012 17:04, mbrubeck a ?crit : > On 01/13/2012 07:11 AM, David Bruant wrote: >> If it's the case, what about a C-to-Rust or C++-to-Rust compiler? >> It would enable to leverage some existing code. >> The Rust All Hands Winter 2011 presentation [1] say that some >> components are planned to be written (slide 39). Such components >> (parallel aspect aside) already exist in Gecko in C++. Having a >> (partial) automation of the C++ to Rust transition would probably be >> beneficial. Recontextualising (other quote by me in this thread): > The Rust All Hands Winter 2011 presentation slide 37 [3] shows a very > ambitious project. I'm sure we agree that re-doing all this work from > scratch while there already exists a C++ browser would be an error [1] > [2]. > Consequently, a C++-to-Rust compiler seems to be a necessity to > achieve the goal in slide 37, doesn't it? > > [1] http://www.slideshare.net/BrendanEich/msr-talk-7782102 slide 23 > [2] http://www.joelonsoftware.com/articles/fog0000000069.html > [3] http://www.slideshare.net/pcwalton/rust-all-hands-winter-2011 Le 13/01/2012 17:04, mbrubeck a ?crit : > Unlike JavaScript code, Rust code can link directly to C/C++ libraries > (and vice-versa). So you can already build programs that include both > Rust and C++ code, without the performance hit of a source-to-source > compiler. Just to be sure I'm not misinterpreted, I'm not pretending that a source-to-source compiler would be a final solution. The generated Rust would need to be probably tweaked a bit to be production ready, both for "serial performance" and also to make the program parallel if possible and if easy enough based on the generated code. I would consider a C++-to-Rust compiler only as an assistance tool, just something that helps in the process, not a button you need to push once and you're good to go. > There's no need to translate existing code into Rust to leverage it; > just use it directly, or write a small wrapper library. It is my understanding that Rust is being designed also for the purpose of being safer than C/C++ [4]. Tell me if I'm wrong, but if a component is used as a library, it doesn't make it safer, yet, with privilege escalation, it makes the program that uses it as a library potentially vulnerable. I agree that for purely the purpose of leveraging code, it is not necessary to compile C++ to Rust, but to leverage code _and_ add the safety (and maybe other properties, like easily make the program running in a concurrent fashion), then compiling to Rust would be of a tremendous help. David [4] http://www.slideshare.net/BrendanEich/future-tense-7782010 slides 14 to 20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Fri Jan 13 10:54:21 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 13 Jan 2012 10:54:21 -0800 Subject: [rust-dev] Student projects/internships In-Reply-To: <4F107A48.5030904@gmail.com> References: <4F1022B8.7070102@mozilla.com> <4f103eeb.29afec0a.634e.ffffae67SMTPIN_ADDED@mx.google.com> <4F10499C.7040808@gmail.com> <4F105609.6060505@mozilla.com> <4F107A48.5030904@gmail.com> Message-ID: <4F107DDD.5030903@mozilla.com> On 1/13/12 10:39 AM, David Bruant wrote: > It is my understanding that Rust is being designed also for the purpose > of being safer than C/C++ [4]. Tell me if I'm wrong, but if a component > is used as a library, it doesn't make it safer, yet, with privilege > escalation, it makes the program that uses it as a library potentially > vulnerable. In order to actually take advantage of the safety features of Rust, such a compiler would have to convert code written in a memory-unsafe programming language to memory-safe code. Essentially, it would have prove through some combination of static and dynamic checks that the C/C++ code is memory-safe before translating it into the safe dialect of Rust. But there's a problem with this -- once you've proved that some C/C++ code is memory safe, you won't gain much by translating it into Rust. In particular, you've already proved all the static safety properties on your own that Rust's type system enforces. You had to have done so, or else the Rust code you generated wouldn't compile. You might benefit from the dynamic safety properties, most notably (a) stack growth checks and (b) array bounds checks. But both of these have simpler solutions available. Stack growth checks are an LLVM feature, not a Rust feature: you can get them in C/C++ by simply using clang and enabling segmented stacks at the LLVM level. (You will have to provide an implementation of __morestack, but this is several orders of magnitude less effort than writing a C++-to-Rust compiler.) And array bounds checks can be achieved by simply using and std::vector::at(). If your goal is to get runtime array bounds checking, a static analysis tool for C/C++ to enforce consistent use of the STL and the safe accessors like std::vector::at() would be far easier. Patrick From lindsey at rockstargirl.org Fri Jan 13 10:55:21 2012 From: lindsey at rockstargirl.org (Lindsey Kuper) Date: Fri, 13 Jan 2012 13:55:21 -0500 Subject: [rust-dev] Student projects/internships In-Reply-To: <4F1022B8.7070102@mozilla.com> References: <4F1022B8.7070102@mozilla.com> Message-ID: On Fri, Jan 13, 2012 at 7:25 AM, David Rajchenbach-Teller wrote: > ? ? ? ?Dear list, > > ?As some of you know, I am one of the persons in charge of relationships > to Universities. As a big fan of Rust, I would love submitting > Rust-related student projects and/or internships. > > From the top of my heads, I am considering the following topics, and I > would like to hear your thoughts about them and the general idea of > getting Rust in the hands of students: > - writing a modern http server (or an irc server) in Rust; > - contributing to some of the "easy" bugs; > - getting Rust to produce Android binaries (it doesn't yet, does it?); > - developing a web framework for Rust; > - adding high-level bindings to a number of system-level libraries (e.g. > nss); > - ... > > Any thoughts? Hi David, Regarding intern projects, I hope you don't neglect the possibility of letting interns work on the Rust compiler itself, in addition to stuff like HTTP servers and web frameworks. At least for me, getting to work *on* Rust as well as *in* Rust is one of the things that made the intern experience particularly rewarding; I think the rest of last summer's interns would probably agree. Lindsey From banderson at mozilla.com Fri Jan 13 11:03:01 2012 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 13 Jan 2012 11:03:01 -0800 (PST) Subject: [rust-dev] Student projects/internships In-Reply-To: <4F1022B8.7070102@mozilla.com> Message-ID: <881d64ec-296c-45de-8a02-9a07b2fd04d5@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > From: "David Rajchenbach-Teller" > To: rust-dev at mozilla.org > Sent: Friday, January 13, 2012 4:25:28 AM > Subject: [rust-dev] Student projects/internships > > Dear list, > > As some of you know, I am one of the persons in charge of > relationships > to Universities. As a big fan of Rust, I would love submitting > Rust-related student projects and/or internships. > > From the top of my heads, I am considering the following topics, and > I > would like to hear your thoughts about them and the general idea of > getting Rust in the hands of students: > - writing a modern http server (or an irc server) in Rust; I would like a node.js clone using Rust+SpiderMonkey. This will require libuv bindings in std, which on its own is a sizable project. > - contributing to some of the "easy" bugs; > - getting Rust to produce Android binaries (it doesn't yet, does > it?); It doesn't. This is a good project. > - developing a web framework for Rust; > - adding high-level bindings to a number of system-level libraries > (e.g. > nss); > - ... > > Any thoughts? > * An actor library comparable to Scala or Akka. * A DBMS interface with bindings for at least 2 DBs. From graydon at mozilla.com Fri Jan 13 10:57:20 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Fri, 13 Jan 2012 10:57:20 -0800 Subject: [rust-dev] Student projects/internships In-Reply-To: <53648143.786206.1326464741158.JavaMail.open-xchange@email.1und1.de References: <4F1022B8.7070102@mozilla.com> <53648143.786206.1326464741158.JavaMail.open-xchange@email.1und1.de Message-ID: <4F107E90.30603@mozilla.com> On 12-01-13 06:25 AM, Rust wrote: > Hi, > > i think that is a good idea. > > OTOH the core and standard libraries are still in flux: > > - we will probably switch a significant portion to interfaces and iterators > > - we should make the naming consistent Yes. This should probably get a lot more focus after this release; it's important to stabilize conventions and names soon. Also to keep growing the infrastructure around cargo, so we don't risk developing >1 package ecosystem. > Maybe work should be focused on improving the Rust infrastructure at > this point in time: > > - improve RustDoc to replace NaturalDocs > > - core/std library cleanups and additions: > https://github.com/mozilla/rust/wiki/Note-wanted-libraries > > - bug fixing I agree these things are important; they're certainly in my sights as high priority for the next few releases, as they've risen to the point of being the "most obvious stumbling blocks" for new users. You can write in the language now -- which is *so satisfying* to be able to finally say! -- but the libraries need a lot of work. I'm not sure how much a student would want to do them! We have paid employees partly because, well, some of the work is unglamorous. Student work is also supposed to be a bit educational :) -Graydon From graydon at mozilla.com Fri Jan 13 11:17:08 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Fri, 13 Jan 2012 11:17:08 -0800 Subject: [rust-dev] Student projects/internships In-Reply-To: <4F1022B8.7070102@mozilla.com> References: <4F1022B8.7070102@mozilla.com> Message-ID: <4F108334.4070807@mozilla.com> On 12-01-13 04:25 AM, David Rajchenbach-Teller wrote: > Dear list, > > As some of you know, I am one of the persons in charge of relationships > to Universities. As a big fan of Rust, I would love submitting > Rust-related student projects and/or internships. > > From the top of my heads, I am considering the following topics, and I > would like to hear your thoughts about them and the general idea of > getting Rust in the hands of students: > - writing a modern http server (or an irc server) in Rust; > - contributing to some of the "easy" bugs; > - getting Rust to produce Android binaries (it doesn't yet, does it?); > - developing a web framework for Rust; > - adding high-level bindings to a number of system-level libraries (e.g. > nss); > - ... > > Any thoughts? It'd help to know which time-period you're talking about; we'll be at different maturity-levels now vs. 3, 6, 9, 12 months from now. Writing servers, library bindings, frameworks for well-understood tasks etc. is ... definitely work-that-needs-doing, I'd question exactly how much value a student will get out of it. If we're considering students as "needing practice and experience" or "inexpensive labour", then those are, I guess, good tasks; if we're considering them as people we want to challenge with something strange and difficult, we might want to go a bit deeper. Thinking a bit more along the lines of "strange and difficult": - An android-targeting port would be a challenge for someone who likes the "lower" systems-level stuff: there's asm code involved, and some spooky platform-interface stuff. Could be fun. - I'd like the compiler to grow a bunch more syntax extensions and pragma-like attributes. These systems are still pretty immature; they "work" but they're hard-wired into the compiler. So I'd be very interested in having students work on making the attribute and syntax-extension systems work via libraries themselves, and implementing a number of additional extensions. I have a long list in mind and each of them is somewhat bite-sized but involves some interesting compiler-hacking. - Of particular near-term interest is the stuff erickt is doing interfacing with clang. Being able to use clang to consume C/C++ "in the raw" opens up a lot of tooling possibilities. - I had high-ish hopes for the language being relatively reflective, a lot of these have been deferred or thrown out during the course of our development. I'd like to revive some of them. The API for parsing and inspecting rust ASTs is of course exposed via librustc, but programs can't in general reflect much on themselves nor the type-descriptors that drive some of the polymorphic system, and the post-parse data structures (results of resolution, type and type-state analysis) are mostly hidden or inaccessible; certainly thrown out after compilation. We're also missing quasiquoting, which should probably have been one of the *first* syntax extensions. -Graydon From bruant.d at gmail.com Fri Jan 13 11:35:05 2012 From: bruant.d at gmail.com (David Bruant) Date: Fri, 13 Jan 2012 20:35:05 +0100 Subject: [rust-dev] Student projects/internships In-Reply-To: <4F107DDD.5030903@mozilla.com> References: <4F1022B8.7070102@mozilla.com> <4f103eeb.29afec0a.634e.ffffae67SMTPIN_ADDED@mx.google.com> <4F10499C.7040808@gmail.com> <4F105609.6060505@mozilla.com> <4F107A48.5030904@gmail.com> <4F107DDD.5030903@mozilla.com> Message-ID: <4F108769.1090404@gmail.com> Le 13/01/2012 19:54, Patrick Walton a ?crit : > On 1/13/12 10:39 AM, David Bruant wrote: >> It is my understanding that Rust is being designed also for the purpose >> of being safer than C/C++ [4]. Tell me if I'm wrong, but if a component >> is used as a library, it doesn't make it safer, yet, with privilege >> escalation, it makes the program that uses it as a library potentially >> vulnerable. > > In order to actually take advantage of the safety features of Rust, > such a compiler would have to convert code written in a memory-unsafe > programming language to memory-safe code. I'm not a specialist of the question, but I would guess that it is undecidable. I don't see this as a problem, though. Once again, I didn't suggest a magic tool that will solve all problems. A source-to-source compiler cannot do a perfect 1-to-1 mapping anyway. Such a tool would make mistakes. Such a tool would "find" open questions that it would be preferable a human being answer to. And that's fine. I wasn't suggesting to do a tool that solves all problems, but rather an assistant; sorry if the word "compiler" resonated as something that ambitious, that's not what I meant. > Essentially, it would have prove through some combination of static > and dynamic checks that the C/C++ code is memory-safe before > translating it into the safe dialect of Rust. It could translate into the unsafe subset (or partially to the safe subset for parts that are easy to prove if such cases exist) and a human being could take it from here and get to the safe subset. It sounds much less work than a human being having to write from scratch in Rust (if the need is to translate a lot of long programs, of course). > But there's a problem with this -- once you've proved that some C/C++ > code is memory safe, you won't gain much by translating it into Rust. > In particular, you've already proved all the static safety properties > on your own that Rust's type system enforces. You had to have done so, > or else the Rust code you generated wouldn't compile. Is it true also for the unsafe subset? If so, then my idea is pointless. If not, then, it probably means you can "easily" have a compilable unsafe Rust from C/C++ which is a good start. If a human being brings the unsafe compiled Rust to the safe subset, then, all the benefits of Rust (static and dynamic ones) will be there without additional tooling when it comes to maintaining and evolving the code, since the Rust compiling phase will help during maintenance and evolution of the code that will be already in Rust. All these benefits will be harder to achieve in code maintained in C/C++. > You might benefit from the dynamic safety properties, most notably (a) > stack growth checks and (b) array bounds checks. But both of these > have simpler solutions available. Stack growth checks are an LLVM > feature, not a Rust feature: you can get them in C/C++ by simply using > clang and enabling segmented stacks at the LLVM level. (You will have > to provide an implementation of __morestack, but this is several > orders of magnitude less effort than writing a C++-to-Rust compiler.) > And array bounds checks can be achieved by simply using and > std::vector::at(). If your goal is to get runtime array bounds > checking, a static analysis tool for C/C++ to enforce consistent use > of the STL and the safe accessors like std::vector::at() would be far > easier. Is this already in use to analyze Firefox (or equivalent software which would be as big and in C/C++) in continuous integration? If not, then it's worth doing the compiler just to have all the benefits while maintaining/evolving the software. If the goal is to benefit once from some static/dynamic properties, then, as you note, additional tools may be easier to set up. If the goal is to benefit of all the goodness during the software developement phase (when is Firefox development planned to be finished, btw? ;-) ), then, it may be worth doing a one-time translation assisted with a tool that could do 70/80% (guesstimate) of the work. David From pwalton at mozilla.com Fri Jan 13 11:38:56 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 13 Jan 2012 11:38:56 -0800 Subject: [rust-dev] Student projects/internships In-Reply-To: <4F1022B8.7070102@mozilla.com> References: <4F1022B8.7070102@mozilla.com> Message-ID: <4F108850.2020908@mozilla.com> On 1/13/12 4:25 AM, David Rajchenbach-Teller wrote: > Dear list, > > As some of you know, I am one of the persons in charge of relationships > to Universities. As a big fan of Rust, I would love submitting > Rust-related student projects and/or internships. > > From the top of my heads, I am considering the following topics, and I > would like to hear your thoughts about them and the general idea of > getting Rust in the hands of students: > - writing a modern http server (or an irc server) in Rust; > - contributing to some of the "easy" bugs; > - getting Rust to produce Android binaries (it doesn't yet, does it?); > - developing a web framework for Rust; > - adding high-level bindings to a number of system-level libraries (e.g. > nss); > - ... > > Any thoughts? Some ideas: * If you're looking for bindings for students to work on, the SpiderMonkey bindings (https://github.com/pcwalton/rust-spidermonkey) could use help. * For Servo we're also interested in bindings to Azure (the cross-platform rendering library), as well as bindings to OpenGL and the native windowing APIs. * Monomorphizing is something I would really like to try, but it's a fair amount of work. Possibly too ambitious for a student project. Serializing ASTs might be doable as a project though, and it's an important step in monomorphizing... but also fairly mechanical and not too interesting from a pedagogical perspective. * Making message passing more efficient. Brian had some ideas to use RCU here. This is fun low-level hacking. * An API to allow third-party libraries to interoperate with Rust host programs better (allowing Rust strings to be easily created from C, sending messages, etc.) This is pretty easy and helps students get acquainted with real codebases. * Implementing prototypes of some of the language feature proposals, like formalized DPS, fixed-length arrays, classes, regions, traits... Regions in particular are interesting from a pedagogical point of view because they're well-studied in the literature and they're fairly straightforward to implement in Rust -- it's mostly all typechecker work. Patrick From zackcorr95 at gmail.com Mon Jan 16 03:52:49 2012 From: zackcorr95 at gmail.com (Zack Corr) Date: Mon, 16 Jan 2012 21:52:49 +1000 Subject: [rust-dev] Advanced math library (std::math) Message-ID: Hello, I've started an advanced math library, which I plan on submitting in a future pull request as std::math, if there are no other plans. It currently includes complex number and quaternion interfaces, and sin cardinal functions (which were required for quaternions). Besides the obvious algebra and statistic tools, are there any suggestions of what else to include? The source code is on Github . Zack -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.plantikow at googlemail.com Mon Jan 16 04:04:23 2012 From: stefan.plantikow at googlemail.com (Stefan Plantikow) Date: Mon, 16 Jan 2012 13:04:23 +0100 Subject: [rust-dev] Advanced math library (std::math) In-Reply-To: References: Message-ID: <283EE563FE7F4F76A5A7495BE8274140@googlemail.com> Am Montag, 16. Januar 2012 um 12:52 schrieb Zack Corr: > I've started an advanced math library, which I plan on submitting in a future pull request as std::math, if there are no other plans. It currently includes complex number and quaternion interfaces, and sin cardinal functions (which were required for quaternions). Besides the obvious algebra and statistic tools, are there any suggestions of what else to include? The source code is on Github (https://github.com/z0w0/rusty-math). Hi, that is great. I'm especially looking forward to statistic tools, like deviation, mean, normalization (normal, softmax), ... Please keep in mind that all numeric types in core will undergo quite a bit of refactoring as we move more towards using type classes. Regarding complex numbers I personally think these should be built-in primitive types because they need special ABI handling when interfacing with C code and would prefer using them with lib math where possible to be in line with f32, f64. -- Stefan Plantikow From graydon at mozilla.com Tue Jan 17 11:15:35 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 17 Jan 2012 11:15:35 -0800 Subject: [rust-dev] cargo and (de)centralization Message-ID: <4F15C8D7.3080408@mozilla.com> Hi, We have a preliminary "package management system" called "cargo" that we're going to be shipping as part of our 0.1 release. We want this to be friendly and usable for people who are developing new rust code and experimenting with the language. It pretty much works now, thanks to elly's hard work, but remains a bit threadbare and doesn't quite have clearly-established conventions for use just yet. I'd like to establish some! It was designed to accommodate decentralization -- supports an arbitrary number of package-listing "sources" that feed end-users -- but for the sake of making packages easily findable I'm *hoping* most users will register with a single central listing. To this end, we have a repository "cargo-central" (at http://github.org/mozilla/cargo-central) that is wired into the default sources list retrieved from www.rust-lang.org when the 'cargo' tool initializes. I've given all users in the rust and rust-push groups on github access to this repository, for merging pull requests. I would *like* to incorporate all existing sources people are using into cargo-central and see if we can maintain "mostly centralized" indexing of packages as a normal community practice, rather than the currently-evolving habit of every user making their own sources file. That is imo a mistake, an over-use of the decentralization mechanism for little gain. Is this ok? If so, and if you happen to have a sources.json file you're already using to point to your package by symbolic name, can you tell me about it so I can fold its contents into cargo-central? All a sources file registry does is map symbolic-name -> fetch mechanism. The underlying repositories are still decentralized. You don't need to update it every time you push new versions of your library or anything. It's a one-time registration. So I *hope* there won't be too much grief over centralization-by-default at this level. You can absolutely use secondary sources of your own making, it's just a matter of which habit we encourage users to adopt (and make easy workflow for). If most people register with cargo-central, most packages should be easily findable by short-name, most of the time. -Graydon From pwalton at mozilla.com Wed Jan 18 12:48:32 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 18 Jan 2012 12:48:32 -0800 Subject: [rust-dev] Zero-variant tags? Message-ID: <4F173020.3070202@mozilla.com> I broke zero-variant tags with my syntax change. Is this something we want to support? Patrick From pwalton at mozilla.com Wed Jan 18 13:04:31 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 18 Jan 2012 13:04:31 -0800 Subject: [rust-dev] Zero-variant tags? In-Reply-To: <4F17318F.5040503@mozilla.com> References: <4F173020.3070202@mozilla.com> <4F17318F.5040503@mozilla.com> Message-ID: <4F1733DF.2060204@mozilla.com> On 1/18/12 12:54 PM, Brendan Eich wrote: > Occasionally useful as a basis case, a kind of void variant? > > /be I usually write that as enum foo { foo(@foo); } Which creates a type foo that you can't actually create instances of (unless you use unsafe::reinterpret_cast::(0) or similar in an unsafe block). But maybe "enum foo { /* unconstructible */ }" is better -- I've wanted void to be easier to define. Note that OCaml lets you say "type foo;;" for this. This is nice for interfacing with C; SpiderMonkey bindings have stuff like: enum JSRuntime { JSRuntime(@JSRuntime) } So that I can write *JSRuntime instead of *int or whatever in C bindings. This is of course useful for phantom types as well. Patrick From graydon at mozilla.com Wed Jan 18 19:36:59 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Wed, 18 Jan 2012 19:36:59 -0800 Subject: [rust-dev] prerelease tarball Message-ID: <4F178FDB.30302@mozilla.com> Hi, I have a certain amount of release-making machinery wired up now, such that by pushing to "distcheck-snap" on origin you will get a tarball and .exe uploaded (after a successful "make distcheck") to the dl host. So you get something like this: http://dl.rust-lang.org/dist/rust-prerelease.tar.gz I'd suggest not clicking on that link though -- the resulting tarball is over 100mb since it includes a complete snapshot of LLVM. Is this ... acceptable? I'm not really sure what to do about it. LLVM is too much of a moving target still and our relationship to it is not at all stable enough to make "use the system LLVM" terribly practical yet. Or so I believe. Am I correct? -Graydon From elly+rd at leptoquark.net Wed Jan 18 19:54:29 2012 From: elly+rd at leptoquark.net (Elly Jones) Date: Wed, 18 Jan 2012 21:54:29 -0600 Subject: [rust-dev] prerelease tarball In-Reply-To: <4F178FDB.30302@mozilla.com> References: <4F178FDB.30302@mozilla.com> Message-ID: <20120119035429.GB4517@leptoquark.net> On Wed, Jan 18, 2012 at 07:36:59PM -0800, Graydon Hoare wrote: > Hi, > > I have a certain amount of release-making machinery wired up now, > such that by pushing to "distcheck-snap" on origin you will get a > tarball and .exe uploaded (after a successful "make distcheck") to > the dl host. So you get something like this: > > http://dl.rust-lang.org/dist/rust-prerelease.tar.gz > > I'd suggest not clicking on that link though -- the resulting > tarball is over 100mb since it includes a complete snapshot of LLVM. > > Is this ... acceptable? I'm not really sure what to do about it. > LLVM is too much of a moving target still and our relationship to it > is not at all stable enough to make "use the system LLVM" terribly > practical yet. Or so I believe. Am I correct? We can't use the system llvm on ubuntu, certainly, as it is 2.9. > -Graydon > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- elly -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From banderson at mozilla.com Wed Jan 18 21:07:44 2012 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 18 Jan 2012 21:07:44 -0800 (PST) Subject: [rust-dev] prerelease tarball In-Reply-To: <4F178FDB.30302@mozilla.com> Message-ID: ----- Original Message ----- > From: "Graydon Hoare" > To: rust-dev at mozilla.org > Sent: Wednesday, January 18, 2012 7:36:59 PM > Subject: [rust-dev] prerelease tarball > > Hi, > > I have a certain amount of release-making machinery wired up now, > such > that by pushing to "distcheck-snap" on origin you will get a tarball > and > .exe uploaded (after a successful "make distcheck") to the dl host. > So > you get something like this: > > http://dl.rust-lang.org/dist/rust-prerelease.tar.gz > > I'd suggest not clicking on that link though -- the resulting tarball > is > over 100mb since it includes a complete snapshot of LLVM. > > Is this ... acceptable? I'm not really sure what to do about it. LLVM > is > too much of a moving target still and our relationship to it is not > at > all stable enough to make "use the system LLVM" terribly practical > yet. > Or so I believe. Am I correct? The snapshot contains the llvm .git directory. Removing it reduces the tarball size by 90%. From catamorphism at gmail.com Thu Jan 19 01:11:22 2012 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu, 19 Jan 2012 01:11:22 -0800 Subject: [rust-dev] Heads up: syntax change with nullary tags in patterns Message-ID: As of 5b028f527f2c487a5f4196fdf3cfc7a2acef74ff the syntax of a pattern consisting of a nullary tag has changed to omit the trailing '.' That is: now we write alt x { some(_) {} none {} } instead of alt x { some(_) {} none. {} } To make this change possible, the typechecker now forbids local variable names that shadow the name of a tag that's in scope. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt ?I cannot hide my anger to spare you guilt, nor hurt feelings, nor answering anger; for to do so insults and trivializes all our efforts. Guilt is not a response to anger; it is a response to one?s own actions or lack of action.? -- Audre Lorde From graydon at mozilla.com Thu Jan 19 15:25:10 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 19 Jan 2012 15:25:10 -0800 Subject: [rust-dev] release pending, proof reading request Message-ID: <4F18A656.5080607@mozilla.com> Hi! Closer to a release, we've done quite a lot of documentation cleanup in the past little while and the "new" docs (posted to the website and auto-generated on each build now) are currently ... in need of proof readers. If anyone has felt a bit shy about contributing and wants to do something *really useful* right now, I'd greatly appreciate extra eyes on the docs, and patches / pull reqs against them (doc/rust.md). Absent substantial changes, we're likely to make our 0.1 release within the next day or so. -Graydon From mad.one at gmail.com Thu Jan 19 16:07:59 2012 From: mad.one at gmail.com (Austin Seipp) Date: Thu, 19 Jan 2012 18:07:59 -0600 Subject: [rust-dev] release pending, proof reading request In-Reply-To: <4F18A656.5080607@mozilla.com> References: <4F18A656.5080607@mozilla.com> Message-ID: Graydon, I'd love to help (and may do so tonight,) but will be absent for the weekend and tomorrow, so time for me is limited to help here in the short term. Because of that, and the release being so soon (and I'll likely miss the announcement,) I have to jump the gun and just wanted to say to you and everyone else: Congratulations! I'm sure all you Mozilla guys are excited and quite happy with the work that's there. And so is this tiny rabbit: http://i.imgur.com/JOWer.jpg On Thu, Jan 19, 2012 at 5:25 PM, Graydon Hoare wrote: > Hi! > > Closer to a release, we've done quite a lot of documentation cleanup in the > past little while and the "new" docs (posted to the website and > auto-generated on each build now) are currently ... in need of proof > readers. > > If anyone has felt a bit shy about contributing and wants to do something > *really useful* right now, I'd greatly appreciate extra eyes on the docs, > and patches / pull reqs against them (doc/rust.md). > > Absent substantial changes, we're likely to make our 0.1 release within the > next day or so. > > -Graydon > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- Regards, Austin From banderson at mozilla.com Fri Jan 20 14:34:26 2012 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 20 Jan 2012 14:34:26 -0800 (PST) Subject: [rust-dev] The Rust compiler 0.1 is unleashed In-Reply-To: <8a8616b6-b624-4798-94cb-99fe5cc68629@zimbra1.shared.sjc1.mozilla.com> Message-ID: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> Today Mozilla and the Rust community are releasing version 0.1 of the Rust compiler and associated tools. Rust is a strongly-typed systems programming language with a focus on memory safety and concurrency. This is the initial release of the compiler after a multi-year development cycle focusing on self-hosting, implementation of major features, and solidifying the syntax. Version 0.1 should be considered an alpha release, suitable for early adopters and language enthusiasts. It's nifty, but it will still eat your laundry. Please file bugs at http://github.com/mozilla/rust/issues. This release is available as both a tarball and a windows installer: * http://dl.rust-lang.org/dist/rust-0.1.tar.gz http://dl.rust-lang.org/dist/rust-0.1.tar.gz.asc SHA256: a1a234592168443b3bd6dce03378ee410393b07f8075c6a56e339638fdda8263 * http://dl.rust-lang.org/dist/rust-0.1-install.exe http://dl.rust-lang.org/dist/rust-0.1-install.exe.asc SHA256: d66ab7ab30832816460bdec29909be267fb2e4f2baf5add4d9449b8166839ca2 Thanks to everybody who has contributed[1]. Regards, The Rust Team Version 0.1 (January 2012) --------------------------- * Most language features work, including: * Unique pointers, unique closures, move semantics * Interface-constrained generics * Static interface dispatch * Stack growth * Multithread task scheduling * Typestate predicates * Failure unwinding, destructors * Pattern matching and destructuring assignment * Lightweight block-lambda syntax * Preliminary macro-by-example * Compiler works with the following configurations: * Linux: x86 and x86_64 hosts and targets * MacOS: x86 and x86_64 hosts and targets * Windows: x86 hosts and targets * Cross compilation / multi-target configuration supported. * Preliminary API-documentation and package-management tools included. Known issues: * Documentation is incomplete. * Performance is below intended target. * Standard library APIs are subject to extensive change, reorganization. * Language-level versioning is not yet operational - future code will break unexpectedly. [1] Contributors to Rust 0.1: Adam Bozanich Andreas Gal Austin Seipp Ben Striegel Benjamin Jackman Brendan Eich Brian Anderson Chris Double Dave Herman David Rajchenbach-Teller Elly Fong-Jones Eric Holk Erick Tryzelaar Erik Rose Grahame Bowland Graham Fawcett Graydon Hoare Haitao Li Jason Orendorff Jeff Balogh Jeff Muizelaar Jeffrey Yasskin Jesse Ruderman Josh Matthews Joshua Wise Jyun-Yan You Kelly Wilson Kevin Atkinson Kevin Cantu Lennart Kudling Lindsey Kuper Marijn Haverbeke Matt Brubeck Michael Bebenita Michael Sullivan Niko Matsakis Or Brostovski Patrick Walton Paul Stansifer Peter Hull Ralph Giles Rafael ?vila de Esp?ndola Reuben Morais Rob Arnold Roland Tanglao Roy Frostig Sean Stangl Stefan Plantikow Tim Chevalier Tycho Sci Wade Mealing From pwalton at mozilla.com Fri Jan 20 14:47:30 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Fri, 20 Jan 2012 14:47:30 -0800 Subject: [rust-dev] The Rust compiler 0.1 is unleashed In-Reply-To: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> References: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4F19EF02.3030501@mozilla.com> On 1/20/12 2:34 PM, Brian Anderson wrote: > Today Mozilla and the Rust community are releasing version 0.1 of the Rust compiler > and associated tools. Congratulations everyone! This is a great day for Rust and there's been a lot of hard work to get to this point. Patrick From arcata at gmail.com Fri Jan 20 14:52:23 2012 From: arcata at gmail.com (Joe Groff) Date: Fri, 20 Jan 2012 14:52:23 -0800 Subject: [rust-dev] The Rust compiler 0.1 is unleashed In-Reply-To: <4F19EF02.3030501@mozilla.com> References: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> <4F19EF02.3030501@mozilla.com> Message-ID: On Fri, Jan 20, 2012 at 2:47 PM, Patrick Walton wrote: > On 1/20/12 2:34 PM, Brian Anderson wrote: >> >> Today Mozilla and the Rust community are releasing version 0.1 of the Rust >> compiler >> and associated tools. Been looking forward to this. Congratulations, and thanks for all the hard work. -Joe From graydon at mozilla.com Fri Jan 20 14:58:32 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Fri, 20 Jan 2012 14:58:32 -0800 Subject: [rust-dev] The Rust compiler 0.1 is unleashed In-Reply-To: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> References: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4F19F198.1040607@mozilla.com> On 12-01-20 02:34 PM, Brian Anderson wrote: > Thanks to everybody who has contributed[1]. Yes, thanks very much. I've been very impressed with all the work everyone have put in in the past 18 months. Not all of you were involved at that point, but .. if I think back to the awkward dialect we were coding in when we published rustboot -- or even the dialect it had matured to by the time we actually bootstrapped -- it's still a bit amazing how far we've come. The language released today (absent the array of last minute, Murphy's law build-breakage and whatnot) is something I'm quite proud to have helped with. It's also very satisfying to realize how little of it is my code anymore; keep the forks and pull requests coming! -Graydon From banderson at mozilla.com Sat Jan 21 13:47:53 2012 From: banderson at mozilla.com (Brian Anderson) Date: Sat, 21 Jan 2012 13:47:53 -0800 (PST) Subject: [rust-dev] Silently-breaking change to core::vec::init_elt In-Reply-To: <056320ac-7476-4e59-9f5c-506506eb552d@zimbra1.shared.sjc1.mozilla.com> Message-ID: Just a heads-up. 7763b40c71372c6be7a65673a968f6174bab4209 Changes core::vec::init_elt to take the count first and the initialization element second. For most existing uses this change will not typecheck so you'll know it's busted, but for vectors of uint it will compile correctly and break mysteriously. From banderson at mozilla.com Sat Jan 21 16:32:49 2012 From: banderson at mozilla.com (Brian Anderson) Date: Sat, 21 Jan 2012 16:32:49 -0800 (PST) Subject: [rust-dev] The Rust compiler 0.1 is unleashed In-Reply-To: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> Message-ID: <5045f699-f14f-4e94-a8d1-d29e081f40a7@zimbra1.shared.sjc1.mozilla.com> We've received a report that the windows installer can damage the system PATH variable, so I've removed it from the servers and removed the link from the website. My sincere apologies to anybody this has affected. Regards, Brian ----- Original Message ----- > From: "Brian Anderson" > To: rust-dev at mozilla.org > Sent: Friday, January 20, 2012 2:34:26 PM > Subject: The Rust compiler 0.1 is unleashed > > Today Mozilla and the Rust community are releasing version 0.1 of the > Rust compiler > and associated tools. > > Rust is a strongly-typed systems programming language with a focus on > memory safety > and concurrency. This is the initial release of the compiler after a > multi-year > development cycle focusing on self-hosting, implementation of major > features, and > solidifying the syntax. > > Version 0.1 should be considered an alpha release, suitable for early > adopters and > language enthusiasts. It's nifty, but it will still eat your laundry. > Please file > bugs at http://github.com/mozilla/rust/issues. > > This release is available as both a tarball and a windows installer: > > * http://dl.rust-lang.org/dist/rust-0.1.tar.gz > http://dl.rust-lang.org/dist/rust-0.1.tar.gz.asc > SHA256: > a1a234592168443b3bd6dce03378ee410393b07f8075c6a56e339638fdda8263 > * http://dl.rust-lang.org/dist/rust-0.1-install.exe > http://dl.rust-lang.org/dist/rust-0.1-install.exe.asc > SHA256: > d66ab7ab30832816460bdec29909be267fb2e4f2baf5add4d9449b8166839ca2 > > Thanks to everybody who has contributed[1]. > > Regards, > The Rust Team > > > Version 0.1 (January 2012) > --------------------------- > > * Most language features work, including: > * Unique pointers, unique closures, move semantics > * Interface-constrained generics > * Static interface dispatch > * Stack growth > * Multithread task scheduling > * Typestate predicates > * Failure unwinding, destructors > * Pattern matching and destructuring assignment > * Lightweight block-lambda syntax > * Preliminary macro-by-example > > * Compiler works with the following configurations: > * Linux: x86 and x86_64 hosts and targets > * MacOS: x86 and x86_64 hosts and targets > * Windows: x86 hosts and targets > > * Cross compilation / multi-target configuration supported. > > * Preliminary API-documentation and package-management tools > included. > > Known issues: > > * Documentation is incomplete. > > * Performance is below intended target. > > * Standard library APIs are subject to extensive change, > reorganization. > > * Language-level versioning is not yet operational - future code > will > break unexpectedly. > > > [1] Contributors to Rust 0.1: > > Adam Bozanich > Andreas Gal > Austin Seipp > Ben Striegel > Benjamin Jackman > Brendan Eich > Brian Anderson > Chris Double > Dave Herman > David Rajchenbach-Teller > Elly Fong-Jones > Eric Holk > Erick Tryzelaar > Erik Rose > Grahame Bowland > Graham Fawcett > Graydon Hoare > Haitao Li > Jason Orendorff > Jeff Balogh > Jeff Muizelaar > Jeffrey Yasskin > Jesse Ruderman > Josh Matthews > Joshua Wise > Jyun-Yan You > Kelly Wilson > Kevin Atkinson > Kevin Cantu > Lennart Kudling > Lindsey Kuper > Marijn Haverbeke > Matt Brubeck > Michael Bebenita > Michael Sullivan > Niko Matsakis > Or Brostovski > Patrick Walton > Paul Stansifer > Peter Hull > Ralph Giles > Rafael ?vila de Esp?ndola > Reuben Morais > Rob Arnold > Roland Tanglao > Roy Frostig > Sean Stangl > Stefan Plantikow > Tim Chevalier > Tycho Sci > Wade Mealing > From dteller at mozilla.com Sun Jan 22 06:41:52 2012 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Sun, 22 Jan 2012 15:41:52 +0100 Subject: [rust-dev] The Rust compiler 0.1 is unleashed In-Reply-To: <5045f699-f14f-4e94-a8d1-d29e081f40a7@zimbra1.shared.sjc1.mozilla.com> References: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> <5045f699-f14f-4e94-a8d1-d29e081f40a7@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4F1C2030.6070202@mozilla.com> Congrats to everybody involved. As soon as I find some time (and if nobody has done it yet), I'll get working on a Mac installer. What's the preferred strategy? Should the Mac installer essentially contain the .tgz and build from source? Or do we have a reference script that builds a package and that I should adapt to Mac? Cheers, David On Sun Jan 22 01:32:49 2012, Brian Anderson wrote: > We've received a report that the windows installer can damage the system PATH variable, so I've removed it from the servers and removed the link from the website. My sincere apologies to anybody this has affected. > > Regards, > Brian > > ----- Original Message ----- >> From: "Brian Anderson" >> To: rust-dev at mozilla.org >> Sent: Friday, January 20, 2012 2:34:26 PM >> Subject: The Rust compiler 0.1 is unleashed >> >> Today Mozilla and the Rust community are releasing version 0.1 of the >> Rust compiler >> and associated tools. >> >> Rust is a strongly-typed systems programming language with a focus on >> memory safety >> and concurrency. This is the initial release of the compiler after a >> multi-year >> development cycle focusing on self-hosting, implementation of major >> features, and >> solidifying the syntax. >> >> Version 0.1 should be considered an alpha release, suitable for early >> adopters and >> language enthusiasts. It's nifty, but it will still eat your laundry. >> Please file >> bugs at http://github.com/mozilla/rust/issues. >> >> This release is available as both a tarball and a windows installer: >> >> * http://dl.rust-lang.org/dist/rust-0.1.tar.gz >> http://dl.rust-lang.org/dist/rust-0.1.tar.gz.asc >> SHA256: >> a1a234592168443b3bd6dce03378ee410393b07f8075c6a56e339638fdda8263 >> * http://dl.rust-lang.org/dist/rust-0.1-install.exe >> http://dl.rust-lang.org/dist/rust-0.1-install.exe.asc >> SHA256: >> d66ab7ab30832816460bdec29909be267fb2e4f2baf5add4d9449b8166839ca2 >> >> Thanks to everybody who has contributed[1]. >> >> Regards, >> The Rust Team >> >> >> Version 0.1 (January 2012) >> --------------------------- >> >> * Most language features work, including: >> * Unique pointers, unique closures, move semantics >> * Interface-constrained generics >> * Static interface dispatch >> * Stack growth >> * Multithread task scheduling >> * Typestate predicates >> * Failure unwinding, destructors >> * Pattern matching and destructuring assignment >> * Lightweight block-lambda syntax >> * Preliminary macro-by-example >> >> * Compiler works with the following configurations: >> * Linux: x86 and x86_64 hosts and targets >> * MacOS: x86 and x86_64 hosts and targets >> * Windows: x86 hosts and targets >> >> * Cross compilation / multi-target configuration supported. >> >> * Preliminary API-documentation and package-management tools >> included. >> >> Known issues: >> >> * Documentation is incomplete. >> >> * Performance is below intended target. >> >> * Standard library APIs are subject to extensive change, >> reorganization. >> >> * Language-level versioning is not yet operational - future code >> will >> break unexpectedly. >> >> >> [1] Contributors to Rust 0.1: >> >> Adam Bozanich >> Andreas Gal >> Austin Seipp >> Ben Striegel >> Benjamin Jackman >> Brendan Eich >> Brian Anderson >> Chris Double >> Dave Herman >> David Rajchenbach-Teller >> Elly Fong-Jones >> Eric Holk >> Erick Tryzelaar >> Erik Rose >> Grahame Bowland >> Graham Fawcett >> Graydon Hoare >> Haitao Li >> Jason Orendorff >> Jeff Balogh >> Jeff Muizelaar >> Jeffrey Yasskin >> Jesse Ruderman >> Josh Matthews >> Joshua Wise >> Jyun-Yan You >> Kelly Wilson >> Kevin Atkinson >> Kevin Cantu >> Lennart Kudling >> Lindsey Kuper >> Marijn Haverbeke >> Matt Brubeck >> Michael Bebenita >> Michael Sullivan >> Niko Matsakis >> Or Brostovski >> Patrick Walton >> Paul Stansifer >> Peter Hull >> Ralph Giles >> Rafael ?vila de Esp?ndola >> Reuben Morais >> Rob Arnold >> Roland Tanglao >> Roy Frostig >> Sean Stangl >> Stefan Plantikow >> Tim Chevalier >> Tycho Sci >> Wade Mealing >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- David Rajchenbach-Teller, PhD Performance Team, Mozilla -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: OpenPGP digital signature URL: From masklinn at masklinn.net Sun Jan 22 03:11:41 2012 From: masklinn at masklinn.net (Masklinn) Date: Sun, 22 Jan 2012 12:11:41 +0100 Subject: [rust-dev] First thoughts on Rust Message-ID: I guess this would be the least-bad mailing list for it considering the other one is -commits. With Rust 0.1, I finally decided to actually test Rust (kudos for a perfect compilation under OSX, by the way, no issue whatsoever to report), and have thus encountered interrogations, dislikes, or issues. And am thus reporting them here. Warning: I only spent about half an hour or an hour with rust. I'm aware some of them might have been discussed to death beforehand and can have rationales, a simple link to these discussions/rationales should be sufficient of course. Interrogations: --------------- * Are there plans for a CLI? Maybe not a full-blown REPL, but a basic execution console which would let users try out snippets without having to create and compile files * In the use-crate specification, are attributes arbitrary and always exactly matched? My concerns are mostly with the `vers` attribute of the examples, as strict equality is sometimes (often) not what is wanted, with richer/more flexible specifications being useful (as well as more than one spec) e.g. vers >= 1.5, vers < 2 - Linked to this, if some attributes have special status does Rust enforce a specific style for version numbers e.g. semver? * Are python-style chained comparison operators (e.g. `3 < a < 5` being true iif a is in ]3.0, 5.0[) planned? They don't seem to be possible right now, the example above fails to typecheck. * Do the rustc &al libraries provide services to third-parties which would allow for easily building e.g. analysis or transformation tools (such as refactoring utilities)? Would they give AST-level access to third-party tools such as the Rust emacs mode or an IDE? I did not see any hint to documentation of these libraries and their services. Issues: ------- * The first one is the apparent (community) usage of "blocks" for Rust's boxed closures[0]. My issue with this is that languages where blocks are first-class objects (Smalltalk, Ruby) default to non-local returns from these blocks. Rust does not ? as far as I can tell ? have ? let alone use ? non-local returns. Using "block" for boxed closures does everybody a disservice as it makes transition much harder and *will* disappoint people used to actual smalltalk-type blocks. The tutorial does not have this issue, which is good, but the community should be careful. Talking about lambdas or sugared lambdas would probably be a good idea (unless Rust is modified to handle and default to non-local returns from stack closures) * The second issue is both trivial and extremely serious: after having written a few trivial pieces of code (can't call them programs), it feels like Rust's handling of semicolons combines the simplicity of Erlang's with the determinism of Javascript's. I think the core issue is that Rust uses semicolons as expression separators where most if not all other braceful languages use them as expression terminators. I know the rules are simple to express, but Erlang demonstrated it would *never* feel right to people in the current state of the language. Erlang also has the issue of three different separators, but Rust has the additional issue that a semicolon becomes the difference between returning a value and returning unit. That's not right. I see three possible ways to fix this: - Don't change Rust's semantics, but change Rust's "blessed" style, by prefixing expressions with semicolons (instead of post-fixing). This is a common style for e.g. RelaxNG-Compact schemas and it looks "correct" for separators - Make semicolons into expression terminators, as in the majority of C-style languages - Add haskell-like layout rules making semicolons redundant in 99.9% of cases, and necessary only when putting multiple expressions on a line or when generating rust code mechanically. This would fix the issue by making semicolons generally unnecessary and thus not a source of error * Strings. I believe Rust's current state of conflating byte sequences and human-text strings to be as big a mistake as it was in Python. If Rust wants to be mainly bytes-oriented the `str` type should be renamed `bytes` and most string-manipulation functions should be removed. Otherwise, I believe it should be split in two clearly separate types, one manipulating sequences or arrays of bytes and the other one manipulating streams of unicode codepoints (for which encoding would be an implementation detail). I think the current setting will hurt both Rust and its users in the long term. One of the first problems being that a byte sequence advertising itself as UTF-8 and actually UTF-8 text have different properties and overlong UTF-8 (which can be found in byte sequences) is an actual security issue[1]. Bytes to string *should* require transcoding, even if that transcoding does nothing more than an O(n) shortest-form assertion because the string type's underlying representation is UTF-8 anyway. Furthermore: - A string type's primary interface should be about graphemes, not codepoints and especially not bytes. And on this I fully agree with Graydon Hoare[1] that O(1) random access is neither necessary nor helpful. While it is not its primary interface, NSString is the only string type I know of which comes close to being good there. In fact overall NSString is the string type closest to providing a good interface for text, as far as I'm concerned. This also makes issues of e.g. normalization issues easier to handle. I am aware it makes string types more complex to have them be "unicode-correct", as many unicode operations rely on locale. But I also believe this to be necessary, I don't believe "works for english speakers" to be sufficient anymore. - A bytes type should have a literal form, I would think this a more useful usage for single quotes than the current `char` literals. Having erlang-style bytes pattern matching/destructuring would be a good usage of bytes having their own literals when it comes to protocol-parsing. * I find strange that Rust has kept the ternary operator even though its conditionals are expressions of their own. * Finally, I could not find any good information on the result of loop expressions, from my tests it seems to always be `()` is that correct? If so, why `()` rather than the last-evaluated result of the iteration? In case no iteration at all is performed? Thank you for reading until this point, looking forward to any reply and have a nice day. [0] https://mail.mozilla.org/pipermail/rust-dev/2012-January/001168.html [1] http://www.unicode.org/reports/tr36/#UTF-8_Exploit [2] https://mail.mozilla.org/pipermail/rust-dev/2012-January/001196.html From me at kevincantu.org Sun Jan 22 20:37:18 2012 From: me at kevincantu.org (Kevin Cantu) Date: Sun, 22 Jan 2012 20:37:18 -0800 Subject: [rust-dev] First thoughts on Rust In-Reply-To: References: Message-ID: You raise some good questions. Regarding your CLI comments: I have a Cargo package named 'rustx' which has some shell scripts to build and run a .rs file (like a simple equivalent to 'runhaskell'). Let me know what you think. I'd also love a REPL, if someone wants to write it. Regarding strings: they're in transition now. Right now, I think you can choose between vectors of bytes ([u8]), strings of UTF-8 (str), and vectors of UCS-4 characters ([char]), and the vector library is pretty good. A lot of the byte-oriented string functions should probably be marked as deprecated, actually, and moved or turned into UTF-8 safe functions. Prepare for some of what you see to change. I'm curious though, because I've not used it in depth, what makes NSString so good. What does it do that Haskell's Text and other languages' string types don't do? And what do you need from a core string library that doesn't belong in, say, an extended package of ICU bindings? -- Kevin Cantu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at atkinson.dhs.org Sun Jan 22 21:52:37 2012 From: kevin at atkinson.dhs.org (Kevin Atkinson) Date: Sun, 22 Jan 2012 22:52:37 -0700 (MST) Subject: [rust-dev] First thoughts on Rust In-Reply-To: References: Message-ID: On Sun, 22 Jan 2012, Kevin Cantu wrote: > Regarding strings: they're in transition now. Right now, I think you can > choose between vectors of bytes ([u8]), strings of UTF-8 (str), and vectors > of UCS-4 characters ([char]), and the vector library is pretty good. A lot > of the byte-oriented string functions should probably be marked as > deprecated, actually, and moved or turned into UTF-8 safe functions. > Prepare for some of what you see to change. Are these plans written down anywhere? I have my own ideas of what I want to see, but I rather see what is planned first. My main concern is the deprecated of byte oriented access into UTF-8 strings. In my view, there needs to be some way to maintain indexes (or maybe pointers) into a string and character oriented access is too inefficient for variable length characters. From niko at alum.mit.edu Sun Jan 22 22:14:30 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Sun, 22 Jan 2012 22:14:30 -0800 Subject: [rust-dev] Iterators, lists, vectors In-Reply-To: <4f0f4297.d483e50a.5ba6.5df4SMTPIN_ADDED@mx.google.com> References: <201539446.1742.1326382232447.JavaMail.open-xchange@email.1und1.de <4F0F1CB2.5080008@mozilla.com> <4F0F23E9.40309@alum.mit.edu> <4f0f4297.d483e50a.5ba6.5df4SMTPIN_ADDED@mx.google.com> Message-ID: <4F1CFAC6.3000203@alum.mit.edu> Take a look at the iter library. You can install it via cargo or find it here: https://github.com/nikomatsakis/rust-iter Feedback very welcome. Some work is needed to make it nicer to use, but the idea is basically right. Right now there are some limitations to the current impl of method calls (for example, you cannot bind "a.b(_)") that need to be patched up to make the whole thing use ifaces and impls rather than top-level functions. Niko On 1/12/12 12:29 PM, Rust wrote: > > > Niko Matsakis hat am 12. Januar 2012 um 19:18 > geschrieben: > > > On 1/12/12 9:47 AM, Graydon Hoare wrote: > > > More generally though, I think block-centric is best, and perhaps > > > provide a standard vec method that appends-to-a-vec everything fed > to it. > > [...] > > > or even: > > > > let keys = hash.keys.to_list(); > Actually, this sounds like a good compromise to me. > I'm looking forward to this. From banderson at mozilla.com Sun Jan 22 22:18:58 2012 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 22 Jan 2012 22:18:58 -0800 (PST) Subject: [rust-dev] First thoughts on Rust In-Reply-To: Message-ID: <98ab230a-2515-433c-91d1-50dc6480daf0@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > From: "Masklinn" > To: rust-dev at mozilla.org > Sent: Sunday, January 22, 2012 3:11:41 AM > Subject: [rust-dev] First thoughts on Rust > > I guess this would be the least-bad mailing list for it > considering the other one is -commits. > > With Rust 0.1, I finally decided to actually test Rust (kudos for > a perfect compilation under OSX, by the way, no issue whatsoever > to report), and have thus encountered interrogations, dislikes, > or issues. And am thus reporting them here. Warning: I only spent > about half an hour or an hour with rust. Thanks for the thoughtful comments! > I'm aware some of them might have been discussed to death > beforehand and can have rationales, a simple link to these > discussions/rationales should be sufficient of course. > > Interrogations: > --------------- > > * Are there plans for a CLI? Maybe not a full-blown REPL, but a > basic execution console which would let users try out snippets > without having to create and compile files No solid plans, but I'm sure everyone agrees it would be sweet. > > * In the use-crate specification, are attributes arbitrary and > always exactly matched? My concerns are mostly with the `vers` > attribute of the examples, as strict equality is > sometimes (often) not what is wanted, with richer/more flexible > specifications being useful (as well as more than one spec) > e.g. vers >= 1.5, vers < 2 > - Linked to this, if some attributes have special status does > Rust enforce a specific style for version numbers > e.g. semver? Besides 'name' and 'vers' the attributes are arbitrary and by convention. Right now they are exactly matched, but you are right that's often not what one wants. Versioning is very incomplete at the moment. I think currently rustc doesn't enforce anything except that 'name' and 'vers' are strings (and not some other literal type). > * Are python-style chained comparison operators (e.g. `3 < a < 5` > being true iif a is in ]3.0, 5.0[) planned? They don't seem to > be possible right now, the example above fails to typecheck. I have never heard this discussed. > * Do the rustc &al libraries provide services to third-parties > which would allow for easily building e.g. analysis or > transformation tools (such as refactoring utilities)? Would > they give AST-level access to third-party tools such as the > Rust emacs mode or an IDE? I did not see any hint to > documentation of these libraries and their services. Absolutely. rustc is just a driver that links to librustc, which is also used by cargo, rustdoc and the fuzzer. There's no documentation because nobody has put effort into designing a nice API and it's not a major focus right now. The intent is definitely that the compiler be exposed as one or more libraries for tools to use. > Issues: > ------- > > * The first one is the apparent (community) usage of "blocks" for > Rust's boxed closures[0]. My issue with this is that languages > where > blocks are first-class objects (Smalltalk, Ruby) default to > non-local returns from these blocks. Rust does not ? as far as I > can > tell ? have ? let alone use ? non-local returns. > > Using "block" for boxed closures does everybody a disservice as it > makes transition much harder and *will* disappoint people used to > actual smalltalk-type blocks. The tutorial does not have this > issue, > which is good, but the community should be careful. Talking about > lambdas or sugared lambdas would probably be a good idea (unless > Rust is modified to handle and default to non-local returns from > stack closures) Non-local returns have been discussed frequently - there's a lot of demand but so far we haven't come up with a way to do it that anybody is that thrilled about. I think the term 'block' is being phased out - the keyword is definitely going away. Possibly they will be referred to as 'stack closures'. > * The second issue is both trivial and extremely serious: after > having written a few trivial pieces of code (can't call them > programs), it feels like Rust's handling of semicolons combines > the simplicity of Erlang's with the determinism of > Javascript's. Others share your opinion, and it is admittedly a stumbling block. > I think the core issue is that Rust uses semicolons as expression > separators where most if not all other braceful languages use them > as expression terminators. I know the rules are simple to express, > but Erlang demonstrated it would *never* feel right to people in > the > current state of the language. Erlang also has the issue of three > different separators, but Rust has the additional issue that a > semicolon becomes the difference between returning a value and > returning unit. That's not right. > > I see three possible ways to fix this: > > - Don't change Rust's semantics, but change Rust's "blessed" style, > by prefixing expressions with semicolons (instead of > post-fixing). This is a common style for e.g. RelaxNG-Compact > schemas and it looks "correct" for separators > > - Make semicolons into expression terminators, as in the majority > of > C-style languages To do this I think the type checker would have to infer your intentions about what should be done with the last statement of the block. Some rules have been proposed in the past to make this work, but I don't remember the details. > > - Add haskell-like layout rules making semicolons redundant in > 99.9% > of cases, and necessary only when putting multiple expressions on > a line or when generating rust code mechanically. This would fix > the issue by making semicolons generally unnecessary and thus not > a source of error > > * Strings. I believe Rust's current state of conflating byte > sequences > and human-text strings to be as big a mistake as it was in Python. I don't have any knowledge about this subject. It's a terribly difficult thing to get right, and I do worry about the built in string type and accompanying library. > * I find strange that Rust has kept the ternary operator even though > its conditionals are expressions of their own. At one point there was some desire to be able to write if-else expressions more compactly and it was trivial to add to the language. I tend to agree that it's not necessary. > * Finally, I could not find any good information on the result of > loop > expressions, from my tests it seems to always be `()` is that > correct? If so, why `()` rather than the last-evaluated result of > the iteration? In case no iteration at all is performed? You are correct that loop expressions always have type (). The reason you suggest sounds convincing to me. > Thank you for reading until this point, looking forward to any reply > and have a nice day. > > [0] > https://mail.mozilla.org/pipermail/rust-dev/2012-January/001168.html > [1] http://www.unicode.org/reports/tr36/#UTF-8_Exploit > [2] > https://mail.mozilla.org/pipermail/rust-dev/2012-January/001196.html > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From me at kevincantu.org Sun Jan 22 22:42:22 2012 From: me at kevincantu.org (Kevin Cantu) Date: Sun, 22 Jan 2012 22:42:22 -0800 Subject: [rust-dev] First thoughts on Rust In-Reply-To: References: Message-ID: This lists a variety of renamings, etc. geared towards emphasizing characters over bytes in the string lib: https://github.com/mozilla/rust/wiki/Note-libcore I should update that list a little, but it was still the plan last time I asked. -- Kevin Cantu From kevin at atkinson.dhs.org Sun Jan 22 22:56:47 2012 From: kevin at atkinson.dhs.org (Kevin Atkinson) Date: Sun, 22 Jan 2012 23:56:47 -0700 (MST) Subject: [rust-dev] First thoughts on Rust In-Reply-To: References: Message-ID: On Sun, 22 Jan 2012, Kevin Cantu wrote: > This lists a variety of renamings, etc. geared towards emphasizing > characters over bytes in the string lib: > https://github.com/mozilla/rust/wiki/Note-libcore Okay, I thought that there might of been more ambitious plans. Nothing major there. A few minor points. Why: slice_char instead of char_slice slice_unsafe instead of unsafe_slice The later reads better, in by view. Fortunately, there is no mention of depicting any of the byte access routines, although its fair to make them unsafe when they truly are. From masklinn at masklinn.net Mon Jan 23 02:43:53 2012 From: masklinn at masklinn.net (Masklinn) Date: Mon, 23 Jan 2012 11:43:53 +0100 Subject: [rust-dev] First thoughts on Rust In-Reply-To: References: Message-ID: <43F341F9-7F46-4394-A85F-4E382A67231F@masklinn.net> On 2012-01-23, at 05:37 , Kevin Cantu wrote: > I'm curious though, because I've not used it in depth, what makes NSString > so good. What does it do that Haskell's Text and other languages' string > types don't do? First-class interaction with grapheme clusters (which it calls "composed characters)[0], I don't remember seeing that in any other language, and good first-class (not tucked in a library hidden out of the way) support for Unicode text manipulation algorithms (lower and upper case conversions, sorting, etc?) > And what do you need from a core string library that > doesn't belong in, say, an extended package of ICU bindings? As far as I am concerned, any string operation which is defined in Unicode should be either implemented "correctly" (according to unicode) on the string type or not at all (and delegated to a third-party library). This means, for instance, either string comparisons should implement the UCA or they should be forbidden. This, of course, does not apply to a bytes/[w8] type, which would operate solely at the byte level. [0] http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/stringsClusters.html#//apple_ref/doc/uid/TP40008025 From masklinn at masklinn.net Mon Jan 23 02:58:10 2012 From: masklinn at masklinn.net (Masklinn) Date: Mon, 23 Jan 2012 11:58:10 +0100 Subject: [rust-dev] First thoughts on Rust In-Reply-To: <98ab230a-2515-433c-91d1-50dc6480daf0@zimbra1.shared.sjc1.mozilla.com> References: <98ab230a-2515-433c-91d1-50dc6480daf0@zimbra1.shared.sjc1.mozilla.com> Message-ID: <0FCDF40F-5957-42EE-8F93-8FC92DDE8900@masklinn.net> On 2012-01-23, at 07:18 , Brian Anderson wrote: >> * Do the rustc &al libraries provide services to third-parties >> which would allow for easily building e.g. analysis or >> transformation tools (such as refactoring utilities)? Would >> they give AST-level access to third-party tools such as the >> Rust emacs mode or an IDE? I did not see any hint to >> documentation of these libraries and their services. > > Absolutely. rustc is just a driver that links to librustc, which is also used by cargo, rustdoc and the fuzzer. There's no documentation because nobody has put effort into designing a nice API and it's not a major focus right now. The intent is definitely that the compiler be exposed as one or more libraries for tools to use. Neat. I think that's one area where rust could shine, few language provide tooling hooks (and incidentally good tools), that it be *easy* to create tools for Rust (or to use Rust's own tools to analyze rust code) could be a selling point for the high-IDE crowd. >> * The first one is the apparent (community) usage of "blocks" for >> Rust's boxed closures[0]. My issue with this is that languages >> where >> blocks are first-class objects (Smalltalk, Ruby) default to >> non-local returns from these blocks. Rust does not ? as far as I >> can >> tell ? have ? let alone use ? non-local returns. >> >> Using "block" for boxed closures does everybody a disservice as it >> makes transition much harder and *will* disappoint people used to >> actual smalltalk-type blocks. The tutorial does not have this >> issue, >> which is good, but the community should be careful. Talking about >> lambdas or sugared lambdas would probably be a good idea (unless >> Rust is modified to handle and default to non-local returns from >> stack closures) > > Non-local returns have been discussed frequently - there's a lot of demand but so far we haven't come up with a way to do it that anybody is that thrilled about. I think the term 'block' is being phased out - the keyword is definitely going away. Possibly they will be referred to as 'stack closures'. Yeah, I don't think non-local returns are necessary (as Rust tends to use language special forms), I just meant that attention should be paid to the lingo in order not to mislead new users. >> - Make semicolons into expression terminators, as in the majority >> of >> C-style languages > > To do this I think the type checker would have to infer your intentions about what should be done with the last statement of the block. Some rules have been proposed in the past to make this work, but I don't remember the details. Or the last expression evaluated would always be the return value of the block, and if one wants to return `nil` one would end the block with `();`. This *may* also lead Rust developers towards a more functional path (if you're going to return something anyway, it might as well be something useful). >> * I find strange that Rust has kept the ternary operator even though >> its conditionals are expressions of their own. > > At one point there was some desire to be able to write if-else expressions more compactly and it was trivial to add to the language. I can see that. On the other hand, I will quote Tony Hoare on trivial-to-add features: > I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. Of course a case *for* the ternary can also be made relative to ease of switching from other braceful languages (somewhat similar to the reason for the `for` special form in Ruby) >> * Finally, I could not find any good information on the result of >> loop >> expressions, from my tests it seems to always be `()` is that >> correct? If so, why `()` rather than the last-evaluated result of >> the iteration? In case no iteration at all is performed? > > You are correct that loop expressions always have type (). The reason you suggest sounds convincing to me. Alternatively, they could collect the result of each iteration in a vector. From pwalton at mozilla.com Mon Jan 23 09:11:19 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 23 Jan 2012 09:11:19 -0800 Subject: [rust-dev] First thoughts on Rust In-Reply-To: References: Message-ID: <4F1D94B7.20802@mozilla.com> On 01/22/2012 03:11 AM, Masklinn wrote: > * The first one is the apparent (community) usage of "blocks" for > Rust's boxed closures[0]. My issue with this is that languages where > blocks are first-class objects (Smalltalk, Ruby) default to > non-local returns from these blocks. Rust does not ? as far as I can > tell ? have ? let alone use ? non-local returns. > > Using "block" for boxed closures does everybody a disservice as it > makes transition much harder and *will* disappoint people used to > actual smalltalk-type blocks. The tutorial does not have this issue, > which is good, but the community should be careful. Talking about > lambdas or sugared lambdas would probably be a good idea (unless > Rust is modified to handle and default to non-local returns from > stack closures) Nobody could find a way to implement non-local returns in a performant way, so they're missing. There's been discussion of a magic "loopctl" enum type as a return type for blocks, which would allow non-local returns with cooperation between the loop function and the block. > * The second issue is both trivial and extremely serious: after > having written a few trivial pieces of code (can't call them > programs), it feels like Rust's handling of semicolons combines > the simplicity of Erlang's with the determinism of > Javascript's. > > I think the core issue is that Rust uses semicolons as expression > separators where most if not all other braceful languages use them > as expression terminators. I know the rules are simple to express, > but Erlang demonstrated it would *never* feel right to people in the > current state of the language. Erlang also has the issue of three > different separators, but Rust has the additional issue that a > semicolon becomes the difference between returning a value and > returning unit. That's not right. > > I see three possible ways to fix this: > > - Don't change Rust's semantics, but change Rust's "blessed" style, > by prefixing expressions with semicolons (instead of > post-fixing). This is a common style for e.g. RelaxNG-Compact > schemas and it looks "correct" for separators > > - Make semicolons into expression terminators, as in the majority of > C-style languages > > - Add haskell-like layout rules making semicolons redundant in 99.9% > of cases, and necessary only when putting multiple expressions on > a line or when generating rust code mechanically. This would fix > the issue by making semicolons generally unnecessary and thus not > a source of error I like OCaml's solution, which is to simply ignore trailing semicolons. In order to do this we need to reform the standard library to avoid returning values that are unused (which is a good idea anyway, so this is a lesser problem). But IIRC when this was tried, there were parsiing ambiguities involving loops and sugared block syntax (basically, the set of expressions that automatically infer a trailing semicolon). We would have to solve those issues somehow. Options (1) and (3) are basically changing the entire syntactic family that Rust belongs to. I don't agree that this is a serious enough issue to warrant that. > * Strings. I believe Rust's current state of conflating byte sequences > and human-text strings to be as big a mistake as it was in Python. > > If Rust wants to be mainly bytes-oriented the `str` type should be > renamed `bytes` and most string-manipulation functions should be > removed. > > Otherwise, I believe it should be split in two clearly separate > types, one manipulating sequences or arrays of bytes and the other > one manipulating streams of unicode codepoints (for which encoding > would be an implementation detail). > > I think the current setting will hurt both Rust and its users in the > long term. One of the first problems being that a byte sequence > advertising itself as UTF-8 and actually UTF-8 text have different > properties and overlong UTF-8 (which can be found in byte sequences) > is an actual security issue[1]. Bytes to string *should* require > transcoding, even if that transcoding does nothing more than an O(n) > shortest-form assertion because the string type's underlying > representation is UTF-8 anyway. It was always the intention to do things more or less the way you suggest (str is Unicode-correct, [u8] is not Unicode-correct), although I'm not sure whether we want to make libicu a dependency of every Rust program. The [u8]->str conversion function is called "unsafe_from_bytes" for this reason, for example -- it's unsafe because it's not calling into libicu to perform the conversion. In other words, this is mostly a standard library hygiene issue. > * Finally, I could not find any good information on the result of loop > expressions, from my tests it seems to always be `()` is that > correct? If so, why `()` rather than the last-evaluated result of > the iteration? In case no iteration at all is performed? Yes. Rust matches OCaml here. Patrick From masklinn at masklinn.net Mon Jan 23 09:34:29 2012 From: masklinn at masklinn.net (Masklinn) Date: Mon, 23 Jan 2012 18:34:29 +0100 Subject: [rust-dev] First thoughts on Rust In-Reply-To: <4F1D94B7.20802@mozilla.com> References: <4F1D94B7.20802@mozilla.com> Message-ID: On 2012-01-23, at 18:11 , Patrick Walton wrote: > >> - Don't change Rust's semantics, but change Rust's "blessed" style, >> by prefixing expressions with semicolons (instead of >> post-fixing). This is a common style for e.g. RelaxNG-Compact >> schemas and it looks "correct" for separators >> >> - Make semicolons into expression terminators, as in the majority of >> C-style languages >> >> - Add haskell-like layout rules making semicolons redundant in 99.9% >> of cases, and necessary only when putting multiple expressions on >> a line or when generating rust code mechanically. This would fix >> the issue by making semicolons generally unnecessary and thus not >> a source of error > > Options (1) and (3) are basically changing the entire syntactic family that Rust belongs to. I don't agree that this is a serious enough issue to warrant that. Option (1) is the current state of things, made clearer (and more visually logical) through a "better" style, it does not change anything in the language. Did you mean options (2) and (3)? > It was always the intention to do things more or less the way you suggest (str is Unicode-correct, [u8] is not Unicode-correct), although I'm not sure whether we want to make libicu a dependency of every Rust program. The [u8]->str conversion function is called "unsafe_from_bytes" for this reason, for example -- it's unsafe because it's not calling into libicu to perform the conversion. For what it's worth, there really is no need to link against libicu just to perform minimal utf8 encoding assertion on byte sequences. From niko at alum.mit.edu Mon Jan 23 09:54:59 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 23 Jan 2012 09:54:59 -0800 Subject: [rust-dev] First thoughts on Rust In-Reply-To: <4F1D94B7.20802@mozilla.com> References: <4F1D94B7.20802@mozilla.com> Message-ID: <4F1D9EF3.6090805@alum.mit.edu> First off, Masklinn thanks for your feedback (I know others have said it, but I wanted to chime in). This kind of thing is inordinately useful. > *pcwalton: *Nobody could find a way to implement non-local returns in > a performant way, so they're missing. There's been discussion of a > magic "loopctl" enum type as a return type for blocks, which would > allow non-local returns with cooperation between the loop function and > the block. I finally got around to writing up my idea . It's not full-on smalltalk blocks but it would be straightforward to implement and nice to have. Worse is better and all that. >> *OP: ** The second issue is both trivial and extremely serious: after >> having written a few trivial pieces of code (can't call them >> programs), it feels like Rust's handling of semicolons combines >> the simplicity of Erlang's with the determinism of >> Javascript's. I think the criticism is fair enough---even though I authored the current rules I am not sure they are best, though I prefer them to what we had before---but I do want to point out that the rules are not non-deterministic or anything like that. In fact, I made a big effort to ensure that programs which are not parsed "as they appear" will result in compile errors. For example, something like this: fn foo(v: [int]) -> int { vec::foldl(v, 0, {|x, y| x + y}) - 10 } looks like it sums up all of the integers in the list and subtracts 10, but in fact it parses as: fn foo(v: [int]) -> int { vec::foldl(v, 0, {|x, y| x + y}) // throw away the return value -10 } This would seem like a big problem, except that the type checker will report an error because vec::foldl() has a non-unit return type and an omitted semicolon. Of course, if you're the innocent author who doesn't realize WHY you're getting an error, it can still be quite confusing! Personally I think we were going to change the current rules I would want to just use a semicolon consistently after every statement, whether or not a similar statement would have a semicolon in C. So you would write: fn foo() { ... } // this is a declaration, no semicolon while test { ... }; // this is a statement, use a semicolon ret foo; and so forth. I would probably also make the trailing semicolon insignificant, as discussed below. As pcwalton said, though, this would mean that we feel "even less" like C. > *pcwalton: *I like OCaml's solution, which is to simply ignore > trailing semicolons. In order to do this we need to reform the > standard library to avoid returning values that are unused (which is a > good idea anyway, so this is a lesser problem). But IIRC when this was > tried, there were parsiing ambiguities involving loops and sugared > block syntax (basically, the set of expressions that automatically > infer a trailing semicolon). We would have to solve those issues somehow. Actually, the parser was not the problem. In fact, the parser does not currently look "inside" blocks and that sort of thing like it used to. The problem was that I tried to change the representation of a block from a pair of (stmts, tail expr) to just (stmts), and this triggered lots of changes. If I were to try again, I think I would keep block the way it was. What is needed, however, is a change to the type checker which says that tail expressions in a unit return context are effectively ignored. In other words, I think that a function like: fn bar(...) -> int { /* some side effect-y thing */ } fn foo(...) { bar(...); } should still type check, but if we get overeager on the unification it will not. I also made this change to the type checker. It was minor. It seemed to work fine. I'm sure it might give a somewhat surprising error in some corner cases, like blocks where we are inferring the return type (those need work anyhow), but that's probably ok. In the end, though, I decided to go the more conservative route and not modify the type checker but instead simply require that statements without a trailing semicolon must have unit type. All that said, I think what the OP was complaining about was not knowing when a semicolon is required and when it is not. This can be a bit confusing. The rule is more-or-less "if it ends with braces, it does not need a semicolon", but this is not true when e.g. the expression is embedded in a `let` (as, then, the `let` itself needs a semicolon). So the following are fine and do not require semicolons: foo() {|| ... } if ... { ... } else { ... } but this does: let x = foo() {|| ... }; >> *OP: ** Finally, I could not find any good information on the result >> of loop >> expressions, from my tests it seems to always be `()` is that >> correct? If so, why `()` rather than the last-evaluated result of >> the iteration? In case no iteration at all is performed? By the by, I believe that do-while loops return the value of the final iteration (they always have at least 1). Niko From masklinn at masklinn.net Mon Jan 23 09:59:26 2012 From: masklinn at masklinn.net (Masklinn) Date: Mon, 23 Jan 2012 18:59:26 +0100 Subject: [rust-dev] First thoughts on Rust In-Reply-To: <4F1D9EF3.6090805@alum.mit.edu> References: <4F1D94B7.20802@mozilla.com> <4F1D9EF3.6090805@alum.mit.edu> Message-ID: <04E92534-1AA7-4117-B302-28350DBEDD0D@masklinn.net> On 2012-01-23, at 18:54 , Niko Matsakis wrote: > > I think the criticism is fair enough---even though I authored the current rules I am not sure they are best, though I prefer them to what we had before---but I do want to point out that the rules are not non-deterministic or anything like that. Oh absolutely, as I note in the next paragraph I understand that there are (pretty simple) rules to it (and I think I understand these rules as well, though I could very well be wrong there) just as there are rules in Erlang and Javascript. The first paragraph is mostly about the feel of it when encountering it, which I believe would plague the language as much as it does e.g. Erlang. From graydon at mozilla.com Mon Jan 23 12:48:10 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 23 Jan 2012 12:48:10 -0800 Subject: [rust-dev] First thoughts on Rust In-Reply-To: <43F341F9-7F46-4394-A85F-4E382A67231F@masklinn.net> References: <43F341F9-7F46-4394-A85F-4E382A67231F@masklinn.net> Message-ID: <4F1DC78A.1090601@mozilla.com> On 23/01/2012 2:43 AM, Masklinn wrote: > On 2012-01-23, at 05:37 , Kevin Cantu wrote: >> I'm curious though, because I've not used it in depth, what makes NSString >> so good. What does it do that Haskell's Text and other languages' string >> types don't do? > First-class interaction with grapheme clusters (which it calls "composed characters)[0], I don't remember seeing that in any other language, and good first-class (not tucked in a library hidden out of the way) support for Unicode text manipulation algorithms (lower and upper case conversions, sorting, etc?) You're asking for a locale-qualified composed-character type. That's more than a string type. That's much higher up the ladder towards UI. Str is more like int or float, or say one of those nice date-time types like TAI64. Not like a UI object representing "number" or "text" or "calendar date". Those UI concepts contain buckets of affordances that have no relevance -- just cost and limitation -- to most instances of the datatype that occur lower down in the program. Use of strings for display-to-humans-as-UI is actually a pretty narrow subset of all the strings your average program works with. Making such UI-level concepts the sole representation might make sense in a world where: - Performance doesn't matter. Space, time, etc. - Programmers never want to think of the thing in terms of its lower-level representation. But IMO that's not the general condition. >> And what do you need from a core string library that >> doesn't belong in, say, an extended package of ICU bindings? > > As far as I am concerned, any string operation which is defined in Unicode should be either implemented "correctly" (according to unicode) on the string type or not at all (and delegated to a third-party library). I agree with this. If it's a "string operation defined in unicode", we intend to ship the real thing. The things in libcore that claim to be unicode-y are correct unicode algorithms. We just don't ship *all* and *only* unicode algorithms in libcore; some will be pushed to libstd or further (punting to libICU) if they seem rare. Unicode is a huge standard. Moreover, we do (and will continue to) ship algorithms on str values that are not defined by unicode. More on this next... > This means, for instance, either string comparisons should implement the UCA or they should be forbidden. I disagree with this. In particular, I disagree with the idea that the only comparison that exists is UCA comparison. UCA-comparison is not even a single operation at all: it's a *family* of highly customizable operations. That the documentation clearly lists a number of serious shortcomings of: - It's very slow. - It is not a stable sort. - It is not preserved under concatenation or substring. - It's highly variable: results vary by locale, legal system and organizational tailorings, phonetic dictionaries, etc. etc. - It will disagree with any tool doing codepoint or byte order. - It is subject to revision by the unicode consortium and may be found to be in wildly different states on opposite ends of a communication medium (say). All this is not to disparage the fine work done by the consortium. UCA is a massive work of linguistic engineering. It's also inappropriate for jamming into the middle of all uses of strings. The authors are quite clear on that: "The Unicode Collation Algorithm does not restrict the many different ways in which implementations can compare strings" Most uses of strings involve computers talking to other computers, or to themselves, not humans via a GUI. And most of those operations are more like: - Bulk IO. - Use as keys in hashtables or balanced trees. - Substring and concatenation operations. These operations do, regularly, have use for a "<" operator that does something a lot less than any particular locale-customization of UCA. Namely: memcmp. So that's what we do for <. It's a different operation than any UCA operator. It has a different API. A proper API for a UCA operation isn't even *expressible* as a < expression, since as the spec states "collation is not a property of strings". It has to be tailored by locale and a dozen other features of the scripts. Similarly, demanding the sole representation for our strings be in precomposed-grapheme form means that all bulk IO on strings takes not just a codepoint conversion hit, but a normalization-pass hit. That's a very high cost and there's no reason to assume "most" uses of strings require it. (Plus one can't even implement either of these things without shipping a program with an 18mb library. Again, this only makes sense in a world where performance costs are somehow invisible or not counted.) > This, of course, does not apply to a bytes/[w8] type, which would operate solely at the byte level. In rust, str is not [u8]. Str is unicode, [u8] is a step further down. Str is just held in the most common and future-proof unicode encoding to avoid constant round-tripping through different encodings and normalizations during bulk IO, and to grant default operations like < and == based on performance and commonality estimates and our own experience writing code that uses strings. I'm willing to listen to arguments about "commonality" to some extent, but I'd be very surprised if your position is that most programs you've worked on would benefit from (say) their balanced trees implementing DUCET father than memcmp. I think many of them would just break, and the remainder would slow down by a factor of 100. Str is, in other words, a point of tension between many forces, like int and float. One of those forces is definitely "be unicode" -- we have no intention of *burying* unicode-ness -- but performance, commonality, simplicity and compatibility are also concerns. -Graydon From niko at alum.mit.edu Mon Jan 23 20:09:35 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 23 Jan 2012 20:09:35 -0800 Subject: [rust-dev] Syntax change! Message-ID: <4F1E2EFF.6040103@alum.mit.edu> Just a warning: Per recent discussions, I just pushed a change that removed the `block` keyword (which used to be deprecated). Parameters that use to have type "block(T) -> U" should now have type "fn(T) -> U". Creating a stack closure is still best done with the sugared closure syntax `{|x, y| x+y}`. If you wish to declare an explicit stack closure for some reason, the syntax `block(x: uint, y: uint) -> uint { x + y }` no longer works, you must do `fn&(x: uint, y: uint) -> uint { x + y }`. The full set of function types are now: native fn(T) -> U a "bare" function without environment fn(T) -> U any closure at all fn@(T) -> U "boxed" or task-local closure fn~(T) -> U unique closure fn&(T) -> U stack closure All function types are subtypes of "fn(T) -> U", and "native fn(T) -> U" is a subtype of all other types. All the closure types are represented as the pair of a function and the environment. Eventually, "native fn(T) -> U" will be represented by a single function pointer, but for now it is represented as the pair of a function pointer and a null environment. Niko From graydon at mozilla.com Tue Jan 24 10:56:03 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Tue, 24 Jan 2012 10:56:03 -0800 Subject: [rust-dev] Syntax change! In-Reply-To: <4F1E2EFF.6040103@alum.mit.edu> References: <4F1E2EFF.6040103@alum.mit.edu> Message-ID: <4F1EFEC3.7000805@mozilla.com> On 12-01-23 08:09 PM, Niko Matsakis wrote: > The full set of function types are now: Thanks for sorting this out. It was never going to be pretty but I think this is likely the best we can do without losing representation control, and it's nice to have at least a coherent story :) -Graydon From talex5 at gmail.com Tue Jan 24 12:24:51 2012 From: talex5 at gmail.com (Thomas Leonard) Date: Tue, 24 Jan 2012 20:24:51 +0000 Subject: [rust-dev] Cargo requirements Message-ID: Hi, I saw the Rust announcement on OSNews today and had a look through the tutorial. I noticed that Rust has its own package manager (cargo). I'm hope you don't mind, but I'm interested in collecting the requirements of the various language-specific installers out there (Rust's cargo, Haskell's cabal, Python's easy-install, etc), with a view to finding a way to address them all in future versions of 0install. Basically, I'd like to make a list of short-comings in existing installation systems that cargo addresses (e.g. poor documentation, too many dependencies, lack of robustness, poor security, etc). Thanks, -- Dr Thomas Leonard? ? ? ? http://0install.net/ GPG: 9242 9807 C985 3C07 44A6? 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA? BD8E 0713 3F96 CA74 D8BA From thegreendragon at gmail.com Wed Jan 25 10:42:33 2012 From: thegreendragon at gmail.com (Matthew O'Connor) Date: Wed, 25 Jan 2012 11:42:33 -0700 Subject: [rust-dev] tail-call performance issue? Message-ID: Hi, I was reading https://github.com/mozilla/rust/wiki/Bikeshed-tailcall and wondered about the statement "Tail calls cannot be implemented in general without a serious performance hit for all calls". I've never heard this before. tjc speculated it had to do with decrementing refcounts on normal function returns, but our discussion didn't reveal any obvious reasons. What is the reason for this performance hit on all calls? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Wed Jan 25 10:46:33 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 25 Jan 2012 10:46:33 -0800 Subject: [rust-dev] tail-call performance issue? In-Reply-To: References: Message-ID: <4F204E09.7070108@mozilla.com> On 1/25/12 10:42 AM, Matthew O'Connor wrote: > Hi, > > I was reading https://github.com/mozilla/rust/wiki/Bikeshed-tailcall and > wondered about the statement "Tail calls cannot be implemented in > general without a serious performance hit for all calls". I've never > heard this before. tjc speculated it had to do with decrementing > refcounts on normal function returns, but our discussion didn't reveal > any obvious reasons. > > What is the reason for this performance hit on all calls? Pascal calling conventions versus C ones, basically. To handle tail calls in the case in which the callee has more arguments than the caller, you have to make sure that callees pop all their arguments (the Pascal convention). This prevents callers from reusing one set of outgoing argument space for all calls (the C convention). I don't know what the performance hit is in practice; I suspect it's fairly small and not serious. I'm sure that one could make a microbenchmark that performs significantly worse under Pascal calling conventions than C ones, though. Patrick From marijnh at gmail.com Wed Jan 25 11:46:20 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Wed, 25 Jan 2012 20:46:20 +0100 Subject: [rust-dev] Proposal: rename sequence concatenation operator to ++ Message-ID: Currently it is simply '+'. The thing that prompted this is issue #1520 -- operator overloading. Delegating + on non-builtin-numeric types to a `num` interface that implements methods add/sub/mult/div/rem/neg methods seems elegant, and similar to Haskell's approach. Vector-concatenation + messes everything up though, since vectors can't meaningfully implement the full num interface. In general, it seems preferable to have operators mean a single thing. The code in the compiler that handles + is often quite clumsy, precisely because two very different things have to be dealt with. I briefly floated the idea on IRC to just get rid of a concat binop altogether, and use library calls for this, but it seems people like their concatenating operator, so ++ seems a good choice (it has something of a precedent in Haskells list append operator). Those who oppose, start arguing. From pwalton at mozilla.com Wed Jan 25 12:12:07 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 25 Jan 2012 12:12:07 -0800 Subject: [rust-dev] A couple of tweaks to make typeclasses easier? Message-ID: <4F206217.4030309@mozilla.com> I've noticed a couple of usability issues with typeclasses: (1) There's no easy place to search in a file to find all the typeclass implementations presently in scope. (2) It's hard to see at a glance whether a dereference with '.' is a method call or whether it's a record field access. It's subtle when a record contains closures. (In fact, it can even be ambiguous in such cases...) As a couple of simple-to-implement tweaks, I'd like to suggest the following solutions: (1) Typeclass imports become "import impl". So you'd write "import impl driver::diagnostic::handler" where you'd write "import driver::diagnostic::handler" today. This way, when you look at a method call and you don't know where it's coming from, you just grep for "import impl" and look at all the implementations in scope. (2) Change method calls to '->', like C++, Perl, and PHP. That operator is free and it has precedent. And getting away from overloading the dot worked well when we changed module access from '.' to '::'. Thoughts? Patrick From pwalton at mozilla.com Wed Jan 25 12:13:05 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 25 Jan 2012 12:13:05 -0800 Subject: [rust-dev] Proposal: rename sequence concatenation operator to ++ In-Reply-To: References: Message-ID: <4F206251.3060000@mozilla.com> On 1/25/12 11:46 AM, Marijn Haverbeke wrote: > Currently it is simply '+'. > > The thing that prompted this is issue #1520 -- operator overloading. > Delegating + on non-builtin-numeric types to a `num` interface that > implements methods add/sub/mult/div/rem/neg methods seems elegant, and > similar to Haskell's approach. Vector-concatenation + messes > everything up though, since vectors can't meaningfully implement the > full num interface. What about an add interface? Patrick From marijnh at gmail.com Wed Jan 25 12:18:31 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Wed, 25 Jan 2012 21:18:31 +0100 Subject: [rust-dev] Proposal: rename sequence concatenation operator to ++ In-Reply-To: <4F206251.3060000@mozilla.com> References: <4F206251.3060000@mozilla.com> Message-ID: > What about an add interface? That works, but doesn't provide the conceptual simplicity of a number interface, and if you want to write a generic over any numeric type, it could end up taking a type parameter. From marijnh at gmail.com Wed Jan 25 12:21:48 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Wed, 25 Jan 2012 21:21:48 +0100 Subject: [rust-dev] A couple of tweaks to make typeclasses easier? In-Reply-To: <4F206217.4030309@mozilla.com> References: <4F206217.4030309@mozilla.com> Message-ID: > (1) Typeclass imports become "import impl". So you'd write "import impl > driver::diagnostic::handler" where you'd write "import > driver::diagnostic::handler" today. This way, when you look at a method call > and you don't know where it's coming from, you just grep for "import impl" > and look at all the implementations in scope. It can often be pleasant to have impls included in a * import (but then, it is also occasionally not what you want). Similarly, it is currently very convenient to name a type and an impl with the same name, so that importing it gets you both the type and its methods. Maybe we can somehow tweak the syntax to also allow a form that imports both impls and other things? > (2) Change method calls to '->', like C++, Perl, and PHP. That operator is > free and it has precedent. And getting away from overloading the dot worked > well when we changed module access from '.' to '::'. I considered this when I did the first implementation. I figured that simply giving record field access precedence was good enough, but the readability argument is valid. From alex at scienceforums.net Wed Jan 25 12:31:22 2012 From: alex at scienceforums.net (Alex R.) Date: Wed, 25 Jan 2012 14:31:22 -0600 Subject: [rust-dev] Proposal: rename sequence concatenation operator to ++ In-Reply-To: References: <4F206251.3060000@mozilla.com> Message-ID: <6D9D1410-0E76-4AF9-BE1A-772DE456F50A@scienceforums.net> There are cases in math or physics when the granularity is needed. For example, when implementing vectors (in the math or physics sense), it doesn't make sense to define a division operator, and what you mean by "multiplication" depends on if you mean dot product, cross product, or whatever. It'd be simplest to define addition and subtraction but require multiplication to use an explicit method call. Is it possible to define a Num interface which is the superset of interfaces for addition and multiplication, and use that when necessary? - Alex Reinhart On Jan 25, 2012, at 2:18 PM, Marijn Haverbeke wrote: >> What about an add interface? > > That works, but doesn't provide the conceptual simplicity of a number > interface, and if you want to write a generic over any numeric type, > it could end up taking a type parameter. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From graydon at mozilla.com Wed Jan 25 12:36:27 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Wed, 25 Jan 2012 12:36:27 -0800 Subject: [rust-dev] Cargo requirements In-Reply-To: References: Message-ID: <4F2067CB.6010309@mozilla.com> On 24/01/2012 12:24 PM, Thomas Leonard wrote: > Basically, I'd like to make a list of short-comings in existing > installation systems that cargo addresses (e.g. poor documentation, > too many dependencies, lack of robustness, poor security, etc). Summary version: too many concepts and moving parts. We kept degrees-of-freedom to a bare minimum with cargo, and there are still probably too many. We might well shave more. It's reasonable in 2012 for our compiler to support: use foo (url = "git://github.com/user/foo.git"); out of the box. We don't yet, but we may well do so and remove cargo altogether. Developer machines without revision control and internet connections in this day and age are curious paperweights. The number of degrees-of-freedom in 0install is much higher, as it's trying to solve many more problems (end-user distribution, multi-language, multi-transport, multi-vcs, source and executable, OS-packaging, sandboxing, etc.) The critical thing for us to minimize is the cognitive load of figuring out, as a developer, how to go from "my new libfoo is in a git repo somewhere" to "you can successfully compile 'use foo' in your application". The number of steps to achieve this in 0install is simply too high; the publisher has too much to figure out and the consumer does too. I have to read a number of web pages worth of docs and flow charts, and examine a number of XML fragments to try to figure which one I am supposed to edit (or create) to make things go. That's too much. Possibly, as I say, even having the installation-step *be* a separate tool is too much. Shaving down interaction-steps is really important. People don't have a lot of time to learn how new systems work. -Graydon From fw at deneb.enyo.de Wed Jan 25 12:39:12 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 25 Jan 2012 21:39:12 +0100 Subject: [rust-dev] Heads up: syntax change with nullary tags in patterns References: Message-ID: <87zkdba55b.fsf@mid.deneb.enyo.de> * Tim Chevalier: > To make this change possible, the typechecker now forbids local > variable names that shadow the name of a tag that's in scope. The "." was ugly, but doesn't this make the syntatic category of the token dependent on the contents of imported modules? I think this is problematic for IDEs which want to go a bit beyond lexical syntax highlighting. This change also breaks exhaustiveness checks to some degree. Here's an example: enum enum_type { a, b, c } fn repr(e: enum_type) -> str { alt e { a { "a" } b { "b" } c { "c" } } } We can remove the c variant from the enum_type definition, and the program still compiles (even though this smells like a bug). It keeps compiling if we add a d variant to enum_type. Flagging unused bound variables as error isn't a reliable countermeasure because the variant-now-variable might actually be used. From niko at alum.mit.edu Wed Jan 25 12:40:38 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 25 Jan 2012 12:40:38 -0800 Subject: [rust-dev] Heads up: syntax change with nullary tags in patterns In-Reply-To: <87zkdba55b.fsf@mid.deneb.enyo.de> References: <87zkdba55b.fsf@mid.deneb.enyo.de> Message-ID: <4F2068C6.5040701@alum.mit.edu> On 1/25/12 12:39 PM, Florian Weimer wrote: > The "." was ugly, but doesn't this make the syntatic category of the > token dependent on the contents of imported modules? I think this is > problematic for IDEs which want to go a bit beyond lexical syntax > highlighting. Yes, this was the counter argument. > We can remove the c variant from the enum_type definition, and the > program still compiles (even though this smells like a bug). It keeps > compiling if we add a d variant to enum_type. Flagging unused bound > variables as error isn't a reliable countermeasure because the > variant-now-variable might actually be used. This is because exhaustiveness checking is not implemented. Niko From arcata at gmail.com Wed Jan 25 12:42:19 2012 From: arcata at gmail.com (Joe Groff) Date: Wed, 25 Jan 2012 12:42:19 -0800 Subject: [rust-dev] Proposal: rename sequence concatenation operator to ++ In-Reply-To: References: <4F206251.3060000@mozilla.com> Message-ID: On Wed, Jan 25, 2012 at 12:18 PM, Marijn Haverbeke wrote: > That works, but doesn't provide the conceptual simplicity of a number > interface, and if you want to write a generic over any numeric type, > it could end up taking a type parameter. It might be foolish simplicity in this case. How hard/theoretically sound would it be to support iface multiple inheritance, so you can have your 'num' typeclass be a subclass of add, mul, sub, div? And how about separating the integer quotient from field division ifaces, since they're different operations, and a routine written for one likely won't work for the other? -Joe From fw at deneb.enyo.de Wed Jan 25 12:45:02 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 25 Jan 2012 21:45:02 +0100 Subject: [rust-dev] Heads up: syntax change with nullary tags in patterns In-Reply-To: <4F2068C6.5040701@alum.mit.edu> (Niko Matsakis's message of "Wed, 25 Jan 2012 12:40:38 -0800") References: <87zkdba55b.fsf@mid.deneb.enyo.de> <4F2068C6.5040701@alum.mit.edu> Message-ID: <87pqe7a4vl.fsf@mid.deneb.enyo.de> * Niko Matsakis: >> We can remove the c variant from the enum_type definition, and the >> program still compiles (even though this smells like a bug). It keeps >> compiling if we add a d variant to enum_type. Flagging unused bound >> variables as error isn't a reliable countermeasure because the >> variant-now-variable might actually be used. > > This is because exhaustiveness checking is not implemented. The last part also applies with exhaustiveness checking. You can reproduce this with Standard ML (which requires such checks and lacks a lexical destinction between datacons and binders, or whatever the technical terms are)" datatype enum_type = a | b | c (* or: d *) fun repr a = "a" | repr b = "b" | repr c = "c" Besides lexical distinction in one way or other, I'm not aware of a solution. From pwalton at mozilla.com Wed Jan 25 12:46:57 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 25 Jan 2012 12:46:57 -0800 Subject: [rust-dev] Heads up: syntax change with nullary tags in patterns In-Reply-To: <87zkdba55b.fsf@mid.deneb.enyo.de> References: <87zkdba55b.fsf@mid.deneb.enyo.de> Message-ID: <4F206A41.5030803@mozilla.com> On 1/25/12 12:39 PM, Florian Weimer wrote: > * Tim Chevalier: > >> To make this change possible, the typechecker now forbids local >> variable names that shadow the name of a tag that's in scope. > > The "." was ugly, but doesn't this make the syntatic category of the > token dependent on the contents of imported modules? I think this is > problematic for IDEs which want to go a bit beyond lexical syntax > highlighting. Depends on how you define syntactic categories. It just means that resolve has to disambiguate a bit. > > This change also breaks exhaustiveness checks to some degree. Here's > an example: > > enum enum_type { > a, b, c > } > > fn repr(e: enum_type) -> str { > alt e { > a { "a" } > b { "b" } > c { "c" } > } > } > > We can remove the c variant from the enum_type definition, and the > program still compiles (even though this smells like a bug). It keeps > compiling if we add a d variant to enum_type. Flagging unused bound > variables as error isn't a reliable countermeasure because the > variant-now-variable might actually be used. I see, this is a potential issue. Seems like a pretty rare case though, because you'd actually have to use the same tag variant inside the body. Again, I'd point to Standard ML here... SML has the same rule and I've never seen it result in this bug. Patrick From stefan.plantikow at googlemail.com Wed Jan 25 14:10:19 2012 From: stefan.plantikow at googlemail.com (Stefan Plantikow) Date: Wed, 25 Jan 2012 23:10:19 +0100 Subject: [rust-dev] A couple of tweaks to make typeclasses easier? In-Reply-To: <4F206217.4030309@mozilla.com> References: <4F206217.4030309@mozilla.com> Message-ID: <4A7CB099885F4A87861B1EA045F5414C@googlemail.com> Hi, Am Mittwoch, 25. Januar 2012 um 21:12 schrieb Patrick Walton: > I've noticed a couple of usability issues with typeclasses: > > (1) There's no easy place to search in a file to find all the typeclass > implementations presently in scope. > Hmm, maybe the compiler could help with that by having a simple macro which would print the list, or by having some flag which would emit it. > > (2) It's hard to see at a glance whether a dereference with '.' is a > method call or whether it's a record field access. It's subtle when a > record contains closures. (In fact, it can even be ambiguous in such > cases...) > I kind-of like it that way because it simplifies replacing record access with getter typeclass methods without too much refactoring. > (1) Typeclass imports become "import impl". So you'd write "import impl > driver::diagnostic::handler" where you'd write "import > driver::diagnostic::handler" today. This way, when you look at a method > call and you don't know where it's coming from, you just grep for > "import impl" and look at all the implementations in scope. > Maybe there is the need for an "import impl module::*" to get them all. And an "import all module::*". I would find it a tad annoying to need 2 import statements to import everything from a single module. > > (2) Change method calls to '->', like C++, Perl, and PHP. That operator > is free and it has precedent. And getting away from overloading the dot > worked well when we changed module access from '.' to '::'. > That may just be me but I always found that ugly and slow to type (on non-us keyboards at least) Stefan Plantikow From niko at alum.mit.edu Wed Jan 25 14:21:06 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 25 Jan 2012 14:21:06 -0800 Subject: [rust-dev] Heads up: syntax change with nullary tags in patterns In-Reply-To: <87pqe7a4vl.fsf@mid.deneb.enyo.de> References: <87zkdba55b.fsf@mid.deneb.enyo.de> <4F2068C6.5040701@alum.mit.edu> <87pqe7a4vl.fsf@mid.deneb.enyo.de> Message-ID: <4F208052.3040505@alum.mit.edu> On 1/25/12 12:45 PM, Florian Weimer wrote: > The last part also applies with exhaustiveness checking. You can > reproduce this with Standard ML (which requires such checks and lacks > a lexical destinction between datacons and binders, or whatever the > technical terms are)" Ah, sorry, I misunderstood what you were saying. You were pointing out that program evolution can lead to a bug. This is a good point that I personally had not considered. Niko From niko at alum.mit.edu Wed Jan 25 14:23:49 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 25 Jan 2012 14:23:49 -0800 Subject: [rust-dev] Proposal: rename sequence concatenation operator to ++ In-Reply-To: References: <4F206251.3060000@mozilla.com> Message-ID: <4F2080F5.8050401@alum.mit.edu> On 1/25/12 12:18 PM, Marijn Haverbeke wrote: > That works, but doesn't provide the conceptual simplicity of a number > interface, and if you want to write a generic over any numeric type, > it could end up taking a type parameter. It seems to me that if impls did not have to declare the interfaces which they implement (as I would prefer), then we could simply declare several interfaces (addable, divable, num) and things would just work. Some interfaces, like num, could be a superset of others. This would be an alternative to introducing subtyping into interfaces. Not that I'm opposed to that per se, but it's more than we need to solve this case. One situation which would be improved through some sort of inheritance: fn foo(x: A) { ... } fn bar(x: N) { foo(x); } This call ought to work, as num is a superset of add, but we'd need to construct a "derived vtable" of some sort which means that we'd get another layer of indirection at runtime. Kind of a drag. Niko From elly at leptoquark.net Wed Jan 25 12:38:39 2012 From: elly at leptoquark.net (Elly Jones) Date: Wed, 25 Jan 2012 14:38:39 -0600 Subject: [rust-dev] Cargo requirements In-Reply-To: <4F2067CB.6010309@mozilla.com> References: <4F2067CB.6010309@mozilla.com> Message-ID: <20120125203839.GG4517@leptoquark.net> On Wed, Jan 25, 2012 at 12:36:27PM -0800, Graydon Hoare wrote: > On 24/01/2012 12:24 PM, Thomas Leonard wrote: > > >Basically, I'd like to make a list of short-comings in existing > >installation systems that cargo addresses (e.g. poor documentation, > >too many dependencies, lack of robustness, poor security, etc). > > Summary version: too many concepts and moving parts. > > We kept degrees-of-freedom to a bare minimum with cargo, and there > are still probably too many. We might well shave more. It's > reasonable in 2012 for our compiler to support: > > use foo (url = "git://github.com/user/foo.git"); As an aside, Racket does this right now: (require (planet )) will fetch and install module locally, if need be. It's certainly doable. It's not even part of the compiler in racket, since the module system is extremely powerful. > out of the box. We don't yet, but we may well do so and remove cargo > altogether. Developer machines without revision control and internet > connections in this day and age are curious paperweights. > > The number of degrees-of-freedom in 0install is much higher, as it's > trying to solve many more problems (end-user distribution, > multi-language, multi-transport, multi-vcs, source and executable, > OS-packaging, sandboxing, etc.) > > The critical thing for us to minimize is the cognitive load of > figuring out, as a developer, how to go from "my new libfoo is in a > git repo somewhere" to "you can successfully compile 'use foo' in > your application". The number of steps to achieve this in 0install > is simply too high; the publisher has too much to figure out and the > consumer does too. I have to read a number of web pages worth of > docs and flow charts, and examine a number of XML fragments to try > to figure which one I am supposed to edit (or create) to make things > go. That's too much. > > Possibly, as I say, even having the installation-step *be* a > separate tool is too much. Shaving down interaction-steps is really > important. People don't have a lot of time to learn how new systems > work. > > -Graydon > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- elly -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From marijnh at gmail.com Thu Jan 26 00:21:17 2012 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 26 Jan 2012 09:21:17 +0100 Subject: [rust-dev] Proposal: rename sequence concatenation operator to ++ In-Reply-To: <4F2080F5.8050401@alum.mit.edu> References: <4F206251.3060000@mozilla.com> <4F2080F5.8050401@alum.mit.edu> Message-ID: You're right that the impls can be static, in which case interfaces don't enter into it. Also, method names can overlap in Rust (unlike in Haskell) without causing conflicts. So I guess this is not a direct issue. And yes, I do intend to implement support for super-interfaces, they seem to be useful in a lot of situations. Given all that, I'd still like to rename the vector append operator. I think it'd be an improvement in readability. From talex5 at gmail.com Thu Jan 26 00:36:09 2012 From: talex5 at gmail.com (Thomas Leonard) Date: Thu, 26 Jan 2012 08:36:09 +0000 Subject: [rust-dev] Cargo requirements In-Reply-To: References: <4F2067CB.6010309@mozilla.com> Message-ID: On 25 January 2012 20:36, Graydon Hoare wrote: > On 24/01/2012 12:24 PM, Thomas Leonard wrote: > >> Basically, I'd like to make a list of short-comings in existing >> installation systems that cargo addresses (e.g. poor documentation, >> too many dependencies, lack of robustness, poor security, etc). > > Summary version: too many concepts and moving parts. > > We kept degrees-of-freedom to a bare minimum with cargo, and there are still > probably too many. We might well shave more. It's reasonable in 2012 for our > compiler to support: > > ?use foo (url = "git://github.com/user/foo.git"); > > out of the box. We don't yet, but we may well do so and remove cargo > altogether. Developer machines without revision control and internet > connections in this day and age are curious paperweights. Thanks for the reply. Yes, simplicity is a big problem. Unfortunately, all package systems start simple and grow more complex over time :-( Embedding the URLs in the code is interesting. How do you see this working with versions? Would your example above build against the latest version on foo.git's master? That might make builds a bit unstable. Would rustc do a "git pull" on each dependency before building? How would I update my code if e.g. foo.git made a big API change on master? In the tutorial, I see you can specify versions. e.g. use foo (url = "git://github.com/user/foo.git", vers = "1.0"); That works if you don't have diamond dependencies (most systems seem to start this way). But then what if I have: use logging (url = "git://github.com/user/logging.git", vers = "1.12.3"); use foo (url = "git://github.com/user/foo.git", vers = "1.0"); and foo has: use logging (url = "git://github.com/user/logging.git", vers = "1.12.4"); (i.e. a conflict in the version of logging: 1.12.3 vs 1.12.4) Would it just pick one (like older versions of Maven did)? Or are you planning to support version ranges? e.g. use logging (url = "git://github.com/user/logging.git", ? ? ? ? ? ? ? ? ? ? not-before="1.12" before="1.13"); use foo (url = "git://github.com/user/foo.git", ? ? ? ? ? ? ?not-before = "1.0"); Then you could run a solver to select the best set of compatible versions. But, I don't see how you can do that if the dependencies are in the code. For example, if the latest foo depends on "logging >= 1.14" then you'd need to select an older version of foo. Would rustc check out successively older versions of foo.git, parsing the source in each, until it found a version that could use a version of the logger compatible with my program? > The number of degrees-of-freedom in 0install is much higher, as it's trying > to solve many more problems (end-user distribution, multi-language, > multi-transport, multi-vcs, source and executable, OS-packaging, sandboxing, > etc.) True. So if I understand correctly: - Rust will help developers to get the libraries/crates they need to build, but it's assumed that users already have the run-time libraries on their machines (or the developer bundles the library with their program). - When libraries have language-specific components (e.g. translations), the developer should bundle all translations of all libraries with their program, so select-by-locale is not needed. - Rust will only support Git (note: VCS support is not part of the core of 0install, but there is a tool called 0release which can automate the process of making a release from a Git repository). - Rust will only download source, not binaries. e.g. a Git checkout of a Rust program will not download rustc, make, etc. If my build uses e.g. sphinx and graphviz to build its documentation then developers should install those themselves. - Rust builds do not need to be sandboxed. > The critical thing for us to minimize is the cognitive load of figuring out, > as a developer, how to go from "my new libfoo is in a git repo somewhere" to > "you can successfully compile 'use foo' in your application". The number of > steps to achieve this in 0install is simply too high; the publisher has too > much to figure out and the consumer does too. True (normally, we don't expect people to depend on a library until it's been released). Once you have released your new libfoo 1.1, someone wanting to depend on the new features would update the XML file in their Git repository from: ? ? ? ? ? ? ? to ? ? ? ? ? ? ? > I have to read a number of web > pages worth of docs and flow charts, and examine a number of XML fragments > to try to figure which one I am supposed to edit (or create) to make things > go. That's too much. Yes. When adding a new language it's not obvious how to do it (and different languages do it differently). For example, for C programs depending on a library usually means adding a directory to PKG_CONFIG_PATH, but whether that would be right for Rust I don't know. If Rust is putting dependencies in the source code, then you can target it much more specifically, because you know which individual source files depend on which library. > Possibly, as I say, even having the installation-step *be* a separate tool > is too much. Shaving down interaction-steps is really important. People > don't have a lot of time to learn how new systems work. -- Dr Thomas Leonard? ? ? ? http://0install.net/ GPG: 9242 9807 C985 3C07 44A6? 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA? BD8E 0713 3F96 CA74 D8BA From me at kevincantu.org Thu Jan 26 01:03:49 2012 From: me at kevincantu.org (Kevin Cantu) Date: Thu, 26 Jan 2012 01:03:49 -0800 Subject: [rust-dev] Cargo requirements In-Reply-To: References: <4F2067CB.6010309@mozilla.com> Message-ID: If source control was the distribution method, things like git's submodules already do provide a way to precisely manage the versions of dependencies. There are probably some better ways, of course. For example, I think Scott Kilpatrick is working on a module language for Haskell: http://www.mpi-sws.org/~skilpat/ My impression is that Rust is just getting started. -- Kevin Cantu From graydon at mozilla.com Thu Jan 26 11:31:23 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 26 Jan 2012 11:31:23 -0800 Subject: [rust-dev] The Rust compiler 0.1 is unleashed In-Reply-To: <4F1C2030.6070202@mozilla.com> References: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> <5045f699-f14f-4e94-a8d1-d29e081f40a7@zimbra1.shared.sjc1.mozilla.com> <4F1C2030.6070202@mozilla.com> Message-ID: <4F21AA0B.2010705@mozilla.com> On 1/22/2012 6:41 AM, David Rajchenbach-Teller wrote: > As soon as I find some time (and if nobody has done it yet), I'll get > working on a Mac installer. What's the preferred strategy? Should the > Mac installer essentially contain the .tgz and build from source? Or do > we have a reference script that builds a package and that I should adapt > to Mac? I'm afraid I don't know enough about mac packaging standards to say. Try some things that seem like platform-standard ways of doing it and see what comes out? Nothing's really set in stone at this point; if you need slightly different make targets or distribution layouts or whatnot we can just add them. -Graydon From masklinn at masklinn.net Thu Jan 26 12:49:57 2012 From: masklinn at masklinn.net (Masklinn) Date: Thu, 26 Jan 2012 21:49:57 +0100 Subject: [rust-dev] The Rust compiler 0.1 is unleashed In-Reply-To: <4F21AA0B.2010705@mozilla.com> References: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> <5045f699-f14f-4e94-a8d1-d29e081f40a7@zimbra1.shared.sjc1.mozilla.com> <4F1C2030.6070202@mozilla.com> <4F21AA0B.2010705@mozilla.com> Message-ID: On 2012-01-26, at 20:31 , Graydon Hoare wrote: > On 1/22/2012 6:41 AM, David Rajchenbach-Teller wrote: > >> As soon as I find some time (and if nobody has done it yet), I'll get >> working on a Mac installer. What's the preferred strategy? Should the >> Mac installer essentially contain the .tgz and build from source? Or do >> we have a reference script that builds a package and that I should adapt >> to Mac? > > I'm afraid I don't know enough about mac packaging standards to say. The two ways I know of are: 1. a .pkg of the (compiled) binaries putting everything at the right place, ? la Haskell Platform[0] or PythonMac[1] (I don't think a pkg spending an hour or two compiling stuff would be a great idea) 2. and/or adding it to one or all (third-party) package managers [2][3][4] [0] http://hackage.haskell.org/platform/mac.html [1] warning, direct link to installer http://python.org/ftp/python/2.7.2/python-2.7.2-macosx10.6.dmg [2] source-based Macports http://www.macports.org/ [3] source-based Homebrew http://mxcl.github.com/homebrew/ [4] binary-based Fink http://finkproject.org/ From graydon at mozilla.com Thu Jan 26 17:38:28 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 26 Jan 2012 17:38:28 -0800 Subject: [rust-dev] A couple of tweaks to make typeclasses easier? In-Reply-To: <4F206217.4030309@mozilla.com> References: <4F206217.4030309@mozilla.com> Message-ID: <4F220014.7070107@mozilla.com> On 1/25/2012 12:12 PM, Patrick Walton wrote: > (1) Typeclass imports become "import impl". So you'd write "import impl > driver::diagnostic::handler" where you'd write "import > driver::diagnostic::handler" today. This way, when you look at a method > call and you don't know where it's coming from, you just grep for > "import impl" and look at all the implementations in scope. > > (2) Change method calls to '->', like C++, Perl, and PHP. That operator > is free and it has precedent. And getting away from overloading the dot > worked well when we changed module access from '.' to '::'. > > Thoughts? A bit opposed to both, sadly. I quite like picking up impls "by accident" via "import foo::*", and dislike the aesthetic of ->. Is the ambiguity between field-access and method-call really biting in actual cases? Users really seem to adore '.' as a sub-component accessor. We even have people wanting us to go back to '.' for module-separator :) -Graydon From pwalton at mozilla.com Thu Jan 26 17:41:44 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Thu, 26 Jan 2012 17:41:44 -0800 Subject: [rust-dev] A couple of tweaks to make typeclasses easier? In-Reply-To: <4F220014.7070107@mozilla.com> References: <4F206217.4030309@mozilla.com> <4F220014.7070107@mozilla.com> Message-ID: <4F2200D8.6050804@mozilla.com> On 1/26/12 5:38 PM, Graydon Hoare wrote: > On 1/25/2012 12:12 PM, Patrick Walton wrote: > >> (1) Typeclass imports become "import impl". So you'd write "import impl >> driver::diagnostic::handler" where you'd write "import >> driver::diagnostic::handler" today. This way, when you look at a method >> call and you don't know where it's coming from, you just grep for >> "import impl" and look at all the implementations in scope. >> >> (2) Change method calls to '->', like C++, Perl, and PHP. That operator >> is free and it has precedent. And getting away from overloading the dot >> worked well when we changed module access from '.' to '::'. >> >> Thoughts? > > A bit opposed to both, sadly. I quite like picking up impls "by > accident" via "import foo::*", and dislike the aesthetic of ->. Is "import impl foo::*" bad? > Is the ambiguity between field-access and method-call really biting in > actual cases? Users really seem to adore '.' as a sub-component > accessor. We even have people wanting us to go back to '.' for > module-separator :) Yes, I found it very confusing yesterday, when trying to figure out "." with a closure. It's also screwing up our error messages. Patrick From graydon at mozilla.com Thu Jan 26 18:10:57 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Thu, 26 Jan 2012 18:10:57 -0800 Subject: [rust-dev] A couple of tweaks to make typeclasses easier? In-Reply-To: <4F2200D8.6050804@mozilla.com> References: <4F206217.4030309@mozilla.com> <4F220014.7070107@mozilla.com> <4F2200D8.6050804@mozilla.com> Message-ID: <4F2207B1.1060505@mozilla.com> On 1/26/2012 5:41 PM, Patrick Walton wrote: >> A bit opposed to both, sadly. I quite like picking up impls "by >> accident" via "import foo::*", and dislike the aesthetic of ->. > > Is "import impl foo::*" bad? Depends what it means! Does it pull in the same stuff that "import foo::*" pulls in, in addition to impls? Or just impls? IWO, do I have to double the number of boilerplate lines to get access to foo-and-its-methods? >> Is the ambiguity between field-access and method-call really biting in >> actual cases? Users really seem to adore '.' as a sub-component >> accessor. We even have people wanting us to go back to '.' for >> module-separator :) > > Yes, I found it very confusing yesterday, when trying to figure out "." > with a closure. It's also screwing up our error messages. What was the error message? I'm not trying to be a pain, just concerned that a proliferation of -> symbols through much of our code will read poorly, and want to try to avoid. -Graydon From kevin at atkinson.dhs.org Thu Jan 26 18:35:40 2012 From: kevin at atkinson.dhs.org (Kevin Atkinson) Date: Thu, 26 Jan 2012 19:35:40 -0700 (MST) Subject: [rust-dev] A couple of tweaks to make typeclasses easier? In-Reply-To: <4F220014.7070107@mozilla.com> References: <4F206217.4030309@mozilla.com> <4F220014.7070107@mozilla.com> Message-ID: On Thu, 26 Jan 2012, Graydon Hoare wrote: > On 1/25/2012 12:12 PM, Patrick Walton wrote: > >> (1) Typeclass imports become "import impl". So you'd write "import impl >> driver::diagnostic::handler" where you'd write "import >> driver::diagnostic::handler" today. This way, when you look at a method >> call and you don't know where it's coming from, you just grep for >> "import impl" and look at all the implementations in scope. >> >> (2) Change method calls to '->', like C++, Perl, and PHP. That operator >> is free and it has precedent. And getting away from overloading the dot >> worked well when we changed module access from '.' to '::'. >> >> Thoughts? > > A bit opposed to both, sadly. I quite like picking up impls "by accident" via > "import foo::*", and dislike the aesthetic of ->. As a potential user of the language, I have to agree with Graydon. In particular I do not like the idea of having to use a different symbol for what I see as method access and field access. From pwalton at mozilla.com Thu Jan 26 18:44:04 2012 From: pwalton at mozilla.com (Patrick Walton) Date: Thu, 26 Jan 2012 18:44:04 -0800 Subject: [rust-dev] A couple of tweaks to make typeclasses easier? In-Reply-To: References: <4F206217.4030309@mozilla.com> <4F220014.7070107@mozilla.com> Message-ID: <4F220F74.3050803@mozilla.com> On 1/26/12 6:35 PM, Kevin Atkinson wrote: > As a potential user of the language, I have to agree with Graydon. In > particular I do not like the idea of having to use a different symbol > for what I see as method access and field access. Ok, let's not do it then. Patrick From niko at alum.mit.edu Thu Jan 26 20:27:36 2012 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 26 Jan 2012 20:27:36 -0800 Subject: [rust-dev] A couple of tweaks to make typeclasses easier? In-Reply-To: <4F2207B1.1060505@mozilla.com> References: <4F206217.4030309@mozilla.com> <4F220014.7070107@mozilla.com> <4F2200D8.6050804@mozilla.com> <4F2207B1.1060505@mozilla.com> Message-ID: <4F2227B8.8020608@alum.mit.edu> On 1/26/12 6:10 PM, Graydon Hoare wrote: > Depends what it means! Does it pull in the same stuff that "import > foo::*" pulls in, in addition to impls? Or just impls? IWO, do I have > to double the number of boilerplate lines to get access to > foo-and-its-methods? One thing: I think a lot of the uses of record type + impl in our code base might be better phrased as classes. This would obviate the need to pull in an implementation for type "foo" most of the time. It does strike me as somewhat non-obvious where methods are coming from today, particularly when "foo::*" is used. > What was the error message? I'm not trying to be a pain, just > concerned that a proliferation of -> symbols through much of our code > will read poorly, and want to try to avoid. The error message in question says something like "no method implementation found", even in cases where there is clearly no method call. It ought to be changed, probably to something like "no field or method found". As for "." vs "->", I don't have a very strong opinion. I somewhat like that fields and methods would be in disjoint namespaces, but I can also see a counter argument that "->" is not as pretty. Niko From dteller at mozilla.com Fri Jan 27 07:58:03 2012 From: dteller at mozilla.com (David Rajchenbach-Teller) Date: Fri, 27 Jan 2012 16:58:03 +0100 Subject: [rust-dev] The Rust compiler 0.1 is unleashed In-Reply-To: References: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> <5045f699-f14f-4e94-a8d1-d29e081f40a7@zimbra1.shared.sjc1.mozilla.com> <4F1C2030.6070202@mozilla.com> <4F21AA0B.2010705@mozilla.com> Message-ID: <4F22C98B.9050208@mozilla.com> On 1/26/12 9:49 PM, Masklinn wrote: > On 2012-01-26, at 20:31 , Graydon Hoare wrote: >> On 1/22/2012 6:41 AM, David Rajchenbach-Teller wrote: >> >>> As soon as I find some time (and if nobody has done it yet), I'll get >>> working on a Mac installer. What's the preferred strategy? Should the >>> Mac installer essentially contain the .tgz and build from source? Or do >>> we have a reference script that builds a package and that I should adapt >>> to Mac? >> >> I'm afraid I don't know enough about mac packaging standards to say. > > The two ways I know of are: > > 1. a .pkg of the (compiled) binaries putting everything at the right place, ? la Haskell Platform[0] or PythonMac[1] (I don't think a pkg spending an hour or two compiling stuff would be a great idea) > 2. and/or adding it to one or all (third-party) package managers [2][3][4] > > [0] http://hackage.haskell.org/platform/mac.html > [1] warning, direct link to installer http://python.org/ftp/python/2.7.2/python-2.7.2-macosx10.6.dmg > [2] source-based Macports http://www.macports.org/ > [3] source-based Homebrew http://mxcl.github.com/homebrew/ > [4] binary-based Fink http://finkproject.org/ Yes, and I have produced .pkg installers for other projects. At the moment, I am just looking for information regarding which files I need to install on the user's computer. For instance, should I provide our version of llvm? Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: OpenPGP digital signature URL: From graydon at mozilla.com Fri Jan 27 09:28:33 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Fri, 27 Jan 2012 09:28:33 -0800 Subject: [rust-dev] The Rust compiler 0.1 is unleashed In-Reply-To: <4F22C98B.9050208@mozilla.com> References: <5ddc4ec0-d731-49e2-b967-6cc710835aa9@zimbra1.shared.sjc1.mozilla.com> <5045f699-f14f-4e94-a8d1-d29e081f40a7@zimbra1.shared.sjc1.mozilla.com> <4F1C2030.6070202@mozilla.com> <4F21AA0B.2010705@mozilla.com> <4F22C98B.9050208@mozilla.com> Message-ID: <4F22DEC1.3010506@mozilla.com> On 1/27/2012 7:58 AM, David Rajchenbach-Teller wrote: > Yes, and I have produced .pkg installers for other projects. At the > moment, I am just looking for information regarding which files I need > to install on the user's computer. For instance, should I provide our > version of llvm? Sadly, yes. LLVM itself is still quite a moving target and we keep requiring minor adjustments to it. I believe we're on trunk again now, but the odds that the user has a version that's up-to-date with the rev we're tracking are slim. In terms of files-to-include, you will not go wrong with the files that are copied to --prefix when you do "make install". -Graydon From banderson at mozilla.com Sat Jan 28 16:02:27 2012 From: banderson at mozilla.com (Brian Anderson) Date: Sat, 28 Jan 2012 16:02:27 -0800 (PST) Subject: [rust-dev] First thoughts on Rust In-Reply-To: <0FCDF40F-5957-42EE-8F93-8FC92DDE8900@masklinn.net> Message-ID: ----- Original Message ----- > From: "Masklinn" > To: "Brian Anderson" > Cc: rust-dev at mozilla.org > Sent: Monday, January 23, 2012 2:58:10 AM > Subject: Re: [rust-dev] First thoughts on Rust > > >> * I find strange that Rust has kept the ternary operator even > >> though > >> its conditionals are expressions of their own. > > > > At one point there was some desire to be able to write if-else > > expressions more compactly and it was trivial to add to the > > language. > > I can see that. On the other hand, I will quote Tony Hoare on > trivial-to-add features: > > > I couldn't resist the temptation to put in a null reference, simply > > because it was so easy to implement. This comment has moved me, therefore I have filed a bug to remove ternary: https://github.com/mozilla/rust/issues/1698 We'll see where it goes. Regards, Brian From fmartini at gmail.com Sun Jan 29 08:25:57 2012 From: fmartini at gmail.com (Felix Martini) Date: Sun, 29 Jan 2012 17:25:57 +0100 Subject: [rust-dev] Extending records Message-ID: Hi all, Is it possible to extend record types with new fields in Rust without indirection? Say i have a ? ?type point2d = {x: int, y: int}; and i'd like to create a new record type the addition of field z ? ?type point3d = ?{x: int, y: int, z: int} I would like to write something like ? ?type point3d = {type point2d, z: int} because with records that contain many fields it will become annoying to write down all fields when defining a new record type with additional fields. Related is the record update syntax. Currently you can create new records that have the same type as the existing record ? ?let oldpoint = {x: 10, y: 20}; ? ?let newpoint = {x: 30 with oldpoint}; Say i have a record that functions as a prototype for other records. ? ?let person = {first_name: "John", last_name: "Doe"}; It would be nice to be able to create an extended record like this ? ?let patient: {memory_loss: true with person}; The new fields in the record expression would then be added after the existing fields of the prototype record resulting in record type ? ?{first_name: str, last_name: str, memory_loss: bool} From anderslindgaard at yahoo.com Sun Jan 29 17:12:43 2012 From: anderslindgaard at yahoo.com (Anders Lind) Date: Sun, 29 Jan 2012 17:12:43 -0800 (PST) Subject: [rust-dev] cannot build compiler on Mac OSX 10.6.8 Message-ID: <1327885963.72130.YahooMailNeo@web121403.mail.ne1.yahoo.com> got download with ok hash opening snapshot dl/rust-stage0-2012-01-18-8c97854-macos-x86_64-e6879151e8b18ced016c8766142edb0189c53c73.tar.bz2 extracting rust-stage0/bin/rustc extracting rust-stage0/lib/libcore-14bd852465126fe7-0.1.dylib extracting rust-stage0/lib/libstd-79ca5fac56b63fde-0.1.dylib extracting rust-stage0/lib/librustc-4171d83aef249987-0.1.dylib extracting rust-stage0/lib/librustrt.dylib extracting rust-stage0/lib/librustllvm.dylib compile: rt/x86_64-apple-darwin/sync/timer.o cc1plus: error: unrecognized command line option ?-arch? make: *** [rt/x86_64-apple-darwin/sync/timer.o] Error 1 Can anybody give a help? thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From catamorphism at gmail.com Sun Jan 29 17:14:08 2012 From: catamorphism at gmail.com (Tim Chevalier) Date: Sun, 29 Jan 2012 17:14:08 -0800 Subject: [rust-dev] cannot build compiler on Mac OSX 10.6.8 In-Reply-To: <1327885963.72130.YahooMailNeo@web121403.mail.ne1.yahoo.com> References: <1327885963.72130.YahooMailNeo@web121403.mail.ne1.yahoo.com> Message-ID: On Sun, Jan 29, 2012 at 5:12 PM, Anders Lind wrote: > got download with ok hash > opening snapshot > dl/rust-stage0-2012-01-18-8c97854-macos-x86_64-e6879151e8b18ced016c8766142edb0189c53c73.tar.bz2 > extracting rust-stage0/bin/rustc > extracting rust-stage0/lib/libcore-14bd852465126fe7-0.1.dylib > extracting rust-stage0/lib/libstd-79ca5fac56b63fde-0.1.dylib > extracting rust-stage0/lib/librustc-4171d83aef249987-0.1.dylib > extracting rust-stage0/lib/librustrt.dylib > extracting rust-stage0/lib/librustllvm.dylib > compile: rt/x86_64-apple-darwin/sync/timer.o > cc1plus: error: unrecognized command line option ?-arch? > make: *** [rt/x86_64-apple-darwin/sync/timer.o] Error 1 Can you recompile by doing "VERBOSE=1 make" and then post the output? Thanks, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt ?I cannot hide my anger to spare you guilt, nor hurt feelings, nor answering anger; for to do so insults and trivializes all our efforts. Guilt is not a response to anger; it is a response to one?s own actions or lack of action.? -- Audre Lorde From anderslindgaard at yahoo.com Sun Jan 29 17:18:26 2012 From: anderslindgaard at yahoo.com (Anders Lind) Date: Sun, 29 Jan 2012 17:18:26 -0800 (PST) Subject: [rust-dev] cannot build compiler on Mac OSX 10.6.8 In-Reply-To: References: <1327885963.72130.YahooMailNeo@web121403.mail.ne1.yahoo.com> Message-ID: <1327886306.84356.YahooMailNeo@web121403.mail.ne1.yahoo.com> anders at Macbook-Pro~/Downloads/rust$ VERBOSE=1 make make: *** No targets specified and no makefile found. ?Stop. anders at Macbook-Pro~/Downloads/rust$ cd build/ anders at Macbook-Pro~/Downloads/rust/build$ VERBOSE=1 make cfg: shell host triple x86_64-apple-darwin cfg: non host triples? cfg: host for x86_64-apple-darwin is x86_64 cfg: unix-y environment cfg: using gcc cfg: no pandoc found, omitting doc/rust.pdf cfg: no llnextgen found, omitting grammar-verification cfg: no naturaldocs found, omitting library doc build g++ -DNVALGRIND -O2 -Wall -Werror -fno-rtti -g -m64 -arch x86_64 ? -c -o ?rt/x86_64-apple-darwin/sync/timer.o ?-I ../src/rt -I ../src/rt/isaac -I ../src/rt/uthash -I ../src/rt/arch/x86_64 -I ../src/libuv/include ../src/rt/sync/timer.cpp cc1plus: error: unrecognized command line option ?-arch? make: *** [rt/x86_64-apple-darwin/sync/timer.o] Error 1 ________________________________ From: Tim Chevalier To: Anders Lind Cc: rust-dev at mozilla.org Sent: Sunday, January 29, 2012 5:14 PM Subject: Re: [rust-dev] cannot build compiler on Mac OSX 10.6.8 On Sun, Jan 29, 2012 at 5:12 PM, Anders Lind wrote: > got download with ok hash > opening snapshot > dl/rust-stage0-2012-01-18-8c97854-macos-x86_64-e6879151e8b18ced016c8766142edb0189c53c73.tar.bz2 > extracting rust-stage0/bin/rustc > extracting rust-stage0/lib/libcore-14bd852465126fe7-0.1.dylib > extracting rust-stage0/lib/libstd-79ca5fac56b63fde-0.1.dylib > extracting rust-stage0/lib/librustc-4171d83aef249987-0.1.dylib > extracting rust-stage0/lib/librustrt.dylib > extracting rust-stage0/lib/librustllvm.dylib > compile: rt/x86_64-apple-darwin/sync/timer.o > cc1plus: error: unrecognized command line option ?-arch? > make: *** [rt/x86_64-apple-darwin/sync/timer.o] Error 1 Can you recompile by doing "VERBOSE=1 make" and then post the output? Thanks, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt ?I cannot hide my anger to spare you guilt, nor hurt feelings, nor answering anger; for to do so insults and trivializes all our efforts. Guilt is not a response to anger; it is a response to one?s own actions or lack of action.? -- Audre Lorde -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at bnoordhuis.nl Sun Jan 29 17:31:36 2012 From: info at bnoordhuis.nl (Ben Noordhuis) Date: Mon, 30 Jan 2012 02:31:36 +0100 Subject: [rust-dev] cannot build compiler on Mac OSX 10.6.8 In-Reply-To: <1327886306.84356.YahooMailNeo@web121403.mail.ne1.yahoo.com> References: <1327885963.72130.YahooMailNeo@web121403.mail.ne1.yahoo.com> <1327886306.84356.YahooMailNeo@web121403.mail.ne1.yahoo.com> Message-ID: On Mon, Jan 30, 2012 at 02:18, Anders Lind wrote: > anders at Macbook-Pro~/Downloads/rust$ VERBOSE=1 make > make: *** No targets specified and no makefile found. ?Stop. > anders at Macbook-Pro~/Downloads/rust$ cd build/ > anders at Macbook-Pro~/Downloads/rust/build$ VERBOSE=1 make > cfg: shell host triple x86_64-apple-darwin > cfg: non host triples > cfg: host for x86_64-apple-darwin is x86_64 > cfg: unix-y environment > cfg: using gcc > cfg: no pandoc found, omitting doc/rust.pdf > cfg: no llnextgen found, omitting grammar-verification > cfg: no naturaldocs found, omitting library doc build > g++ -DNVALGRIND -O2 -Wall -Werror -fno-rtti -g -m64 -arch x86_64 ? -c -o > ?rt/x86_64-apple-darwin/sync/timer.o ?-I ../src/rt -I ../src/rt/isaac -I > ../src/rt/uthash -I ../src/rt/arch/x86_64 -I ../src/libuv/include > ../src/rt/sync/timer.cpp > cc1plus: error: unrecognized command line option ?-arch? > make: *** [rt/x86_64-apple-darwin/sync/timer.o] Error 1 That's a bug in / shortcoming of the gcc from MacPorts, at least some versions of it. Try the gcc that comes with XCode. From anderslindgaard at yahoo.com Sun Jan 29 17:40:51 2012 From: anderslindgaard at yahoo.com (Anders Lind) Date: Sun, 29 Jan 2012 17:40:51 -0800 (PST) Subject: [rust-dev] cannot build compiler on Mac OSX 10.6.8 In-Reply-To: References: <1327885963.72130.YahooMailNeo@web121403.mail.ne1.yahoo.com> <1327886306.84356.YahooMailNeo@web121403.mail.ne1.yahoo.com> Message-ID: <1327887651.75741.YahooMailNeo@web121404.mail.ne1.yahoo.com> Thank you Ben. But how can I specify which gcc I want to use? Thank you. ________________________________ From: Ben Noordhuis To: Anders Lind Cc: Tim Chevalier ; "rust-dev at mozilla.org" Sent: Sunday, January 29, 2012 5:31 PM Subject: Re: [rust-dev] cannot build compiler on Mac OSX 10.6.8 On Mon, Jan 30, 2012 at 02:18, Anders Lind wrote: > anders at Macbook-Pro~/Downloads/rust$ VERBOSE=1 make > make: *** No targets specified and no makefile found. ?Stop. > anders at Macbook-Pro~/Downloads/rust$ cd build/ > anders at Macbook-Pro~/Downloads/rust/build$ VERBOSE=1 make > cfg: shell host triple x86_64-apple-darwin > cfg: non host triples > cfg: host for x86_64-apple-darwin is x86_64 > cfg: unix-y environment > cfg: using gcc > cfg: no pandoc found, omitting doc/rust.pdf > cfg: no llnextgen found, omitting grammar-verification > cfg: no naturaldocs found, omitting library doc build > g++ -DNVALGRIND -O2 -Wall -Werror -fno-rtti -g -m64 -arch x86_64 ? -c -o > ?rt/x86_64-apple-darwin/sync/timer.o ?-I ../src/rt -I ../src/rt/isaac -I > ../src/rt/uthash -I ../src/rt/arch/x86_64 -I ../src/libuv/include > ../src/rt/sync/timer.cpp > cc1plus: error: unrecognized command line option ?-arch? > make: *** [rt/x86_64-apple-darwin/sync/timer.o] Error 1 That's a bug in / shortcoming of the gcc from MacPorts, at least some versions of it. Try the gcc that comes with XCode. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at bnoordhuis.nl Sun Jan 29 18:19:53 2012 From: info at bnoordhuis.nl (Ben Noordhuis) Date: Mon, 30 Jan 2012 03:19:53 +0100 Subject: [rust-dev] cannot build compiler on Mac OSX 10.6.8 In-Reply-To: <1327887651.75741.YahooMailNeo@web121404.mail.ne1.yahoo.com> References: <1327885963.72130.YahooMailNeo@web121403.mail.ne1.yahoo.com> <1327886306.84356.YahooMailNeo@web121403.mail.ne1.yahoo.com> <1327887651.75741.YahooMailNeo@web121404.mail.ne1.yahoo.com> Message-ID: On Mon, Jan 30, 2012 at 02:40, Anders Lind wrote: > Thank you Ben. But how can I specify which gcc I want to use? Thank you. `make CC=/path/to/gcc CXX=/path/to/g++` should work, I think. From banderson at mozilla.com Sun Jan 29 19:25:43 2012 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 29 Jan 2012 19:25:43 -0800 (PST) Subject: [rust-dev] cannot build compiler on Mac OSX 10.6.8 In-Reply-To: Message-ID: <1180626659.90218.1327893943898.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > From: "Ben Noordhuis" > To: "Anders Lind" > Cc: rust-dev at mozilla.org > Sent: Sunday, January 29, 2012 6:19:53 PM > Subject: Re: [rust-dev] cannot build compiler on Mac OSX 10.6.8 > > On Mon, Jan 30, 2012 at 02:40, Anders Lind > wrote: > > Thank you Ben. But how can I specify which gcc I want to use? Thank > > you. > > `make CC=/path/to/gcc CXX=/path/to/g++` should work, I think. I think this will likely not work with our build system, sadly. We have gcc and/or clang hardcoded. Adjusting the PATH variable to make the working gcc come first should work. Probably we should fix our makefiles to respect CC and CXX. From anderslindgaard at yahoo.com Sun Jan 29 19:37:08 2012 From: anderslindgaard at yahoo.com (Anders Lind) Date: Sun, 29 Jan 2012 19:37:08 -0800 (PST) Subject: [rust-dev] cannot build compiler on Mac OSX 10.6.8 In-Reply-To: <1180626659.90218.1327893943898.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1180626659.90218.1327893943898.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <1327894628.12408.YahooMailNeo@web121403.mail.ne1.yahoo.com> Yes, I think you are right Brian. I just tried gcc 4.2. I got the same error. Not sure what's going on. ________________________________ From: Brian Anderson To: Ben Noordhuis Cc: rust-dev at mozilla.org; Anders Lind Sent: Sunday, January 29, 2012 7:25 PM Subject: Re: [rust-dev] cannot build compiler on Mac OSX 10.6.8 ----- Original Message ----- > From: "Ben Noordhuis" > To: "Anders Lind" > Cc: rust-dev at mozilla.org > Sent: Sunday, January 29, 2012 6:19:53 PM > Subject: Re: [rust-dev] cannot build compiler on Mac OSX 10.6.8 > > On Mon, Jan 30, 2012 at 02:40, Anders Lind > wrote: > > Thank you Ben. But how can I specify which gcc I want to use? Thank > > you. > > `make CC=/path/to/gcc CXX=/path/to/g++` should work, I think. I think this will likely not work with our build system, sadly. We have gcc and/or clang hardcoded. Adjusting the PATH variable to make the working gcc come first should work. Probably we should fix our makefiles to respect CC and CXX. -------------- next part -------------- An HTML attachment was scrubbed... URL: From echristo at gmail.com Sun Jan 29 22:44:58 2012 From: echristo at gmail.com (Eric Christopher) Date: Sun, 29 Jan 2012 22:44:58 -0800 Subject: [rust-dev] cannot build compiler on Mac OSX 10.6.8 In-Reply-To: <1327894628.12408.YahooMailNeo@web121403.mail.ne1.yahoo.com> References: <1180626659.90218.1327893943898.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1327894628.12408.YahooMailNeo@web121403.mail.ne1.yahoo.com> Message-ID: On Sun, Jan 29, 2012 at 7:37 PM, Anders Lind wrote: > Yes, I think you are right Brian. I just tried gcc 4.2. I got the same > error. > Not sure what's going on. > > Public gcc doesn't have the -arch option, you'll really want to use the one out of Xcode. -eric From graydon at mozilla.com Mon Jan 30 16:22:54 2012 From: graydon at mozilla.com (Graydon Hoare) Date: Mon, 30 Jan 2012 16:22:54 -0800 Subject: [rust-dev] Cargo requirements In-Reply-To: References: <4F2067CB.6010309@mozilla.com> Message-ID: <4F27345E.1040101@mozilla.com> On 1/26/2012 12:36 AM, Thomas Leonard wrote: > Thanks for the reply. > > Yes, simplicity is a big problem. Unfortunately, all package systems start > simple and grow more complex over time :-( All systems of any sort start simple and grow more complex, yes. But one sometimes "starts new" to see what level of complexity is legacy and can be safely discarded. We live in a world with pervasive distributed version control now. We didn't used to. > Embedding the URLs in the code is interesting. How do you see this > working with versions? Would your example above build against the > latest version on foo.git's master? By relating to tags stored in foo.git, probably. > That works if you don't have diamond dependencies (most systems seem > to start this way). But then what if I have: No, we very specifically built the versioning scheme in our crates to permit loading and using multiple versions of a library in the same binary (with a deterministic, acyclic dependency graph). IOW the "diamond" doesn't have a join point unless they're metadata-equivalent versions. This is baked into rust's library name-mangling scheme. > use logging (url = "git://github.com/user/logging.git", vers = "1.12.3"); > use foo (url = "git://github.com/user/foo.git", vers = "1.0"); > > and foo has: > > use logging (url = "git://github.com/user/logging.git", vers = "1.12.4"); You wind up with two copies of logging in your process, and they don't conflict because all their names are version-qualified and there are no singletons or global (unless you do unsafe things; don't do that). This is what we built already. > - Rust will help developers to get the libraries/crates they need to > build, but it's assumed that users already have the run-time libraries > on their machines (or the developer bundles the library with their > program). One or the other, yes. Use of a package manager that does anything other than self-contained blobs is actually the minority case for end-user software these days. I know the linux ecosystem makes it seem otherwise, but it's a minority case. Of course, we don't intend to *prevent* people from using package-managers to package up rust crates either. And if they can handle multiple library-version side-by-side installs (say, apt or whatever) then more power to them. > - When libraries have language-specific components (e.g. > translations), the developer should bundle all translations of all > libraries with their program, so select-by-locale is not needed. Some package managers understand system-level locales. For those cases, devs will likely try to integrate with the locale system on their OS. Others don't, and you have to just ship multiple downloads, like so: http://www.mozilla.org/en-US/firefox/all.html > - Rust will only support Git (note: VCS support is not part of the > core of 0install, but there is a tool called 0release which can > automate the process of making a release from a Git repository). We'll start with git and grow others as needed. If we need any. > - Rust will only download source, not binaries. e.g. a Git checkout of > a Rust program will not download rustc, make, etc. If my build uses > e.g. sphinx and graphviz to build its documentation then developers > should install those themselves. More or less. We're ok having an event horizon beyond which the rust compiler or cargo can't (and doesn't try to) manage "the world" around it. It probes, tries its best, and complains if it fails. This is, to some extent, always going to be true. For any tool. You have a threshold beyond which 0install doesn't try to manage your target system either. It can't do everything. We're just doing less. Which, for a young language, is actually good. It makes our devs more likely to do *some* automated code-sharing, by keeping the activation energy of using-the-automation low. Appropriately low for the ambitions involved. A lot of people are still writing hello world with rust. > Yes. When adding a new language it's not obvious how to do it (and > different languages do it differently). For example, for C programs > depending on a library usually means adding a directory to > PKG_CONFIG_PATH, but whether that would be right for Rust I don't > know. If Rust is putting dependencies in the source code, then you can > target it much more specifically, because you know which individual > source files depend on which library. Yes. We baked metadata, version linkage specification and management machinery into the language, to some extent, to mitigate this misery. I mean, Rust is already rare in that it: - specifies a unit of compilation, versioning and linkage - requires names to be scoped within such units, never global - requires that such units form an acyclic dependency graph This is all intentional. We've seen the disastrous results of trying to manage deployments of C/C++ and java programs in the wild under ad-hoc linkage, distribution and dependency regimes. C# / CLR did a bit better. We're hoping to do better still, but we'll see. It's very delicate. I don't pretend to have "solved" all these problems, I just don't feel like adopting 0install (or any other system I've seen) is likely to help solve it any more than it is likely to drive people away by the feel of overengineering, adding extra moving parts. The moving parts we added to the language had to be *very* minimal to pass the developer sniff test. We're probably *still* going to get push-back from people who see the optional (disambiguating) UUIDs in our crate metadata and start having flashbacks to XPCOM. -Graydon From catamorphism at gmail.com Tue Jan 31 10:11:57 2012 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue, 31 Jan 2012 10:11:57 -0800 Subject: [rust-dev] Heads up: alt expressions must now be exhaustive Message-ID: Hi, I've just committed a change that requires alt expressions in Rust to be exhaustive. The change only applies to alts on expressions of type enum, where the patterns are either irrefutable patterns or constructor patterns. So for example: enum foo { a, b } ... let x:foo = ...; alt x { a { ...} } will no longer compile. If you write a non-exhaustive alt (on an enum-typed expression) that the compiler accepts, that's a bug, so please report it. Some languages (e.g. Haskell) make this a warning rather than an error, but after discussion, the Rust team has decided to make it an error. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt ?I cannot hide my anger to spare you guilt, nor hurt feelings, nor answering anger; for to do so insults and trivializes all our efforts. Guilt is not a response to anger; it is a response to one?s own actions or lack of action.? -- Audre Lorde