> > The subroutines generated by a placeholder are not exactly like
> > the equivalent subroutines shown above. If they are called with
> > fewer than the required number of arguments, they return another
> > higher order function, which now has the specified arguments
> > bound as well.
>
> The implementation of this might be far from trivial. The
> IMPLEMENTATION section of this RFC should address this.
But I showed the exact subroutine the curried function was equivalent to:
Thus the expression:
$check = ^_ == ^_**2 *^_ or die ^_;
is actually equivalent to:
$check = sub (;$$$$) {
@_==0 ? ^_ == ^_**2 *^_ or die ^_
: @_==1 ? $_[0] == ^_**2 *^_ or die ^_
: @_==2 ? $_[0] == $_[1]**2 *^_ or die ^_
: @_==3 ? $_[0] == $_[1]**2 *$_[2] or die ^_
: $_[0] == $_[1]**2 *$_[2] or die $_[3]
;
};
We could implement this in pure Perl now, if only (grrrrr!) it were
possible to overload all operators.
> How would Perl's innards have to change to make this possible?
Apart from the changes required to make *all* operators overloadable,
not at all, AFAICS.
> > When Perl sees an expression containing a placeholder, it creates a
> > curried expression around this placeholder that is as large as possible,
> > stopping when it reaches a halting rule. In an expression containing
> > multiple placeholders, the placeholders are only combined into a single
> > curried expression where there is no halting rule between them.
>
> How grammable is this? That is, it's easy to describe but how would
> it affect Perl's parsing process? Can you suggest ways in which this
> might be done?
Sure. Placeholders tokenize and parse exactly like scalar vars.
Then you look through each expression tree recursively and -- on finding
any placeholder node -- you percolate the currying back up the tree until
you reach a node that satisfies any of the halting rules. At that point
you insert an "anonymous sub, curried" node over the expression subtree.
> > Implementation of the 'higher' pragma is left as an exercise to the
> > reader ;-)
>
> But as the proposer, it's your responsibility to make sure that
> someone thinks about it. Something that will cause as dramatic a
> change in the language as currying must address implementation, or
> it's just a useless wish that Larry will look at and say "well,
> yes, but can it be done without buggering the rest of Perl?" (perhaps
> not in those words :-)
>
> Considering implementation now will save us time later.
You're error is in assuming I have time *now*.
With 30+ RFCs still to write, I've been seriously contemplating
just abandoning the Perl 6 effort, because added to the demands
of my full-time job, my O'Reilly and other tutorial commitments,
my modules, and my poor long-suffering and cruelly-neglected wife,
the stress is beginning to affect seriously my health.
Requiring me to consider the implementation of things that are known (in
the CS literature) to be implementable, would definitely be the straw
that breaks this camel's back.
> You don't have to spec out data structures or grammar, but just
> show how it might be done.
See descriptions above.
Damian
