3 ms·

this stuff is always interesting. i don't understand how it ends up in the language in the form of 'for-in' though. the syntax is similar to the old school BAS

by jheriko 12y ago

this stuff is always interesting. i don't understand how it ends up in the language in the form of 'for-in' though. the syntax is similar to the old school BASIC for loop, but the implementation is heavier in the vast majority of cases where you write simple code for the loop body (i.e. avoiding heavyweight language constructs). Of course unless the compiler optimised out the lazy evaluations... i would like laziness in this situation to be described by a keyword please, so that i don't have a whole language feature being slower by premature optimisation I don't get a say in... :)

ColinE 12y ago
I think you misunderstand, the Swift for-in relies on a sequence, i.e. an object that 'feeds' it a certain number of items. However, the sequence does not have to be lazy in its evaluation. And there is nothing that couples for-in to the concept of lazy evaluation. When you use for-in to iterate over arrays, strings, dictionaries etc ... it is an iteration of the type you are no doubt familiar with, where you are iterating over some fixed pre-computed structure. However, sequences can also generate their 'next' value lazily. It is something that I consider to be an interesting topic, but would certainly not advocate that everything should become a lazy operation.
masklinn 12y ago
> i would like laziness in this situation to be described by a keyword please, so that i don't have a whole language feature being slower by premature optimisation I don't get a say in... :) Rust uses the exact same external iterator pattern[0] yet is competitive with[1] a C-style for loop[2] [0] http://doc.rust-lang.org/std/iter/ http://doc.rust-lang.org/std/iter/ [1] up to and including inlining and full unrolling [2] http://www.reddit.com/r/rust/comments/2957fg/can_i_request_a_c_style_for_loop/ http://www.reddit.com/r/rust/comments/2957fg/can_i_request_a...

by jheriko 12y ago

ColinE 12y ago

I think you misunderstand, the Swift for-in relies on a sequence, i.e. an object that 'feeds' it a certain number of items. However, the sequence does not have to be lazy in its evaluation. And there is nothing that couples for-in to the concept of lazy evaluation. When you use for-in to iterate over arrays, strings, dictionaries etc ... it is an iteration of the type you are no doubt familiar with, where you are iterating over some fixed pre-computed structure. However, sequences can also generate their 'next' value lazily. It is something that I consider to be an interesting topic, but would certainly not advocate that everything should become a lazy operation.

masklinn 12y ago

> i would like laziness in this situation to be described by a keyword please, so that i don't have a whole language feature being slower by premature optimisation I don't get a say in... :) Rust uses the exact same external iterator pattern[0] yet is competitive with[1] a C-style for loop[2] [0] http://doc.rust-lang.org/std/iter/ http://doc.rust-lang.org/std/iter/ [1] up to and including inlining and full unrolling [2] http://www.reddit.com/r/rust/comments/2957fg/can_i_request_a_c_style_for_loop/ http://www.reddit.com/r/rust/comments/2957fg/can_i_request_a...