public static IEnumerable<T> Map<F,T>(Func<F,T> func, IEnumerable<F> source)
{
    return
        from it in source
        select func(it);
}

Actually, it’s trivial to implement without the new syntax (although I’ve left in Func because it’s nicer than defining a separate delegate):

public static IEnumerable<T> Map<F,T>(Func<F,T> func, IEnumerable<F> from)
{
    foreach (F it in from)
        yield return func(it);
}

But why stop at map? We can also define a fold:

public static T FoldL<F, T>(Func<T, F, T> func, IEnumerable<F> source, T init)
{
    T last = init;
    foreach (F it in source)
        last = func(last, it);
    return last;
}

Or the non-empty-list variant. This is made easier through the query operator Skip:

public static T FoldL1<T>(Func<T, T, T> func, IEnumerable<T> source)
{
    T last = source.First();
    foreach (T it in source.Skip(1))
        last = func(last, it);
    return last;
}

Finally, a simple compose operator for sticking two functions together, again using the nicer syntax to make this simple:

public static Func<X,Z> Compose<X,Y,Z>(this Func<Y,Z> second, Func<X,Y> first) {
    return x => second(first(x));
}

Example

A simple example including functionality from each part above (I put everything into an FFC utility class):

int[] numbers = { 1, 2, 3, 4, 5 };
Func<int, int> addOne = n => n + 1;
 
foreach (var k in FFC.Map(addOne, numbers))
    Console.Write(k + " ");
Console.ReadLine();
 
Func<int,int> addTwo = addOne.Compose(addOne);
 
foreach (var k in FFC.Map(addTwo, numbers))
    Console.Write(k + " ");
Console.ReadLine();
 
var sum = FFC.FoldL((x, y) => x + y, numbers, 0);
Console.Write(sum + " ");
Console.ReadLine();

A first attempt

The first thing I thought of was to implement them using an IEnumerable with yield statements, so I began with a construction borrowed from Haskell: the iterate function.

static class FakeLazyList
{
    public static IEnumerable<T> Iterate<T>(Func<T, T> f, T x)
    {
        while (true)
        {
            yield return x;
            x = f(x);
        }
    }
}

While this works (try FakeLazyList.Iterate(i => i + 1, 0)), it is obviously a poor solution; it is not flexible as it requires a seperate function to be written for every incarnation.

Lazy data in general

My next approach was to begin with creating a generic type for lazy data. All it has to do is act as a wrapper for a piece of data. However, since in C# arguments must be evaluated before they are used, the data must in turn be wrapped inside a delegate so that the delegate’s execution can be postponed. This resulted in:

public class Lazy<T> 
{
    public Lazy(Func<T> del)
    {
        Del = del;
    }
    private Func<T> Del;
    private T PValue;
    private bool HasValue = false;
    public static implicit operator T(Lazy<T> f)
    {
        if (!f.HasValue)
        {
            f.PValue = f.Del.Invoke();
            f.HasValue = true;
        }
        return f.PValue;
    }
}

As you can see, execution of the data-bearing delegate is delayed until the lazy data is forced to become normal data.

Implementing the list

For the list implementation itself, I chose to go with the traditional cons list structure, so that each list item has an object of data, and a pointer to the next item in the list. In order to make the list lazy, the next item of the list should be generated only on-access, so it is wrapped in the above Lazy<T> class.

public class LazyList<T> : IEnumerable<T>, IEnumerable
{
    private T _First;
    private Lazy<LazyList<T>> _Rest;
 
    public T First { get { return _First; } }
    public LazyList<T> Rest { get { return _Rest; } }
 
    public LazyList(T first, Lazy<LazyList<T>> rest)
    {
        _First = first; _Rest = rest;
    }

Next comes some boilerplate so that the class can be used as an enumerable structure:

    public IEnumerator<T> GetEnumerator() {
        return new Enumerator(this);
    }
    IEnumerator IEnumerable.GetEnumerator()
    {
        return new Enumerator(this);
    }
 
    private class Enumerator : IEnumerator<T>, IEnumerator
    {
        private LazyList<T> curr = null;
        private LazyList<T> next;
        public Enumerator(LazyList<T> parent)
        {
            next = parent;
        }
        /* must implement both interfaces */
        object IEnumerator.Current { get { return this.Current; } }
        public T Current {
                get {
                    if (curr == null)
                        throw new InvalidOperationException();
                    else
                        return curr._First;
                }
        }
 
