Comments on nothingmuch's perl blog: Functional programming and unreasonable expectatio...

It should have been "The 'number' method is not pu...

2009-11-21T11:36:09.844+02:00

It should have been "The 'number' method is not purely functional because it changes the state of the object which is in the outside scope"

Rewording what I said at IRC. The benefit of usin...

2009-11-21T11:34:51.790+02:00

Rewording what I said at IRC. The benefit of using a functional language is that you get perfect isolation, this is because there is no state. But with imperative languages you can also write code that is purely functional - you just need to isolate the state. This means you use only subs that don't change global Perl state and don't use any variables from outer scope. But it does not mean that they use only other pure functions. Here is an example:

package Adder;
use Moose;

has number => ( is => 'rw' );

sub add {
my ( $self, $value ) = @_;
return $value + $self->number;
}

package PureFunctional;

sub add_four {
my $value = shift;
my $adder = Adder->new;
$adder->number( 4 );
return $adder->add( $value );
}

The 'add' method is not purely functional because it changes the state of the object which is in the outside scope - but the add_four sub is purely functional because that object is an automatic variable of that sub.

The point is that if we had that hypothetical 'use pure' pragma we would have a language that gives you the convenience of imperative programming together with the safety of functional programming.

You are assuming that receiving a message is an op...

2009-11-21T10:16:32.754+02:00

You are assuming that receiving a message is an operation with side effects. In the context of the blog post it would really be more appropriate to rail on Perl.

@Sterling: Purely functional means side-effect fre...

2009-11-21T00:40:25.993+02:00

@Sterling: Purely functional means side-effect free and not mutation free. Erlang allows uncontrolled side effects (message passing) and, therefore, is not purely functional.

Bugs introduced by purely functional programming typically fall into three categories: stack overflows, unusable performance and unusable memory consumption. The former is a consequence of avoiding loops and the latter is a consequence of laziness (which renders performance and memory consumption unpredictable).

Well, what would you do with it? You can walk the...

2009-11-20T17:20:22.229+02:00

Well, what would you do with it?

You can walk the optree and unless all of the ops are known pure (or have known pure implications in the context, such as an entersub whose subroutine child op is refers to a GV that contains a CV that is also known pure) return false. This check can be improved incrementally.

Once you have that you can write a B::Util::CheckPurity or something, which can check for the purity of a given subroutine easily.

With that you could then do interesting things, but the question is what =)

Some ideas:

1. Memoize::Automatically
2. a pragma to assert that all the subroutines declared in a certain scope must be pure unless otherwise excluded
3. debugging aids maybe?

...

OK - so for the simple cases it is trivial - we co...

2009-11-20T17:13:30.950+02:00

OK - so for the simple cases it is trivial - we could have a list of pure and impure operations and then add to the list of impure all subs that use anything impure. If the editor highlighted for you the impure operations in a different colour - then you'd not make your mistake. The question is if this is enough to be useful, if your particular case is common enough.

@zby - statically inferring that a subroutine is p...

2009-11-19T19:57:41.188+02:00

@zby - statically inferring that a subroutine is purely functional is trivial for the simple case - just prove it has no impure opcodes.

The problem is knowing which opcodes are pure and which are impure.

For example it turns out that matching a regex is impure because it's nonreentrant, but I never would have expected that since all of the input parameters are provided for it lexically in the Int validator.

Purely functional does not imply that the language...

2009-11-19T19:17:08.738+02:00

Purely functional does not imply that the language restricts to that, I write purely functional Perl every day, and it's about as impure as you can get.

The point of the post is that purely functional components, regardles of whether or not they are written in a purely functional language are in generall more composable and reusable.

Ironically, while Git is implemented mostly in C it uses a largely purely functional model (everything but references is immutable), whereas darcs initially chose a mutable data model, which was part of the issues that plagued version 1. Git (at it's core) is much more pure than darcs.

dunno why i'm bothering to respond to a typical jd...

2009-11-19T18:18:29.417+02:00

dunno why i'm bothering to respond to a typical jdh troll but here it goes -- erlang is indeed purely functional (i.e. there is no mutation) and the problems with darcs (which is still quite popular, actually, and actively maintained, and whose standout problems have been fixed) were with regards to the time taken by certain algorithms, not with regards to anything else.

And jdh has absolutely no grounding for his last statement at all -- one can write perfectly nice purely functional code in ocaml or f# or what have you, and its just plain silly to say that avoiding side-effects somehow can "introduce bugs".

"Another reason I like it so much is that purely f...

2009-11-19T16:42:32.843+02:00

"Another reason I like it so much is that purely functional software tends to be more reliable. Joe Armstrong of Erlang fame makes that point in an excellent talk much better than I could ever hope to."

On the contrary, Erlang is reliable but not purely functional and, in fact, the only software ever written entirely in a purely functional language (Darcs, written in Haskell) and that garnered a significant user base (of only a few thousand users) was subsequently dropped by those users precisely because it was plagued with reliability (and performance) problems.

In reality, trying to use purely functional programming to solve many real problems introduces more bugs than it catches.

This is probably a pie in the sky - but wouldn't i...

2009-11-19T13:14:28.551+02:00

This is probably a pie in the sky - but wouldn't it be nice if it was possible to declare a sub as purely functional? Then the parser would check if there is any call to anything unsafe. It would have to be over-restrictive and not all purely functional code could be declared as such - but I think it could work for a class of subs. In a way it would work for subs as taint works for vars.

my solution was pushing [ $thunk_coderef, $^N ] an...

2009-11-19T07:11:47.268+02:00

my solution was pushing [ $thunk_coderef, $^N ] and then applying all of those after the match finished

In a former life I wrote Regexp::Approx at http://...

2009-11-19T07:09:05.974+02:00

In a former life I wrote Regexp::Approx at http://perlmonks.org/?node_id=306474 which forks off another interpreter to run reentrant regexp code. :-(

I ran into this exact same problem two weeks ago, ...

2009-11-19T02:20:43.483+02:00

I ran into this exact same problem two weeks ago, though not in moose - I was trying to be clever and got bitten by my *own* code.

This sort of issue is a good illustration of your point about functional and re-entrant code... though I hope the average reader sees that and not "omg the perl regex engine is bad!!1!" To be fair, I would want to point out that the regex docs are pretty clear that the (?{}) and (??{}) constructs are dangerous and experimental... and non-reentrant! :-)