Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

[Jeremy Howard]

>    > We could undo the ambiguity like so:
>    >
>    >    /^{foo}/;   # like ${foo} and @{foo} and %{foo}
>    >
>    > In fact, this seems built-in if we follow the same var conventions.
We
>    > can make ^ bind to {} as tightly as we need.
>
> That would be the right solution. And of course one could use the {}
anywhere
> necessary or desirable:
>
> my $sin_deg = sin(180*^{_}/$pi);
>
This is looking quite perlish now, isn't it? And this example shows why '*'
can get a bit nasty:
  my $sin_deg = sin(180**{_}/$pi); # Pardon?

Of course the same is true for ^:
  my $reverse_test = SOME_FLAGS ^ ^_;
but at least ^^ isn't an operator like ** is. Also, you don't see binary '^'
all that often.

Compared to the downside of '_' (__ is hard to read on paper, _identifier
looks like a private method call), the downside of '^' (potential confusion
because '^' is also a binary operator) seems pretty small. As for '*', well
personally I hate it:
- '*' means something else in perl 5
  (confusing C programmers is one thing,
  confusing perl 5 programmers is another!)
- '* *{_}' will be a common construct, and is very confusing.

So what if Damian's redraft uses '^', but mentions '_' as a fallback option?

And there's no argument about having anonymous, positional, and named
placeholders in the redraft...?