The biggest difference between this and %>% is that %>% additionally automatically inserts to the first argument, which is quite useful in R, but not in Julia, which uses different argument order conventions.
It’s been a while since I used R, but if I understand %>% correctly, I would argue that the biggest different between it and your suggestion is that the latter introduces values to the local scope, while R’s %>%, Julia’s |>, and the macros in Lazy.jl linked above don’t. I imagine that this is the major problem with your suggestion for most who are not enthusiastic about it.
%>% most definitely DOES introduce values to the local scope, it just uses . instead of _ for the symbol
No that is not at all a corner case. It’s just a bad macro implementation. One of the corner case is the one I mentioned above, macro writers or normal code writers in general can silently get an wrong result if they do not handle _ correctly. It’ll be the only thing that’s readable and writable but reading from it is not expected to return the value written at all.
There is NO way for a macro that chains blocks to recognize user defined macros which take arguments in block form, like MacroTools.@match. Previous versions of ChainRecursice.@chain have special cased to
- Disable _ immediately after assignments
- Disable using _ in type definitions
I eventually decided to drop both. The rules are much simpler now: I recommend users define types outside of chain blocks, and avoid using _ to refer to named objects.
To avoid conflicts, it’s even possible to use two different symbols. I kind of like “it” for the chained item.
I was thinking about this today and the documentation it would need. Something like
_ always refers to the value of the previous line. Because it is gets overwritten after every line, it can also be safely used as a trash bin: that is, if you don’t want to ever access a value again, name it _.
But I think the point of the current _ is that anything assigned to it is not stored. Presumably this could have some performance benefits that would be lost if objects are allocated for a single line and then discarded.
It’s also not clear how this would deal with discarding multiple values, e.g.
X = randn(10, 10, 10)
nr, _, _ = size(X)
Is _ in the next line the second or third dimension size of X?
I think his point is that it’ll be neither, which would be syntactically consistent but extremely confusing
i think ans is not so bad: Anyone who has used a calculator before knows it, and its only one keystroke longer than _ .
Why even bother?
I’d be ok with ans. It currently doesn’t work inside blocks though