Parameterized Functions

I was recently playing around with Perl 6 , where I encountered dynamic variables , which are looked up in the dynamic scope at runtime. This means that it is possible to shadow variables on the call stack instead of through lexical scoping. When I was thinking about the implications of that concept, I realized that it should be possible to use it to parameterize functions without explicitly passing arguments.

Some languages supply similar concepts explicitly. Personally, I know this concept from Racket , where it could be used to write something like this:

 1#lang racket
 2
 3(define parameter (make-parameter "defaulted"))
 4
 5(define (parameterized #:parameter (param (parameter)))
 6	; well, this was easy
 7	(displayln param))
 8
 9; usage:
10(parameterized)
11(parameterize ([parameter "value1"])
12	(parameterized)
13	(parameterize ([parameter "value2"])
14		(parameterized)
15		(parameterized #:parameter "value3"))
16	(parameterized))
17(parameterized)

This code snippet combines three important features:

1. It is possible to define a default parameter (defaulted) that is used in absence of any user-defined parameters.
2. The default-parameter can be shadowed in the dynamic scope. The parameter is not permanently changed, but only overridden for the lifetime of the parameterized invocation.
3. The function can still be called with the parameter as an optional keyword argument that is then used instead.

So, how would this look in Perl 6? Even simpler, as it turns out:

 1sub parameterized(:$parameter = $*parameter // "defaulted") {
 2	# well, this was easy
 3	say $parameter;
 4}
 5
 6# usage:
 7parameterized();
 8{
 9	parameterized();
10	my $*parameter ::= "value1";
11	parameterized();
12	{
13		my $*parameter ::= "value2";
14		parameterized();
15		parameterized(:parameter("value3"));
16	}
17	parameterized();
18}
19parameterized();

The code has the exact same semantics as the one used in the Racket version. Note that $*parameter is not even lexically defined on the outmost scope!

At this point it should be noted how important it is for either of the previous implementations that the default argument is evaluated every time the function is called.

I tend to spout commonalities like "C++ can do anything all the other languages do, it just might be less convenient!". Sooo… Time to put my money where my mouth is!

The basic idea is rather simple again: Use a thread_local variable that contains the current parameterization and constructors and destructors to change it to and fro. This way the parameter stays changed for the lifetime of an object, and is reverted afterwards¹. I have to use an optional positional argument instead of using a keyword argument, as keyword arguments are not natively supported in C++ (of course there always is Boost …).

Naturally, while it is possible to build it, it is significantly more complicated to do so than it was in either Perl 6 or Racket:

 1#include <vector>
 2#include <iostream>
 3
 4void parameterized(char const*);
 5
 6class parameter_t {
 7	friend void parameterized(char const*);
 8	static thread_local char const* parameter;
 9	char const* old_parameter;
10
11public:
12	parameter_t(char const* str) : old_parameter(parameter)
13	{ parameter = str; }
14
15	~parameter_t() { parameter = old_parameter; }
16};
17
18thread_local char const* (::parameter_t::parameter) = "defaulted";
19
20void parameterized(char const* str = ::parameter_t::parameter) {
21	// Finally, the actual function!
22	::std::cout << str << "\n";
23}
24
25// usage:
26// parameter_t custom_default("custom default"); // this works!
27int main() {
28	parameterized();
29	{
30		parameterized();
31		parameter_t _("value1");
32		parameterized();
33		{
34			parameter_t _("value2");
35			parameterized();
36			parameterized("value3");
37		}
38		parameterized();
39	}
40	parameterized();
41}

Use cases

So, where does one actually use such a construct? What purpose does it serve beyond simple entertainment of creating it?

My favorite example is that of functions that create output. I have lost track of how often I had to pass ::std::cout explicitly², instead of just specifying it as the output stream once. While it is possible³ to change the standard output, it is very non-generic, requiring additional efforts on the behalf of the programmer.

Another common case in which this might be interesting is for programs that are built as a big library with a small driver – like for example Clang. Since the library should not have state with static storage duration, unless absolutely necessary, program options have to be chained through all functions until they are needed.