Stefan, Thank you. Your description really helps clarify things. The issue about different functionality for "return" in map vs for loops was obviously something I overlooked here.
And yes, the influence is clearly ruby. I see how a macro could can duplicate the for loop structure. I guess I'm a bit surprised that is the only way, and there wasn't a metaprogramming way to add this functionality to all iterators. I guess what I was wanting was the ability to use something like "each" (which functions like a for loop, but looks like map()), and any such function (enumerate, etc.), which I guess is just more method definitions. But I probably just have too much baggage from history, so I'll just try and use natural julia expressions for the time being... ;) Cameron On Fri, May 16, 2014 at 12:58 PM, Stefan Karpinski <ste...@karpinski.org>wrote: > That form of iteration is common from Ruby, which is where I'm guessing > this interest is coming from? Ruby has the block/proc/lambda distinction > that makes the for loop and .each forms behaviorally similar, whereas in > Julia, there's just the one kind of anonymous function. As a result, if > this were made to work, enumerate(a) do i,x and for (i,x) in enumerate(a) > would not behave exactly the same – return in the former would exit the > current loop iteration whereas return in the latter exits the enclosing > function. I'm not sure it's a good idea to introduce too many different > ways to write this. If we were going to implement this, we wouldn't do it > by adding language features, but by adding methods to iterator-producing > functions like enumerate. In this case, you could do something like this: > > function enumerate(f::Callable, x) > for (i,x) in enumerate(x) > f(i,x) > end > end > > > That pattern could be emitted by a macro, of course. >
