One problem with your consistency point, Wilfred: you can iterate over an array of arbitrary order with a single for loop.
-- John On Sep 7, 2014, at 4:19 PM, [email protected] wrote: > Sorry, 'cripes' was just me saying that it surprised me. Let me attempt to > make the case for change. > > The suitability of the any language feature depends on how well it stacks up > to Julia's goals. I think consistency, orthogonality, and finding errors > early are good goals, but I admit I've chosen these arbitrarily. > > Consistency: I would expect a n-dimensional array to have n for loops in > order to iterate over it by item. If I view an integer as a 0-dimensional > array, I therefore wouldn't expect any for loops. > > Being able to iterate over numbers also means I don't always get a simpler > type when I iterate over a value. This makes the following slightly > surprising code legal: > > julia> for a in 1 > for b in a > for c in b > println(c) > end > end > end > 1 > > Orthogonality: If we do allow a simple value to be iterated over, what is > the underlying principle that says which value types can be iterated over? > Integers and floats are iterable, but so too are booleans and complex > numbers. On what principle are booleans and complex numbers iterable (are > they scalar)? Could I expect symbols to be iterable too? > > Catching errors early: If you can design a language such that not all > possible combinations of symbols are legitimate programs, it's easier to spot > mistakes. It reduces the likelihood that a programmer's mistake produces a > different, but legal program. I'm concerned that it's too easy to use an > integer when you should have used a range, leading to subtle bugs. Here's an > example: > > julia> function sumto(n) > total = 0 > for i in n > total = total + i > end > return total > end > > I think that's the strongest case I can make, I'm open to being persuaded > otherwise. > > Wilfred
