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. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
