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

[Jeremy Howard]

> >   > As for the regexp issue, just to clarify there's only one ambiguous
case
> >   > we need to work out that I can see:
> >   >
> >   >    /.*^foo/;   # ok
> >
> >But: /.*^foo/m;  #ambiguous
>
> Hold it. What does this mean? Is the whole regex gonna be turned into an
> anonymous sub, or what?
>
> I find this whole  "higher order function" thing nothing but butt ugly.
> Perl already has anonymous subs, which look far less confusing. If you
> want shorter syntax for "sub { ... }" and for $_[1] etc, I can
> understand that. But please please please do not make this thing look
> like an ordinary expression, when it is anything but!
>
First of all, it won't look like an ordinary expression. Damian and I have
just finished off v2 of this RFC, which should be in your inbox RSN.
Hopefully you'll agree that the suggestions made there never create a higher
order function when there's ambiguity (you have to use braces to
disambiguate).

Secondly, it's not just shorter syntax for sub{} and $_[1] etc:

 $check = ^_ < 2 + ^_ * atan($pi/^_) or die ^_;

is actually equivalent to:

 $check = sub (;$$$$) {
           @_==0 ?  ^_ < 2 + ^_ * atan($pi/^_) or die ^_
         : @_==1 ?  $_[0] < 2 + ^_ * atan($pi/^_) or die ^_
         : @_==2 ?  $_[0] < 2 + $_[1] * atan($pi/^_) or die ^_
         : @_==3 ?  $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die ^_
         :          $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die $_[3]
         ;
 };

to allow for re-currying of deferred expressions.