New for loops in Rust • Hacker News Board

Re: New for loops in Rust

#11

Post by andolanra » Fri, Apr 06, 2012, 9:55 AM UTC

gioele wrote: post #7

> the new for will work on any higher-order function with the appropriate signature In the end this makes Rust loops look like Ruby loops. May I restate that «widely used programming languages are modified until they resemble Ruby» ( https://news.ycombinator.com/item?id=3448277 ) or CLispScript ( https://news.ycombinator.com/item?id=3448826 ). What I do not understand of the late "scripting" languages (Dart, Rust) is…

Rust is emphatically not a scripting language. It is a systems language with many features drawn from functional languages (e.g. tagged unions for data types, pattern matching, a type class system, type inference) as well as a strong type system with the addition of type states, which are assertions tracked by the compiler. Yes, its syntax is C-like, but I'd assert that it has more in common with OCaml than Dart.

With that in mind, the suggestion that it'd be more worthwhile to strap static types onto Ruby is like looking at engineers designing an aerodynamic, fuel-efficient, high-speed dragster and suggesting they stick a bigger engine in a sedan and call it done. Yes, Rust has adopted a feature superficially similar to Ruby's; that does not mean it wishes to fill the same niche or that Ruby's goals align with Rust's in any significant way.

Re: New for loops in Rust

#12

Post by masklinn » Fri, Apr 06, 2012, 9:56 AM UTC

chubot wrote: post #6

I'm going to make a superficial comment and say that "cont" and "ret" are annoying and gratuitous differences. C/C++, Java, Python, JavaScript, and I think Perl/Ruby/Go all use "continue" and "break". It's just pointless to be different in this respect. A different concept should use different syntax -- and it looks like Rust has several new concepts where they can invent whatever syntax they want. But the same conce…

> "ret" [is] annoying and gratuitous differences. C/C++, Java, Python, JavaScript, and I think Perl/Ruby/Go all use [...] "break"

`ret` is a non-local return, it's got nothing to do with `break` (which is a local return and the usual" break).

Also, `ret` is in line with the (unfortunate I think) systematic shortening of keywords in Rust: `fn`, `ret`, `mut`, `alt`, ...

And as p4lindromica notes, Ruby's `continue` is called `next`.

Re: New for loops in Rust

#13

Post by riffraff » Fri, Apr 06, 2012, 12:12 PM UTC

gioele wrote: post #7

> the new for will work on any higher-order function with the appropriate signature In the end this makes Rust loops look like Ruby loops. May I restate that «widely used programming languages are modified until they resemble Ruby» ( https://news.ycombinator.com/item?id=3448277 ) or CLispScript ( https://news.ycombinator.com/item?id=3448826 ). What I do not understand of the late "scripting" languages (Dart, Rust) is…

I didn't downvote you but I guess you are getting some hate for considering rust a scripting language, since it has none of the features traditionally associated with such languages (simple vm or interpreter, dynamic typing, no compile step).

I think you may be confusing it with something else.

Re: New for loops in Rust

#14

Post by gtaylor » Fri, Apr 06, 2012, 2:20 PM UTC

chubot wrote: post #6

I'm going to make a superficial comment and say that "cont" and "ret" are annoying and gratuitous differences. C/C++, Java, Python, JavaScript, and I think Perl/Ruby/Go all use "continue" and "break". It's just pointless to be different in this respect. A different concept should use different syntax -- and it looks like Rust has several new concepts where they can invent whatever syntax they want. But the same conce…

I agree. I was noticing that it really read "odd" to me, like someone was trying to be clever and terse. I don't think saving a few keystrokes is worth the decrease in cosmetic appearance/readability. Indeed, I inferred what those keywords meant, but, yuck.

Re: New for loops in Rust

#15

Post by tedunangst » Fri, Apr 06, 2012, 2:40 PM UTC

mahmud wrote: post #10

p4lindromica wrote: post #8

Earlier quoted context omitted.

ruby uses the next keyword for continue

C++ and Java iterators use next as well.

Calling next on an iterator and continue in a loop do very different things. C++ iterators use ++ too, but even though ++ and loops are often found together, I would not list ++ and continue as even remotely synonymous.

Re: New for loops in Rust

#16

Post by vilya » Fri, Apr 06, 2012, 3:00 PM UTC

This looks like a bad design. It means either (a) the semantics of 'ret' inside a lambda function can change depending on the call site (whether it's used inside a for loop or not); (b) that a lambda function passed in from elsewhere can cause your function to return early; or (c) that lambda functions have different syntax rules depending on where they're being defined. All of which seem equally bad!

I hope there's something I've missed. I've been quite impressed by the rest of the language so far & it would be a shame if they got this wrong.

Re: New for loops in Rust

#17

Post by kibwen » Fri, Apr 06, 2012, 3:17 PM UTC

For anyone who's wondering what the point of all this is, here are the discussions that help to explain the impetus for this change:

https://mail.mozilla.org/pipermail/rust-dev/2012-February/00...

https://mail.mozilla.org/pipermail/rust-dev/2012-March/00149...

https://github.com/mozilla/rust/issues/1619

As far as I remember it has to do with the prior inability to handle non-local returns and the desire to honor Tennent's Correspondence Principle.

Re: New for loops in Rust

#18

Post by kibwen » Fri, Apr 06, 2012, 3:26 PM UTC

vilya wrote: post #16

This looks like a bad design. It means either (a) the semantics of 'ret' inside a lambda function can change depending on the call site (whether it's used inside a for loop or not); (b) that a lambda function passed in from elsewhere can cause your function to return early; or (c) that lambda functions have different syntax rules depending on where they're being defined. All of which seem equally bad! I hope there's…

I feel continually obligated to remind people that if there's some aspect of the language that they don't like, they should speak up! :) The devs are always looking for feedback, either on the mailing list, the Github issue tracker, or in #rust on irc.mozilla.org.

That said, perhaps there is something you've missed. I've posted links to the Rust mailing list elsewhere in this thread, could you skim over those and let me know if they address your concerns? Honestly I'm not super-thrilled at this change myself, if only because it makes for loop invocations a bit busier to look at, but I can't say that I fully understand the semantic tradeoffs here.

Re: New for loops in Rust

#19

Post by ezy » Fri, Apr 06, 2012, 3:57 PM UTC

kibwen wrote: post #18

vilya wrote: post #16

This looks like a bad design. It means either (a) the semantics of 'ret' inside a lambda function can change depending on the call site (whether it's used inside a for loop or not); (b) that a lambda function passed in from elsewhere can cause your function to return early; or (c) that lambda functions have different syntax rules depending on where they're being defined. All of which seem equally bad! I hope there's…

I feel continually obligated to remind people that if there's some aspect of the language that they don't like, they should speak up! :) The devs are always looking for feedback, either on the mailing list, the Github issue tracker, or in #rust on irc.mozilla.org. That said, perhaps there is something you've missed. I've posted links to the Rust mailing list elsewhere in this thread, could you skim over those and let…

If I have any suggestion it's that you need to start writing some real code with this language beyond the standard library. This change, and a lot of other features in Rust seem, well, masturbatory. It's diverging pretty far from a "practical" language. What problem does this change solve for a programmer?

Re: New for loops in Rust

#20

Post by nikomatsakis » Fri, Apr 06, 2012, 4:49 PM UTC

vilya wrote: post #16

This looks like a bad design. It means either (a) the semantics of 'ret' inside a lambda function can change depending on the call site (whether it's used inside a for loop or not); (b) that a lambda function passed in from elsewhere can cause your function to return early; or (c) that lambda functions have different syntax rules depending on where they're being defined. All of which seem equally bad! I hope there's…

You're missing something. The semantics of `ret` are always consistent: it always returns from out the innermost `fn()` declaration (closures written using the sugared notation `{||...}` do not count as fn declarations, but closures written as `fn() { ... }` do). In cases where this is not possible, a static error is generated.