What (are/should be) the boundaries of single-argument function shorthand?

[gwhitney]

I don't feel like the cheatsheet quite makes clear what expressions in which & occurs qualify as single-argument function (shorthand) expressions (SAFEs ;-).
Experimenting, the following are all SAFEs: &.prop, &.method(a).chained, !&, -&, &+3, -&*2, & > 3`
as well as

operator contains
& contains y
!& contains y

whereas none of the following are

3 + &
3 > &
y contains &
func(&)
func(&,2)

So the rule seems to be something like "the leftmost identifier-or-number is &". Does that sound about right? Is there a technical reason that only the leftmost thing (not counting prefix unary operators) being & can trigger this? Or could it work that 3 - & would be SAFE? (etc., etc.) And if so, would it be a good idea?

[edemaine]

Yes, the current rule is "function starts with &, optionally preceded with unary operators". Good idea to improve the docs to specify this.

If you start extending leftward, you don't know how far to go. (Potentially, you could go arbitrarily far.) Then the feeling is maybe you really need an arrow wrapper to specify where.

But there are some interesting exceptions, proposed in #480, where we don't already have a meaning. I guess x > & could also work; I'll add it. I'm not sure whether f g & (as in your y contains & example) should be f($ => g($)) (I think that's what #480 would imply?) or $ => f(g($)).

[gwhitney]

Yes, I would be a big fan of #480. I don't see how y contains & would be ambiguous; if contains has been declared as an operator, isn't this just sugar for contains(y, &) which in turn if #480 were adopted would be ($) => contains(y, $) ?

As for what f g & should mean if allowed, I'd just like to note that there seems to be very little point in it meaning f(($) => g($)) since that's almost exactly the meaning that f g already has, except for narrowing g to be precisely a unary function so that should f ever call its argument with more than one parameter, the later parameters will be dropped instead of being passed on to g. It would seem rare that you would need that narrowing, and if so, you could always write out the arrow function form. So by this reasoning I conclude that if f g & were to mean anything, it should be ($) => f(g($)) in which case we get the nice side effect that SAFE gives a nice abbreviation for unary function composition.

But if the rule ends up being "& can only go up one level" so be it, I think that's livable. Certainly it would be nice to eliminate the inconsistency that & - 3 is SAFE but 3 - & is not. And such a change would help with one of the bugaboos of functional programming, when you want to inject the incoming argument into a position other than the first in a function (like C++'s bind2nd or whatever that it has or had, made functional-style code look really ugly).

[gwhitney]

Oh, right, sorry I see the point of "only go up one level," it's that you want

mymap g 3, & to mean mymap(($) => g(3, $) not ($) => mymap(g(3, &))

so if mymap g & did mean ($) => mymap(g($)) it would only be as a special case that & lifted farther in a series of unary calls because there's not really any point in it only lifting one level in this special case. Not sure if it would be worth adding such an exception to the syntax/semantics. As I said, I can certainly live with & lifting just one level and it's a big improvement imo over & must be first except for unary operators. And if you did make that exception, you would face the question of whether
f g h & meant f(($) => g(h($)) or ($) => f(g(h($))), either of which could be pointful. So that seems to be another argument for leaving well enough alone and keeping & to lifting at most one level. That would put us back to f g & meaning the nearly useless f(($) => g($)) so that if you want function composition this way you would just have to explicitly write ($) => f(g($)), oh well.

[edemaine]

Regarding contains: When I read your post, I failed to see that contains was an operator. I agree that y contains & should unambiguously mean $ => contains(y, $).

Nice point that f & isn't really useful. But it's probably best to keep it behaving like f a, &, b for consistency...

[edemaine]

#1070, which has been mostly implemented, provides a reasonable solution to this question, I believe. And there's even a reasonable definition of how high things lift.