Would the Scala convention for anonymous function arguments be feasible?

Internals & Design
21

Is it the case that unused variables get optimized away? In that case, you could imagine

result = begin
    a = 1
    b = 2
    a + 1
    _ / b
end

getting lowered to

result = begin
    _ = a = 1
    _ = b = 2
    _ = a + 1
    _ = _ / b
end

but then optimized to

result = begin
    a = 1
    b = 2
    _ = a + 1
    _ / b
end
22

I assumed that the presence of _ would be dealt with at lowering time, such that

foo(x)
f(x)
g(_)
h(_)

is transformed to something like

foo(x)
$(Symbol("_#1")) = f(x)
$(Symbol("_#2")) = g($(Symbol("_#1"))
h($(Symbol("_#2"))

before inference even sees the code. It should be compatible with current optimizations, allow _ to take different types (since there is a “bug” or missing capability for this in inference in v0.5), etc.

23

I agree with the “too much magic” concern, and I think it can be avoided if _ becomes a sort of currying syntax. Actually, I think _ as a curry “operator” could be useful many places, not just in the context of function chaining. Essentially, this means that foo(_, b) is transformed to (x) -> foo(x, b).

The only question then is whether foo(_, _) should transform to (x) -> ((y) -> foo(x, y)) or (x, y) -> foo(x, y). The former is proper currying but perhaps the later would be more practically useful?

24

The only question then is whether foo(_, _) should transform to (x) -> ((y) -> foo(x, y)) or (x, y) -> foo(x, y). The former is proper currying but perhaps the later would be more practically useful?

The third option which is compatible with the function chaining syntax proposed above is foo(_, _) transforms to x -> foo(x,x).

This might not seem useful at first, but in function chaining it lets you use multiple returns (a tuple of results) more elegantly, such as eig(matrix) |> foo(_[1], _[2]) more-or-less splats two output arguments from eig into slots of foo.

25

Hmm…that is closer to the Scala semantics, but seems to be a bit further from the notion of currying. It also requires that _ behave, at least nominally, as a placeholder variable.

Ok, so if that’s the case (and if I may be so bold), I think the question boils down to: should _ be an equivalent to ans or a placeholder that also triggers a currying transformation?

The former would, I suspect, require less change to the grammar of Julia but may require more refinement of ans’s scoping/semantics. The later involves less magic, but would require a non-trivial transformation of the source/AST.