A way to allow for `filter`, `map` piping...

[haberdashPI]

I like it! (Better than I like my own package LambdaFn). Thanks for putting this together!

It occurred to me that, since this is a macro, you should be able to rewrite piping expressions to treat functions as if they have a curried version.

That is:

@_  data  |>  filter(_>10) |>  map(_+1)

Could be re-written as:

data |> x -> filter(a -> a > 10, x) |> x -> map(a -> a +1,x)

The rule could be that if the top-level expression after |> is a function call, rewrite the expression to be a function that takes a single argument and passes it as the final argument of this top-level expression.

Maybe that should be a separate macro (@_> @|>, @|>_ ??). It is essentially a combination of your macro @_ and the @>> macro from Lazy.jl.

[haberdashPI]

Also, if you like this idea, I'm happy to make a PR for this package to add the feature.

[c42f]

Thanks! I know too little of other packages for this stuff so it's nice to see LambdaFn.

It occurred to me that, since this is a macro, you should be able to rewrite piping expressions to treat functions as if they have a curried version.

I do agree this is a tricky problem.

The issue I see with this is that it amounts to a lot of guessing about the user's intentions which I think leads to something less general purpose. For example, we could no longer define Filter(f) = x->filter(f,x) and use @_ data |> Filter(_+1).

I feel like the better solution here would be to be more explicit and allow __ to "escape an extra level", allowing things like

    @_  data             |>
        filter(_>10, __) |>
        map(_+1, __)

There may be other options, though.

Overall my aim with this package is to make something which could possibly be included in Base. So whatever we do, I'd like it to be visually and conceptually consistent with the builtin syntax which has been discussed so much in JuliaLang/julia#24990.

[c42f]

Have a look at latest master; I implemented the __ version and I'm very happy with the result.

BTW, I renamed the package to Underscores.jl because there's a lot more underscores and richer syntax here than I'd originally imagined. (Also evidence suggests I can no longer type non-pluralized package names :-P )