`is pure` trait and default parameters

user_10173009 0
Viewed 150

The following &greet function is pure, and can appropriately be marked with the is pure trait.

sub greet(Str:D $name) { say "Hello, $name" }
my $user = get-from-db('USER');
greet($user);

This one, however, is not:

sub greet { 
    my $name = get-from-db('USER');
    say "Hello, $name" 
}

greet($user);

What about this one, though?

sub greet(Str:D $name = get-from-db('USER')) { say "Hello, $name" }

greet();

From "inside" the function, it seems pure – when is parameters are bound to the same values, it always produces the same output, without side effects. But from outside the function, it seems impure – when called twice with the same argument, it can produce different return values. Which prospective does Raku/Rakudo take?

rakudo purely-functional raku functional-programming
2 Answers

There are at least two strategies a language might take when implementing default values for parameters:

  1. Treat the parameter default value as something that the compiler, upon encountering a call without enough arguments, should emit at the callsite in order to produce the extra argument to pass to the callee. This means that it's possible to support default values for parameters without any explicit support for it in the calling conventions. This also, however, requires that you always know where the call is going at compile time (or at least know it accurately enough to insert the default value, and one can't expect to use different default values in method overrides in subclasses and have it work out).
  2. Have a calling convention powerful enough that the callee can discover that a value was not passed for the parameter, and then compute the default value.

With its dynamic nature, only the second of these really makes sense for Raku, and so that is what it does.

In a language doing strategy 1 it could arguably make sense to mark such a function as pure, insofar as the code that calculates the default lives at each callsite, and so anything doing an analysis and perhaps transformation based upon the purity will already be having to deal with the code that evaluates the default value, and can see that it is not a source of a pure value.

Under strategy 2, and thus Raku, we should understand default values as an implementation detail of the block or routine that has the default in its signature. Thus if the code calculating the default value is impure, then the routine as a whole is impure, and so the is pure trait is not suitable.

More generally, the is pure trait is applicable if for a given argument capture we can always expect the same return value. In the example given, the argument capture \() contradicts this.

An alternative factoring here would be to use multi subs instead of parameter defaults, and to mark only one candidate with is pure.

user_78325840

When you say that a sub is pure, then the you are guaranteeing that any given input will always produce the same output. In your last example of sub greet it looks to me that you cannot guarantee that for the default value case, as the content of the database may change, or the get-from-db may have side-effects.

Of course, if you are sure that the database doesn't change, and there aren't any side-effects, you could still apply is pure to the sub, but why would you be using a database then?

Why would you mark a sub as is pure anyway? Well, it allows the compiler to constant-fold a call to a subroutine at compile time. Take e.g.:

sub foo($a) is pure {
    2 * $a
}
say foo(21);   # 42

If you look at the code that is generated for this:

$ raku --target=optimize -e 'sub foo($a) is pure { 2 * $a }; say foo(21)'

then you will see this near the end:

 │   │               - QAST::IVal(42)

The 42 is the constant folded call for foo(21). So this way the entire call is optimized away, because the sub was marked is pure and the parameter you provided was a constant.

user_74244700
Related