Delegating definitions in C# 3.0

Firstly, the concept of first-class functions, i.e. the invention of the function type, leads to the notion of closures. So for instance, a constant function such as

Func<int> i = () => 1;

defines something like a readonly variable. You may get it's value now, later or never, but you can always be sure that it's value won't be ever changed anywhere in your code. Hence, you have won a quantum of control over your program by this weird piece of code. That's a basic idea of functional programming.

The concept of function types leads to higher order functions, i.e. functions mapping functions to other functions. Thus, the curry functor, a key concept in the theory of functional programming, is regarded:

curry: (X x Y → Z) → (X → Y → Z)

That is, for any function f(x,y), there is a curryied function curry(f)(x) taking x to a function g(y) = f(x,y). This is now implemented easily in C# using generic types:

static Func<X, Func<Y, Z>> Curry<X, Y, Z>(Func<X, Y, Z> f)
{
  return x => y => f(x, y);
}

(inspired by this C# abuse of the day). Well, that's more or less of academic interest, since one would hardly ever replace x++ by

x = Curry<int, int, int>((a, b) => a + b)(1)(x); // x++ ;)

A slightly more interesting example is the following:

// using System.Text.RegularExpressions;
var grep = Curry<Regex, IEnumerable<string>, IEnumerable<string>>(
  (regex, list) => from s in list
                   where regex.Match(s).Success
                   select s);
var grepFoo = grep(new Regex("foo"));

Thus, grepFoo will grep all words containing "foo" from a wordlist. Attention should be paid to the fact that with the statement

var fooList = grepFoo(new string[]{"foo", "bar", "foobar"});

then there is still no regex applied. Indeed, fooList is of type IEnumerable<string> and not yet enumerated at this point. So the evaluation of the expression is deferred until it's result is needed by another computation - smells like lazy evaluation.

LINQ is not lazy!

One of the most important paradigms of functional programming is the concept of lazy evaluation. For instance, in a functional language, such as the good old Haskell, an expression such as

length [1, 2, 3/0]

evaluates to 3. That is, the control system is too lazy to fail on division by zero, neither at compile time nor on run time, since it doesn't need to know any element inside the array in order to calculate it's length. In C# (where you aren't even able to compile an expression such as 1/0), you may let

var q1 = from i in (IEnumerable<int>)new int[] { 1, 2, 3 }
         select 1/(i - 3);

without getting a run time error. But this has nothing to do with lazy evaluation, since the query expression isn't evaluated at all at this point (in contrast to the array definition inside the query), so the query expression is simply treated as a function definition. However, as soon as an aggregation expression such as

int three = q1.Count();

is reached, a DivideByZeroException will be thrown. Thus, LINQ evaluates eager here, not lazy. On the other hand,

int two = q1.Take(2).Count();

works fine, since the black hole stays unevaluated due to the Take operator. But, having

var q2 = from i in (IEnumerable<int>)new int[] { 1, 2, 3 }
         select 1/(i - 1);
int two2 = q2.Skip(1).Count();

instead, you will - guess what! - catch the exception again. Thus, in contrast to the Take operator, the Skip operator does iterate through skipped elements and hence evaluates them. Ok, that's no surprise, since these operators are using the IEnumerator provided by the corresponding IEnumerable. So, LINQ pretends to be lazy in the way that

var p = q2.Reverse();

won't be evaluated at this point and thus doesn't fail, wheras

int two3 = p.Take(2).Count();

then throws again the exception even though the evil one shuoldn't be taken here.

A functional approach to force lazyness would be to replace value expressions by constant functions, but the compiler won't accept something like this:

// The type of the expression in the select clause is incorrect.
// Type inference failed in the call to 'Select'.
var q1_ = from i in (IEnumerable<int>)new int[] { 1, 2, 3 }
          select () => 1 / (i - 3);

Hence, LINQ isn't lazy, but has a smart way to make function definitions looking like statement expressions.

Diving into recursion

Remember the famous

fib₀ = 0, fib₁ = 1, fib_n = fib_n-1 + fib_n-2.

The sequence starts with

fibs = 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, ...

where fibs₁₀₀ is a number consisting of 21 digits then, so it grows quite fast. Although one may calculate Fibonacci numbers in constant time using Binet's formula, the definition leads to interesting comparisons of different recursion strategies.

Well, lets have a

delegate long Fibonacci(int n);

A direct translation of the definition into a lambda recursion looks like this:

Fibonacci fib1 = null; // pre-assigned for use within recursion
fib1 = n => n <= 1 ? n : fib1(n - 1) + fib1(n - 2);

The funny thing with this implementation is, that the Fibonacci function itself determines it's run time: It's O(fib_n), i.e. lower values will be recalculated many times again and again in order to get a higher one, due to the lack of an aggregating strategy.

Now, in Haskell you may get around this very elegantly by defining an infinitive list:

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

The list is inititialized with two elements. Then, notional, the tail function shifts the first element from the fibs list, while zipWith (+) creates a new list by adding elements of both fibs and (tail fibs) with each other then. But in practice, Haskell is smart and lazy enough to avoid any needless recalculation of numbers already present in the fibs list. Thus, the algorithm applied here is the same one a human being would apply spontaneously using a pencil and a chit of paper. So, it's O(n).

To define an infinitive list in C#, one should implement the IEnumerable interface in the way that the corresponding IEnumerator expands the list on demand within it's MoveNext() method then. Here, it's enough to have a little inliner, taking a list and an expanding function to a Fibonacci type:

Func<
  IEnumerable<long>,
  Func<IEnumerable<long>, IEnumerable<long>>,
  Fibonacci> infList = null;
infList = (list, exp) => n => n < list.Count() ?
  list.Skip(n).First() : infList(exp(list), exp)(n);

Now, C# also provides a Zip function. So, a simple syntactic translation of the Haskell list would look like this:

Func<IEnumerable<long>, IEnumerable<long>> fibZip = fibs =>
  fibs.Take(2).Concat(fibs.Zip(fibs.Skip(1), (x, y) => x + y));

Hm, but this one is even worse than the naive recursion. Indeed, trying

Fibonacci fib2 = infList(new long[] { 0, 1 }, fibZip);

then, you will see that aggregation doesn't work at all this way, since the concept of enumeration is not functional. We may repair the fibZip as follows:

Func<IEnumerable<long>, IEnumerable<long>> fibZip2 = fibs =>
  fibs.Concat((IEnumerable<long>)(new long[] {
    fibs.Skip(fibs.Count() - 2).Sum() }));

This one looks a bit weird, since it's not that easy to extend an IEnumerable by one element. Anyway,

Fibonacci fib3 = infList(new long[] { 0, 1 }, fibZip2);

indeed does the job in O(n) then, even though the idea of an infinitive list has lost it's magic this way.

Conclusion

As expected, neither C# nor LINQ turns out to implement the paradigms of a functional language. None the less, it's really fancy. 8-)

for, far, bar, foo, boofaz, boofar, boof, faz, foobaz, foobars, boofar

be your wordlist. Now, you may apply the according regualar expression:

(1) /\b(for|far|bar|foo|boofaz|boofar|boof|faz|foobaz|foobars|boofar)\b/

But which way a regex engine would implement the assignment? There are different options. The very worst algorithm would be surely to look up every word separately in the whole text. That would be the same as doing

foreach (qw( for far bar foo boofaz boofar boof faz foobaz foobars boofar ))
{
  return "matching!" if $text =~ m/\b$_\b/;
}
return "not matching.";

Assumed you would match m words against a text consisting of n letters, this peace of coding horror would have a runtime estimation of O(m*n).

Now, a better approach would be to run only once through the text, using a matching stack. Thus, assume " foobar " would appear somewhere in the text, the stack trace might look as follows then (read from bottom to top):

[7] ' ' => nothing matches.
[6] 'r' => "foobars" might match.
[5] 'a' => "foobaz" or "foobars" might match.
[4] 'b' => "foobaz" or "foobars" might match.
[3] 'o' => "foo", "foobaz", or "foobars" might match.
[2] 'o' => "for", "foo", "foobaz", or "foobars" might match.
[1] 'f' => "for", "far", "foo", "faz", "foobaz", or "foobars" might match.
[0] ' ' => "\b" matches.

So, but what if the wordlist is getting large? It seems that we should run nearly through the whole list each time a character is pushed onto the stack in order to find out whether the current stack contents still may be matched or not.

It's clear that a considerable optimization would be to sort the word list in advance. Moreover, instead of looking up one item after another, a really smart approach would be to walk downwards a search tree instead. As a tree, the wordlist above would appear like this:

          _____________|_____________
          |                         |
          b                         f
    ______|______        ___________|___________
    |           |        |                     |
   oof          ar       a                     o
    |                 ___|___            ______|______
    a ?               |     |            |           |
 ___|___              r     z            o           r
 |     |                                 |
 r     z                                 ba ?
                                     ____|____
                                     |       |
                                     rs      z

Here, the "?" denotes an optional node. Remember the length of the way downwards such a tree is in logarithmic relation to the number of nodes. Thus, loosely speeking, we have improved the worst algorithm above up to O(n*log(m)) at least.

Actually I'm not sure whether regex engines would apply optimizations like that when compiling. I guess they do, so it might be needless to replace the regex (1) above by the optimized version, implementing the sorted tree of alternative and optional nodes:

(2) /\b(b(?:ar|oof(?:a(?:r|z))?)|f(?:a(?:r|z)|o(?:o(?:ba(?:rs|z))?|r)))\b/

Nevertheless I couldn't help to create a little Perl routine that folds a wordlist into an optimized regex. Now, here it is:

sub foldWordsToRegex {

  local *toString = sub {
    ## node: [ prefix, [ nodes ], opt ]

    my ($prefix, $nodes, $opt) = ${$_[0]};
    my $rv = quotemeta $prefix;
    if ( ref $nodes eq q|ARRAY| && @$nodes )
    {
      $rv .= '(?:'.(join '|', map { toString($_) } @$nodes).')';
      $rv .= '?' if $opt;
    }
    $rv;
  };

  local *fold = sub(@_) {

    sub reduce($);
    local *reduce = sub {
      my ($prefix, $nodes, $opt) = ${$_[0]};

      return $_[0] unless ref $nodes eq q|ARRAY| && @$nodes > 1;

      ## 1st char of the prefix of 1st node in list
      my ($c, $qc);

      ## check whether 2nd prefix starts with same letter as the 1st
      if ( length $nodes->[0][0] )
      {
        $c = substr $nodes->[0][0], 0, 1;
        $qc = quotemeta $c;
        $nodes->[1][0] =~ m/^$qc/ or undef $c;
      }

      unless ( defined $c )
      {
        return $_[0] unless @$nodes > 2;

        ## try to reduce next list part
        my $first = shift @$nodes;
        my $next = reduce ['', $nodes, 0];
        return [ $prefix, [ $first, $next ], $opt] if length $next->[0];

        ## couldn't be reduced
        return [ $prefix, [ $first, ${$next->[1]} ], $opt ];
      }

      ## reduce any ensuing node whose prefix starts with $c
      my @new;
      my $newopt = 0;
      while ( @$nodes )
      {
        $nodes->[0][0] =~ s/^$qc// or last;

        ## reduce node or detect new optional node
        my $n = shift @$nodes;
        if ( length $n->[0] )
        {
          push @new, $n;
          next;
        }
        $newopt = 1;
      }

      if ( @$nodes || $opt )
      {
        my $new = reduce [ $c, [ @new ], $newopt ];
        if ( @$nodes )
        {
          ## reduce remaining nodes
          my $next = reduce ['', $nodes, 0];
          return [ $prefix, [ $new, $next ], $opt] if length $next->[0];

          ## couldn't be reduced
          return [ $prefix, [ $new, ${$next->[1]} ], $opt ];
        }

        ## current node is optional
        return [ $prefix, [ $new, @$nodes ], $opt ];
      }

      ## nothing left to reduce
      reduce [ $prefix.$c, [ @new ], $newopt ];
    };

    reduce [ '', [( map { [$_] } sort @_ )], 0];
  };

  toString(fold(@_));
};

Well, not so easy, but it works :)

Here, the inner recursion fold will create the actually tree, where nodes having the form of arrays consisting of prefix, subnodes and a flag denoting optional nodes. The second inner function toString then creates the actual regular expression string from that tree. So, for instance, calling

&foldWordsToRegex(qw( for far bar foo boofaz boofar boof faz foobaz foobars boofar ))

would return the regex (2).