Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^5: Specializing Functions with Currying

by jryan (Vicar)
on Aug 06, 2004 at 21:03 UTC ( #380720=note: print w/ replies, xml ) Need Help??


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

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 }


Comment on Re^5: Specializing Functions with Currying
Select or Download Code
Re^6: Specializing Functions with Currying
by stvn (Monsignor) on Aug 06, 2004 at 21:56 UTC
    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

      Why be functional when you can be efficient? Recursion might be elegant, but computers don't really understand elegance. :) Functional programming has a lot of great and useful concepts in it, and luckily we use a language that doesn't *force* us to be purists about it.

      P.S.: The variable assignment is very necessary in my second example, because otherwise you're going to get a circularly referenced subroutine, which will make perl hit a infinite recursion warning pretty damned quick.

      P.P.S: And, you're right, your last version is even better!

        Actually programming languages that understand tail-recursion would have made stvn's solution both elegant and efficient.

        That said, some algorithms just cannot be efficiently implemented in a "pure" functional manner. A good example is the Sieve of Eratosthenes.

        Why be functional when you can be efficient

        Spoken like a true Electrical Engineering Major ;-)

        Functional programming has a lot of great and useful concepts in it, and luckily we use a language that doesn't *force* us to be purists about it.

        I agree with you on both points. However, as tilly points out, recursion (and other functional programming goodies) don't have to be inefficient. I would encourage you to check out Standard ML, and in particular its compilation model (which I can't find any good links to at the moment, but I will post them when I find them). ML is a fast functional language, and according to the (inherently flawed) computer language shootout one of the fastest (faster than C++ in some cases). In addition there are some really fast LISP implementations out there too as well.

        Basically with a good compiler, you can be functional and efficient.

        -stvn

      For full equivalence you need to not spoil the aliasing of @_ for the first call. Replace all @args with @_ and you're home safe. (The @_ assignment later breaks the aliasing as it should.)

      Cheers,
      ihb

      Read argumentation in its context!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://380720]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (12)
As of 2014-09-17 20:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (99 votes), past polls