[rust-dev] First thoughts on Rust
masklinn at masklinn.net
Mon Jan 23 02:58:10 PST 2012
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. My issue with this is that languages
>> blocks are first-class objects (Smalltalk, Ruby) default to
>> non-local returns from these blocks. Rust does not — as far as I
>> 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
>> 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
>> 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
>> 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.
More information about the Rust-dev