allow tuple destructuring in formal arguments

[WestleyArgentum]

I've seen this a few times, maybe support could be added:

julia> map({:foo=>"foo", :bar=>"bar"}) do (k, v)
             println("$k: $v")
       end
ERROR: syntax: "(k,v)" is not a valid function argument name

Right now people fall back on:

map({:foo=>"foo", :bar=>"bar"}) do el
    (k, v) = el
    println("$k: $v")
end

[simonster]

+1

[kmsquire]

+1

[burrowsa]

Is this a general do block thing, or is it specific to map? Python has a starmap to do this, in Julia it would look a bit like:

starmap(fn, seq) = [ fn(i...) for i in seq ]

And solves the problem:

starmap({:foo=>"foo", :bar=>"bar"}) do k, v
    println("$k: $v")
end

foo: foo
bar: bar

If do blocks had special support for unpacking tuples then it would be inconsistent and confusing when the user changed their code from using a do block to passing in a function and found that they now had to unpack their tuples manually again.

Obviously starmap makes sense as a name in python but not in Julia, the literal translation would be ellipsismap but I'm not sure that is a good name either.

[StefanKarpinski]

splatmap might be a better name.

[JeffBezanson]

Yes, it should be possible to support the syntax do (x, y), but it can't mean tuple splitting since function arguments don't mean that in other contexts.

[simonster]

There are enough other functions that apply a function argument to an iterator (pmap, mapreduce, any, all, count, find, sum) that a general solution would be useful. One syntax that does not seem to be taken (it presently throws) is:

map(x) do splat(k, v) ... end

as sugar for

map(x) do x splat(x) do k, v ... end end

But maybe that's too confusing, because that syntax could also mean:

map(x) do
    splat(k, v)
end

A macro (@splat map(x) do k, v ... end) is another less invasive possibility, although it's also not immediately clear to someone reading the code what the macro does.

[simonster]

Another possibility is to automatically split the tuple with no new syntax, if the function is being passed a single tuple argument but the do block takes multiple arguments. That wouldn't be consistent for the case of a tuple of length 1, but I'm not sure that's a big deal. Not sure how this would be implemented, though.

[JeffBezanson]

I feel that implicitly splatting things in some cases would be the Path of Madness.

[simonster]

If this is useful enough that we are okay with extending the language for it, maybe just do... k, v?

[StefanKarpinski]

That's not a bad syntax. What's a little strange about introducing this is that it makes the do-block syntax(es) more flexible than the immediate lambda syntax, since there's no way to splat a single argument into multiple locals. Something like ...(k,v)->f(k,v) could work, I suppose.

[JeffBezanson]

The real way to do this is to allow tuple expressions as formal arguments. Example:

f((x,y),) = x+y

would mean

function f(temp)
    x,y = temp
    x+y
end

Types would be specified as normal, e.g. f((x,y)::(Int,Int)).

[JeffBezanson]

I guess if you want to be fancy f((x::Int, y::Int)) could work too.

[StefanKarpinski]

This is basically converging with pattern matching at this point (which is a good thing IMO).