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
