Assignment silently truncating tuples

[dmbates]

This came up in the thread on qr/qrp on julia-dev. At present the methods for the qr generic return a 3-tuple, (Q, R, p) and it is not an error to assign the result as

Q, R = qr(A)

Matlab users expect this to have different semantics from

Q, R, p = qr(A)

which, I believe, is very difficult if not impossible in Julia. Should an attempt to truncate a returned tuple like this be flagged as an error?

[JeffBezanson]

Matlab also allows ignoring unused return values, so this could cause problems elsewhere.

[pao]

Sometimes you don't really need the extra values, though. MATLAB provides "~" to make this explicit; we could use the standard "_" from many functional languages (and I believe supported by julia's anonymous functions?)

[StefanKarpinski]

_ is just a normal identifier so far. I'm a little reluctant to make it special (I used to be itching to make it special left and right but along the way got "cured" — like a ham).

[pao]

Having a name that doesn't create a binding means you can explicitly throw stuff away and not create a binding you could accidentally use down the road. I'm not sure if that name should be _, but it is a popular choice (Prologs, Erlang, Haskell, Scala, etc.)

[StefanKarpinski]

yeah, I could be convinced to do this.

[JeffBezanson]

Although overloading on nargout does give you some nice flexibility, our behavior here is one advantage of NOT having it. You know the left-hand side doesn't affect the call, so you don't need syntax for asking for values which are ignored. And the error checking part of it is just more code to generate --- and to be able to optimize away --- just because you did not access some bit of data. That feels strange to me. "Error: I took the trouble to make this tuple for you; why didn't you eat the whole thing?"

[pao]

You do need syntax for asking for ignored values if you want to throw away the first element of the tuple rather than the last one.

[JeffBezanson]

Ok, so put an underscore in there. Nobody's stopping you. I don't get what the big deal is.

[pao]

There's nothing preventing you--or without namespaces, anyone else--from using the underscore later on with the potential of accidentally introducing a value you didn't want, instead of being an error. As you state it's just a store that could be optimized away anyways. But I'm not hurt either way. (I'm sorry I used the phrase "need syntax", which may have set this off...)

[StefanKarpinski]

There's one case where narg-style overloading would be a big benefit: the size function. The reason that's of interest is because of the whole vector/matrix thing. If you call size on a vector that's being used as a matrix and expect a pair of return values, it will blow up. If size could return the expected number of values, padding with ones, then we would get greater polymorphism.

One argument for having assignment to _ discard values is that in the case where a function call is inlined, the computation of the value that's discarded could be avoided entirely. Not sure how realistic that scenario is.

[JeffBezanson]

Where we can lower code enough that LLVM can prove a computation unnecessary, it will already do that. To do more than that we need to model function purity.

[JeffBezanson]

We discussed this and didn't really get anywhere. Both matlab and common lisp multiple-value-bind allow ignoring trailing values (lisp even allows more variables on the left than values!), so I didn't expect this to be a controversial feature.

[StefanKarpinski]

I say just leave it as-is.