http://www.perlmonks.org?node_id=380444

in reply to Re^2: Specializing Functions with Currying
in thread Specializing Functions with Currying

'boldital' => do { my \$i = curry \&wrap_with_html => ( 'i' ); my \$b = curry \&wrap_with_html => ( 'b' ); sub { \$b->( \$i->( @_ ) ) } },

Neat use of =>. As for composition, as an inveterate Haskell hacker (well, hacker-wannabe), I'd prefer to have that as a primitive, too:

sub compose { my (\$f, \$g) = @_; return sub { \$f->(\$g->(@_)); } } # ... 'boldital' => &compose(&curry(\&wrap_with_html, 'i'), &curry(\&wrap_with_html, 'b')),
The idea of functions that operate on functions and return other functions is much more useful than it first seemed to me. If you never think about functions as first-class objects, having a compose function seems incredibly redundant. Once you start building functions on-the-fly, composition becomes indispensible.

I guess I should write part 2 of my Perlesque Intro to Haskell, then.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
% man 3 strfry

Replies are listed 'Best First'.
Re^4: Specializing Functions with Currying
by stvn (Monsignor) on Aug 06, 2004 at 13:46 UTC

Why limit compose to just two functions?

sub compose { my (\$f, \$f2, @rest) = @_; return \$f unless defined \$f2; return &compose(sub { \$f2->(\$f->(@_)) }, @rest); } *bold_italic_and_underlined_paragraph = compose( &curry(\&wrap_with_html, 'u'), &curry(\&wrap_with_html, 'b'), &curry(\&wrap_with_html, 'i'), &curry(\&wrap_with_html, 'p') ); print bold_italic_and_underlined_paragraph("test");

-stvn

Of course, that's just asking for it.

my \$biup = compose map curry( \&wrap_with_html, \$_ ), qw( p u i b );

Now that actually looks like a construct you're likely to see in some flavour of functional programming language.

Makeshifts last the longest.

Why recurse when you can iterate instead? :)

use List::Util qw(reduce); sub compose { reduce { sub { \$b->(\$a->(@_)) } } @_; }

Of course, that doesn't actually work because Perl's reduce uses global variables (\$a,\$b). But, we can roll our own:

sub compose { my \$c = shift; foreach my \$s (@_) { my \$o = \$c; \$c = sub { \$s->(\$o->(@_)) } } \$c }
Why recurse when you can iterate instead? :)

*gasp* .... thats not very functional! (I wont even bring up the fact you are using variable assignment, tssk tssk)

If we really want to be "efficient" about it, we would avoid the overhead of the wrapper subroutine, and just use straight perl's closures.

sub compose { my (@funcs) = @_; return sub { my (@args) = @_; foreach my \$func (@funcs) { @args = \$func->(@args); } return @args; }; }
But really, that takes all the fun out of it ;-)

-stvn
Re^4: Specializing Functions with Currying
by Aristotle (Chancellor) on Aug 06, 2004 at 04:38 UTC

I had seen that some primitive exists for this kind of thing in functional programming, but I have never gotten past a brief foray into that world. My first contact with a number of functional concepts was through Perl, and ever since I've meant to learn a serious functional language. It hasn't happened yet…

For anyone looking for an introduction to functional concepts in Perl, Mark-Jason Dominus' Higher Order Perl book is well worth a look… or will be once it's finished.

Makeshifts last the longest.