        public bool MoveNext() { curr = next; next = next._Rest; return curr != null; }
        public void Reset() { throw new NotSupportedException(); }
        public void Dispose() { return; }
    }

Last of all comes a couple of utility functions for constructing lists, both of which I took from Haskell. The first, iterate, generates a list of items by taking a function f and a datum x and generating the list like this [x,f(x),f(f(x)),f(f(f(x))),...].

    public static LazyList<X> Iterate<X>(Func<X, X> f, X x)
    {
        return new LazyList<X>(x, new Lazy<LazyList<X>>(delegate { return Iterate(f, f(x)); }));
    }

The next takes a datum and generates the infinite list of just that datum:

    public static LazyList<X> Repeat<X>(X x)
    {
        return new LazyList<X>(x, new Lazy<LazyList<X>>(delegate { return Repeat(x); }));
    }
}

As you can see, the usage of the LazyList constructor isn’t the most elegant. I had hoped that I would be able to use an implicit operator on the Lazy class, such as:

public static implicit operator Lazy<T>(Func<T> f)
{
    return new Lazy<T>(f);
}

… and then use it like this …

new LazyList<X>(x, () => Repeat(x));

Unfortunately, this doesn’t work, giving error CS1660. Apparently the C# compiler cannot use the fact that an implicit cast has been defined. Still, this implementation works well.

Usage

The usage of the LazyList in normal code is very simple, and as shown in this example, you can also use the new C# 3.0-defined list operators Take, Drop, Where etc:

IEnumerable<int> ys;
 
// Lazy list of all positive integers
ys = LazyList<int>.Iterate(i => i + 1, 0).Take(20);
foreach (var y in ys) Console.WriteLine(y);
 
//Lazy list of [89, 89, 89, 89, ...]
ys = LazyList<int>.Repeat(89).Take(20);
foreach (var y in ys) Console.WriteLine(y);
 
Console.ReadLine();

A Comparison

Firstly, I’ll show a short comparison between some Java code and some code from a language that doesn’t have NullPointerExceptions, but does have something that allows you to accomplish anything you might want to do with null pointers.

This Java code:

AnObject thing = someMethod();

is equivalent to the following Haskell:

let thing = Maybe AnObject

That is, every Java object reference is possibly null. What this means is that (using the type notation mentioned in earlier posts) every Java reference has the type:

