Hello!

[bramtayl]

Just happened to find this. I offer a similar @_ macro in LightQuery. Maybe it would make sense to pool efforts?

[haberdashPI]

Hey: yeah, I'm happy to see some sort of combined effort. I saw that you had written it, but wanted to experiment with a somewhat simpler approach.

I could imagine adding your version of @_ or some variant thereof to this package, largely because it seems orthogonal (though very relevant to) the goals of your LightQuery package. Does that make sense to you?

[bramtayl]

Sure. I'm open to whatever.

[haberdashPI]

Cool!

A few initial thoughts / questions about how to combine efforts:

1. From what I can tell your version of @_ and my version of @λ are quite similar. There are a few more features that @λ has (e.g. named and numbered arguments), and I handle _ differently. What're your thoughts on that? Do you like one approach over the other? I like replacing each _ with a unique argument value, allowing for very terse calls (e.g. _ + _). It is easy to use _1 or _x within @λ if you want the same argument repeated. That's also why I like the additional features of @λ

2. How hard would it be to get your version of @> to properly handle things like @> map(2*_,1:10) |> filter(_ > 6,_), ideally I would want the output of that to be [8 10]. I think that's the key features I imagine adding to @λ. I think the rules for when to expand out the _ could be relatively straightforward within the constrained context of a series of function calls separated by |>.

[bramtayl]

On 1)

I don't have very strong opinions about syntax. You can number arguments in @_ just by choosing the number of underscores (_ is argument 1, __ is argument 2, etc.). The ability to add keyword arguments would definitely be nice, though.

On 2)

Maybe not too hard but not worth doing, IMHO.

map((@_ 2 * _), 1:10) |> @_ filter((@_ _ > 6), _)

Is almost as terse and more clear.

[bramtayl]

One thing that bugs me about @_ is precedence of commas

map(@_ 2 * _, 1:10) |> @_ filter(@_ _ > 6, _)

would be nice

[haberdashPI]

regarding 1.)

I think I personally prefer _1 and _2 to _ and __: the former seems more legible to me. It is not as easy to differentiate _ from __.

regarding 2.)

I agree, that may be the case, in which case either @_ or @ λ is sufficient. Maybe I don't understand your version of @>?

It does however seem worth experimenting with a fancier macro, more like the PR for julia, that would try to be smart about where the boundaries are. I think it will be hard to tell which works well in practice with out some means of testing out both.

also, another point (3):

Do you have an opinion about the various names for this macro? For similar reasons to my issues with _ and __ I think I prefer @ λ visually, though I prefer @_ for typing.

[haberdashPI]

One thing that bugs me about @_ is precedence of commas

map(@_ 2 * _, 1:10) |> @_ filter(@_ _ > 6, _)

would be nice

I think this is one reason it would be worth experimenting with something a little smarter. In any case it seems like something that would sort itself out by implementing something and trying it out to see how it feels.

[bramtayl]

Well the place to start would be JuliaLang/julia#24990 (comment)

[bramtayl]

Hmm sure i could see the numbers as being clearer. No strong opinions about macro names

[haberdashPI]

My thinking is that the macro would allow for a slightly different ruleset than that proposal. It could be one that allows for a broader scope of the function boundary: e.g. the |> could be used to denote the function boundary of bare _ arguments, while other _ arguments expand out to the widest containing function argument. Something like that...

Haven't thought through it, but in many cases that might be the same as the PR's rule, but I suspect there would be cases where the macro would work differently.

[bramtayl]

I still like my proposal here JuliaLang/julia#24990 (comment)