Live data from Hacker News

New for loops in Rust

brson.github.com

21–27 of 27 posts

Re: New for loops in Rust

#21
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 wrote up a quick blog post to spell out some of the examples and show how the design aims for a consistent meaning for the `ret` keyword:

http://smallcultfollowing.com/babysteps/blog/2012/04/06/for-...

Re: New for loops in Rust

#22
post #14
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.

This (my) comment is just noise, but I support the choice of short keywords - it helps in seeing them iconically. It's not the typing, though I think that helps too, but the reading - a long word, you have to /read/. A short sequence of chars is an instantly, right-brain recognized pattern. For that same reason I much prefer '0' to 'NULL' for ptrs in C/C++ to (I'm talking about visually, not type safety).

Re: New for loops in Rust

#23
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…

fwiw, I thought the same when I began work on Rust, but I have since gotten quite used to the shorter keywords. At this point, I can't believe the keywords in other languages are so pointlessly long.

But the truth is that whatever the surface syntax is, one quickly gets used to it. What's more important are the core concepts at work.

Re: New for loops in Rust

#24
post #5

Why is there so much sugar?! Can't a keyword just be a keyword?

> Why is there so much sugar?! Can't a keyword just be a keyword? Statements based on keywords are syntactic sugar. What I'm seeing here in Rust is the complete opposite, building an iteration statement from language built-ins. It does include some sugar in it (and "for" is a special keyword) but the semantics of the construct is based on lambda calculus and other lower level constructs in Rust. In general, it's bett…

This is more like Splenda, not sugar

Re: New for loops in Rust

#25
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.

So what happens if we pass a stack closure containing a ret into another function? For example, what would this code print out:

  fn foo(f: fn()) {
    log(info, "calling f");
    f();
    log(info, "called f");
  }

  fn bar() {
    log(info, "calling foo");
    foo({||
      ret;
    });
    log(info, "called foo");
  }
I'm not clear on whether the ret would return from foo or from bar - or whether it would be a compile error.

BTW thanks for taking the time to reply - I appreciate it!

Re: New for loops in Rust

#26
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…

ruby uses the next keyword for continue

Ditto for Perl. However Perl uses last instead break.

NB. Since Perl 5.10 it does have continue & break in its given/when (topicalizer) switch block.

Re: New for loops in Rust

#27
post #25

Earlier quoted context omitted.

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.

So what happens if we pass a stack closure containing a ret into another function? For example, what would this code print out: fn foo(f: fn()) { log(info, "calling f"); f(); log(info, "called f"); } fn bar() { log(info, "calling foo"); foo({|| ret; }); log(info, "called foo"); } I'm not clear on whether the ret would return from foo or from bar - or whether it would be a compile error. BTW thanks for taking the time…

Tried compiling this myself with a main function that just calls bar(), resulting in a compiler error:

  `ret` in block function
Post reply on HN