(Every object reference for an object is either to ‘null’ (AKA ‘unit’ or ‘singleton’, or the object itself.)

… and when you’re dealing with so many objects—Java is, after all, an object-oriented language, so (almost) everything is an object—this simple little “+1″ gets lost easily.

Why so bad?

This wouldn’t seem to be such a big deal, but when contrasted against Java’s penchant for making things (sometimes painfully) explicit—think public static void main (string argh!)—a small, implicit item like this is easily overlooked. Conversely, one might say that the verbosity of Java increases the cognitive load of understanding its code; thus helping the chances of a small mistake like this sneaking through.

Either way, I think I can say that this is objectively A Bad Thing. C# has gone some of the way to a ‘correct’ solution in its introduction of possibly-null primitives, which are explicitly marked with a ? (such as int?), but unfortunately this hasn’t been ‘back-ported’ to the rest of the language. If one were able to force between possibly-null and definitely-not-null references in C#—perhaps by the analogous object? vs. object, this would help to reduce the number of errors ‘hidden’ by the syntax.

I was bored, and it didn’t seem to have been done before, so here’s some Future action in C#.

The Code

using System;
using System.IO;
using System.Reflection;
using System.Threading;
 
public class Future<T> {
        public delegate R FutureDelegate<R>();
        public Future (FutureDelegate<T> del) {
                Del = del;
                Result = del.BeginInvoke(null,null);
        }
        private FutureDelegate<T> Del;
        private IAsyncResult Result;
        private T PValue;
        private bool HasValue = false;
        private T Value {
                get {
                        if (!HasValue) {
                                if (!Result.IsCompleted)
                                        Result.AsyncWaitHandle.WaitOne();
                                PValue = Del.EndInvoke(Result);
                                HasValue = true;
                        }
                        return PValue;
                }
        }
        public static implicit operator T(Future<T> f) {
                return f.Value;
        }
}
 
public static class MainClass {
        //This is purposely wasteful!
        public static ulong Fib(ulong n) {
                if (n > 1) {
                        return Fib(n-1)+Fib(n-2);
                }
                else if (n == 1)
                        return 1;
                else //n == 0
                        return 0;
        }
        //Demo using futures.
        public static void Main(string[] args) {
                Console.WriteLine("First, call synchronously.");
                Console.WriteLine(Fib(40));
                Thread.Sleep(1000);
                Console.WriteLine("Next, call asynchronously.");
                Future<ulong> fib40 = new Future<ulong>(delegate{
                        return Fib(40);
                }); //Begins computing Fib(40) at this point...
                Thread.Sleep(1500);
                Console.WriteLine("Note that we can do other things in the mean time, and that the thread only blocks when we ask for the value.");
                Console.WriteLine(fib40); //Need it now!
                Thread.Sleep(2000);
                Console.WriteLine("We can then ask for the computed value as many times as we like.");
                Console.WriteLine(fib40); //Already computed.
        }
}

Caveats

Most notably, this doesn’t do promise pipelining (and I doubt I could without some compiler magicking), so instead of nesting futures, you’ll want to seperate them out. That is; instead of:

t3 = new Future(delegate{return new Future(delegate{return x.a()}).c(new Future(delegate{return y.b()}))});

…you’ll want to do:

t1 = new Future(delegate{return x.a()});
t2 = new Future(delegate{return y.b()});
t3 = new Future(delegate{return t1.c(t2)});

…although you’d probably want to do this anyway if you don’t want to wander into The LispZone.

First up is DejaVu Sans, which is my default sans-serif font on my system. It is quite plain looking which is possibly a good thing as it doesn’t distract from the task at hand. The ’0′ and ‘O’ characters are different enough, but you may have problems with ‘I’ and ‘l’.

Next I tried Candara, which is a new font that is bundled with Windows Vista. It has a bit of character, but the text figures are a bit distracting, and the punctuation really doesn’t fit in nicely with the rest of the font.

Finally I picked URW Gothic. While this was just a test to see how extreme the fonts could be before they were completely unsuitable for coding, it turned out to work surprisingly well. The large open geometric shapes make for easy reading and the punctuation goes well with the other glyphs. The only problem I could identify is the square brackets looking too much like the rounded ones, but if you can get over that it looks like a very nice font to program with. In fact, I’ve just changed it to be the default in MonoDevelop.

Of course, there are many other sans-serif fonts out there, but I picked these three as representative of several classes of styles. If anyone knows of sans-serif (or even serif!) non-monospace fonts that have been specifically designed for programming, I’d be glad to hear about them.

Promise

First of all I headed over to the Beagle site. It turns out that if you want to do more than handle a specific file-type (not an option in this case because the playlists are stored as .xml) you create not a “Filter” but a “Queryable”. Unfortunately the Queryable HowTo is still being written. Nevermind, I can always ask on the mailing list, and taking a look through the tutorial for Filters shows that the API for that is nice and clean and should be similar for the Queryables.

Next I try to find a reference for the C# DBus bindings. I install the Monodoc documentation for DBus, only to discover everything marked with “Documentation for this section has not yet been entered”—the default message for undocumented functions, classes, and so on. Nevertheless, I find a short tutorial on how to use Python with DBus to control Rhythmbox. The class names and functions seem to have similar titles in C#, so I figure this will map fairly directly.

Finding the DBus reference for Rhythmbox takes a fair bit more effort, trawling through mailing list archives on Google. Eventually I find the DBus APIs hiding in a couple of .xml files in the CVS repositories; org.gnome.Rhythmbox.PlaylistManager looks promising.

Misfortune

Unfortunately, I find a post by a last-exit hacker in which he states (my emphasis):

As I was told DBus C# bindings are unusable I went on about writing DBus# objects the hard way.

What? This can’t be right, I’ve already written a little test program:

using System;
using DBus;

namespace RhythmboxQuery
{
   class MainClass
   {
      public static void Main(string[] args)
      {
         Connection bus = Bus.GetSessionBus();
         try {
            Service rhythmbox = Service.Get(bus,"org.gnome.Rhythmbox");
         } catch (ApplicationException ex) {
            Console.WriteLine("Rhythmbox not started: " + ex);
            return;
         }
         Console.WriteLine("Found Rhythmbox.");
         /*

         Okay, so all I need to do now is to call `getPlaylists` on:
         /org/gnome/Rhythmbox/PlaylistManager

         */
         Console.WriteLine("Uhoh.");
      }
   }
}

Despite my valiant attempts to stave off the past through trivial C# programs, the DBus site confirms the aforementioned revelation:

They are schedualed to be removed from the core but has yet to find a maintainer. [sic]

Epilogue

As it turns out, what I had been planning to do would have been impossible anyway because the Rhythmbox DBus bindings lack a PlayPlaylist function in any of the three interfaces. Also, it seems that DBus under C# only plays nicely with C# objects that you have access to—but this could be just because I couldn’t find a single example of how to call methods on non-C# DBus applications.

Ah well, that Beagle Filter API did seem quite nice anyway, I wonder if there are any filetypes I could parse out there…