@snotskie looped me into this discussion in the context of Lint

I have updated Lint.jl (v0.1.1) to give warnings over
* for-loop when the iterable is just a literal number
* nested vcat, i.e.[[1,2],[3,4]]. Other array formats are unaffected since 
their ASTs are distinct.

Tony

On Monday, September 8, 2014 6:19:55 AM UTC+7, [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
>

Reply via email to