iteration variables should be local to comprehensions

[rtzui]

x="a"
y=[ sqrt(x) | x = 1:10 ]

x==10 is true
I think that's strange. x should be a local variable in that loop. Also Haskell style comprehensions are cool. On the one hand like map:

x=[1,2,3,4,510,1,2,3,1,9]
y=[sqrt(a) | a ∈ x]

On the other hand more powerful:

x=[1,2,3,4,510,1,2,3,1,9]
y=[sqrt(a) | a ∈ x, x%2==0]

I 'd love unicode keywords (as valid alternative form), but i guess nobody else does.

[pao]

See also #524 for scoping in list comprehensions at the REPL. What does your example do if you embed it in a function, making x non-global? I can check when I get home if no one else gets to it by then.

function lctest()
    x = "a"
    y = [ sqrt(x) | x = 1:10 ]
    x == 10
end

[pao]

Okay, this does look like something different, then.

julia> function lctest()
           x = "a"
           y = [ sqrt(x) | x = 1:10 ]
           x == 10
       end

julia> lctest()
true

julia> function lctest()
           x::String = "a"
           y = [ sqrt(x) | x = 1:10 ]
           x == 10
       end

julia> lctest()
in ref: arrayref: index out of range
 in ref at /home/patrick/julia/jl/array.jl:165
 in tuple_elim_pass at /home/patrick/julia/jl/inference.jl:1521
 in typeinf at /home/patrick/julia/jl/inference.jl:1059
 in typeinf_ext at /home/patrick/julia/jl/inference.jl:805

[JeffBezanson]

Congratulations, you found a compiler bug :)

[JeffBezanson]

It's maybe not ideal, but you can accomplish this as:

x=[1,2,3,4,510,1,2,3,1,9]
y=[sqrt(a) | a in x[x%2==0] ]

[pao]

Okay, with that out of the way, it looks like there's three separate issues here:
(1) Variables assigned to within the context of a listcomp may be captured from the enclosing scope iff the variable is already defined, which is unexpected:

julia> [ i | i = 1:10 ]
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

julia> i
i not defined

julia> i = 'a'
'a'

julia> [ i | i = 1:10 ]
{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}

julia> i
10

The same thing happens with enclosing function definitions.

(2) Request that list comprehensions support filters/guards as in Haskell or Python. My Scheme reading abilities aren't terribly good but it doesn't look like that's in there. I agree it would be nice. I've spun this into #550. And Jeff is working faster than I can type this.

(3) Request for support for Unicode forms for certain operators. Editor and REPL support would be required to make this practical for people with normal keyboards. The Haskell editor Yi supports certain automatic Unicode replacements (see https://github.com/yi-editor/yi/blob/master/yi/src/library/Yi/Char/Unicode.hs). Given how few special operators exist in the language I'm not sure how useful this is overall. There's ->, I suppose.

[rtzui]

to unicode: I'm supprised this works:

julia> π=3.141
3.141

julia> r=5
5

julia> 円=π_r_r
78.525

awesome.
I guess unicode keywords should be just an alternative, so no hacking the REPL would be necessary, but editors could (didn't have to) implement this. I just got new a idear for unicode symbols and created issue #552.

[JeffBezanson]

Of course that works! :)
I agree it would be nice to parse unicode operators properly so they can optionally be used. No reason not to, as long as they're not required in order to use core language features.

[JeffBezanson]

Since we have issues for the other parts of this, I'm going to change the title of this one.

[diegozea]

This examples doesn't work... Am I missing something?

julia> [ sqrt(x) | x = 1:10 ]
ERROR: syntax: malformed function argument (call sqrt x)

julia> [ i | i = 1:10 ]
ERROR: syntax: function argument names not unique

[JeffBezanson]

We've used for instead of | for quite a while now.

[diegozea]

Thanks @JeffBezanson I was using for since I have memory of Julia. So when I saw this notation I tried to reproduce it by curiosity.