Re: A "Fun"ctional Attempt

It should be noted that the code is not so strict since it assumes the existence of local variables.

Package global variables, actually. And it’s easy to make it work under strict:

use strict;
use warnings;
use HOI::Comprehensions;
use HOI::Match;

sub slowsort
{
    HOI::Match::pmatch
    (
        'nil' => sub { [] },
        'pivot :: unsorted' =>
        sub
        {
            our ($x, $unsorted, $pivot);
            my $left  = HOI::Comprehensions::comp( sub { $x }, x => $u
+nsorted )->( sub { $x <= $pivot } );
            my $right = HOI::Comprehensions::comp( sub { $x }, x => $u
+nsorted )->( sub { $x >  $pivot } );
            return [ @{slowsort($left->force)}, $pivot, @{slowsort($ri
+ght->force)} ];
        },

    )->(@_)
}

my $res = slowsort [3, 4, 1, 2, 5, 6];
print @$res, "\n";
[download]

Output:

19:35 >perl -c 1262_SoPW.pl
1262_SoPW.pl syntax OK

19:37 >perl 1262_SoPW.pl
123456

19:37 >
[download]

I see from that you are the author of the HOI::Comprehensions and HOI::Match modules. For the benefit of those of us who don’t know as much as we’d like about functional programming, perhaps you could give some explanation of what the code is doing, and of its advantages over equivalent code written in the imperative or object oriented paradigms?

Thanks,

Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

Comment on Re: A "Fun"ctional Attempt Select or Download Code

Replies are listed 'Best First'.
Re^2: A "Fun"ctional Attempt by withering (Monk) on Jun 04, 2015 at 13:59 UTC
Thanks for reply and the workaround under "use strict". The solution works well, although it is a little different from my own consideration, which hopes that those variables need no declaration. The demo code give such an algorithm - it looks like quicksort, but it's simpler and much slower. The function takes a list, taking its first element as a "pivot". Then the remaining list (tail of the list), namely "unsorted", is divided into two sub-lists: one contains elements which are no bigger than the pivot, and the other contains elements which are bigger than the pivot. The same process is applied to the two sub-lists unless the argument list is empty. Quicksort is much faster, for it costs less time when dividing the original list. In addition, the strategy to choose a pivot is sometimes ingenious. As for advantages of functional style over other paradigms, my opinion is that most of the time a piece of code which follows functional paradigm runs under a heavier burden, perhaps from its runtime mainly. However, there are reasons for following such discipline: 1. To think from a different perspective, which tells one to focus on functions and their composition, encourages one to write operators (i.e. functions that return functions) as glue between operations. Thus, some achievement in reusability could be somewhat reached. 2. More or less, such discipline encourages one to write smaller functions with clearer boundaries. I myself usually consider functional paradigm able to be graceful. It's actually not always graceful, however.	[reply]

Replies are listed 'Best First'.

Re^2: A "Fun"ctional Attempt
by withering (Monk) on Jun 04, 2015 at 13:59 UTC

Thanks for reply and the workaround under "use strict". The solution works well, although it is a little different from my own consideration, which hopes that those variables need no declaration.

The demo code give such an algorithm - it looks like quicksort, but it's simpler and much slower. The function takes a list, taking its first element as a "pivot". Then the remaining list (tail of the list), namely "unsorted", is divided into two sub-lists: one contains elements which are no bigger than the pivot, and the other contains elements which are bigger than the pivot. The same process is applied to the two sub-lists unless the argument list is empty.

Quicksort is much faster, for it costs less time when dividing the original list. In addition, the strategy to choose a pivot is sometimes ingenious.

As for advantages of functional style over other paradigms, my opinion is that most of the time a piece of code which follows functional paradigm runs under a heavier burden, perhaps from its runtime mainly. However, there are reasons for following such discipline:

1. To think from a different perspective, which tells one to focus on functions and their composition, encourages one to write operators (i.e. functions that return functions) as glue between operations. Thus, some achievement in reusability could be somewhat reached.

2. More or less, such discipline encourages one to write smaller functions with clearer boundaries.

I myself usually consider functional paradigm able to be graceful. It's actually not always graceful, however.

[reply]