The output type of list comprehension is often difficult to infer (by
human), as it depends on a complex compile-time type inference mechanism.
This, combined with the fact that its behavior is inconsistent with that of
the function map, is a recipe for confusion.
We should try to make things more consistent.
- Dahua
On Wednesday, November 5, 2014 8:30:58 AM UTC+8, ele...@gmail.com wrote:
>
>
>
> On Wednesday, November 5, 2014 10:01:10 AM UTC+11, yfra...@gmail.com
> wrote:
>>
>> Bug map works fine...
>>
>> julia> g(x) = 1 / (1 + x)
>> g (generic function with 1 method)
>>
>> julia> xs = [1.0, 2.0, 3.0, 4.0]
>> 4-element Array{Float64,1}:
>> 1.0
>> 2.0
>> 3.0
>> 4.0
>>
>> julia> gxs1 = map(g, xs)
>> 4-element Array{Float64,1}:
>> 0.5
>> 0.333333
>> 0.25
>> 0.2
>>
>>
> Map determines the type dynamically at runtime. Comprehensions infer the
> type at compile time, but the type of g(x) is dependent on the type of x,
> so its not known at compile time.
>
> If you define g(x) = (1/(1+x))::Float64 so the type of g(x) is known at
> compile time then you get:
>
> julia> gxs = [g(x) for x in xs]
> 4-element Array{Float64,1}:
> 0.5
> 0.333333
> 0.25
> 0.2
>
> [...]
>
>>
>>>
>>>
