thanks for all the replies.
i really wanted something that took *only* the contents of the array, while
getindex has the type too. so i've defined my own "array" function:
array(T) = (builder(x...) = T[x...])
which i can use as, say, array(Any).
(the final use case is that this is given to a parser and is used to
construct an array from the results, in much the same way as i can
currently pass in the function "tuple").
i'd be interested if there's some nicer (ie using curly brackets) way of
handling the type, T, or some way of defining anon functions (to avoid
explicitly naming "builder") with interpolated args.
cheers,
andrew
On Wednesday, 17 June 2015 12:06:50 UTC-3, David Gold wrote:
>
> Soo, in summary (and I do apologize for spamming this thread; I don't
> usually drink coffee, and when I do it's remarkable):
>
> 1) Mauro and Avik seem to be right about the common use case Any[1, 2, 3,
> 4] lowering to getindex -- my apologies for hastily suggesting otherwise
> 2) I suspect I was wrong to say that concatenation in general doesn't go
> through a function. It probably does, just not always through getindex
> (sometimes vcat, typed_vcat, vect, etc).
>
> On Wednesday, June 17, 2015 at 10:15:00 AM UTC-4, David Gold wrote:
>>
>> However, it does look like this use pattern does resolve to 'getindex',
>>
>> *julia> **dump(:( Int[1, 2, 3, 4] ))*
>>
>> Expr
>>
>> head: Symbol ref
>>
>> args: Array(Any,(5,))
>>
>> 1: Symbol Int
>>
>> 2: Int64 1
>>
>> 3: Int64 2
>>
>> 4: Int64 3
>>
>> 5: Int64 4
>>
>> typ: Any
>>
>>
>> *julia> **getindex(Int, 1, 2, 3, 4)*
>>
>> *4-element Array{Int64,1}:*
>>
>> * 1*
>>
>> * 2*
>>
>> * 3*
>>
>> * 4*
>>
>>
>> So now I am not so sure about my claim that most concatenation doesn't go
>> through function calls. However, I don't think that the rest of the
>> concatenating heads (:vect, :vcat, :typed_vcat, etc.) lower to getindex:
>>
>>
>> *julia> **@which([1, 2, 3, 4])*
>>
>> *vect{T}(X::T...) at abstractarray.jl:13*
>>
>>
>> *julia> **@which([1; 2; 3; 4])*
>>
>> *vcat{T<:Number}(X::T<:Number...) at abstractarray.jl:643*
>>
>>
>> they seem instead to call the type 'vect', 'vcat', etc. itself on the
>> array arguments.
>>
>
