porges » C#

C# type inference and extension methods: an abuse

Porges — Wed, 23 Feb 2011 03:11:48 +0000

Here’s a little example of statically-sized stacks in C#. They’re implemented with a linked-list as the backing store:

using System;
 
namespace ConsoleApplication
{
    public static class MainClass
    {
        // Example:
 
        public static void Main(string[] args)
        {
            var stack = Stack.New<int>(); // real type Stack
 
            var s1 = stack.Push(1).Push(2).Push(3); // real type Stack>>>
            var s2 = s1.Pop().Pop().Pop(); // real type Stack
 
            // statically disallowed:
            // s2.Pop();
 
            Pop2(s1);
 
            Console.WriteLine(s1.IsEmpty());
            Console.WriteLine(s2.IsEmpty());
        }
 
        // Example of a method requiring "at least 2" items on stack.
        static void Pop2<TRest,T>(Stack<S<S<TRest>>,T> stack)
        {
            T x1;
            T x2;
            stack.Pop(out x1).Pop(out x2);
            Console.WriteLine("{0}, {1}", x1, x2);
        }
    }
 
    // Implementation:
 
    // very weak type level naturals
    // Z = zero, S = successor of x.
    // so, S = 1, S> = 2, etc.
    public sealed class S<TPrev> {}
    public sealed class Z {}
 
    // internal node type for the linked list
    internal class StackNode<T>
    {
        public StackNode(T item, StackNode<T> next)
        {
            this.item = item;
            this.next = next;
        }
 
        internal T item;
        internal StackNode<T> next;
    }
 
    // the stack wrapper type (sized with types)
    public class Stack<TSize,T>
    {
        internal StackNode<T> node;
 
        // Construct wrapper:
        internal Stack(StackNode<T> node)
        {
            this.node = node;
        }
 
        // Push:
        internal Stack(T item, StackNode<T> node)
        {
            this.node = new StackNode<T>(item, node);
        }
 
        // note that the return type has the size increased by 1
        // S ~= TSize++ 
        public Stack<S<TSize>,T> Push(T item)
        {
            return new Stack<S<TSize>,T>(item, node);
        }
    }
 
    // extension methods that perform the operations:
    public static class Stack
    {
        // a new stack has size zero
        public static Stack<Z,T> New<T>()
        {
            return new Stack<Z, T>(null);
        }
 
        // pop with ignored result
        public static Stack<TRest,T> Pop<TRest,T>(this Stack<S<TRest>,T> stack)
        {
            T ignored;
            return stack.Pop(out ignored);
        }
 
        // popping an item removes one S<> from the size (~= TSize--)
        public static Stack<TRest,T> Pop<TRest,T>(this Stack<S<TRest>,T> stack, out T item)
        {
            item = stack.node.item;
            return new Stack<TRest, T>(stack.node.next);
        }
 
        // These are statically known, because of the types:
        public static bool IsEmpty<T>(this Stack<Z,T> stack) { return true; }
        public static bool IsEmpty<TRest, T>(this Stack<S<TRest>, T> stack) { return false; }
 
    }
}

One fun thing about this is that we never have to check whether we’ve hit the bottom of the stack (node.next == null). Since the size is statically part of the type, and there’s no Pop for an empty list, we never have to check for this situation.

Things I’d like to see in C#: Conditional interface implementation

Porges — Sat, 20 Sep 2008 02:54:29 +0000

To explain this, imagine you are designing a type Wrapper, which is just a simple wrapper around a type T.

class Wrapper<T>
{
    T value;
    public Wrapper(T theObject)
    {
        value = theObject;
    }
    // Some other methods...
}

Now, since this is a just a wrapper around some type T, we would like to implement some simple interfaces around this object. For example, if T is comparable, we would like the wrapper class to implement IComparable>. However this is not possible with C#. In Haskell we would have something like this:

instance (Disposable a) => Disposable (Wrapper a) where ...

This says “if a is a type that is an instance of Disposable, then the type Wrapper a is also an instance of Disposable”. In C#, I’d like to see something like this:

class Wrapper<T>
    : IComparable<Wrapper<T>>
        when T : IComparable<T> //this is the syntax extension
{
    //...
}

And then in any methods that the interface specifies (in this case int Compare(Wrapper other)), it is assumed that for any object of type T you have access to all the methods that T has when it implements IComparable.

At the moment the best you can do is to always implement IComparable> and just throw a runtime exception when T doesn’t implement IComparable, which isn’t very nice.

A simple idea, but it would add great power to C#.

After some (very quick) research I haven’t found anything that suggests anyone else has attempted to get this into C#, but there is JavaGI (see section 2.4 for the equivalent of what this post talks about) where the authors have extended Java to deal with what they term ‘generalized interfaces’—a concept which alters Java (rather radically) to make interface implementations similar to Haskell’s typeclasses.

Implementing IEnumerable easily

Porges — Fri, 04 Apr 2008 09:43:02 +0000

Say that you’re implementing a linked list, and you want an enumerator:

public IEnumerator<T> GetEnumerator()
{
    return new Stream<T,Node>(first,
        node => node.next == null ? null : Tuple.Of(node.next, node.datum).AsNullable());
}

This uses the following utility class to implement the enumerator in one line (along with some code for Tuples and an extension method for structs):

public class Stream<Tdata, Tstate> : IEnumerator<Tdata>
{
    private Tdata current;
    private Tstate initialState;
    private Tstate state;
    private Func<Tstate, Pair<Tstate, Tdata>?> moveNext;
 
    public Stream(Tstate initialState, Func<Tstate, Pair<Tstate, Tdata>?> calcNextValue)
    {
        moveNext = calcNextValue;
        this.initialState = initialState;
        Reset();
    }
 
    #region IEnumerator Members
 
    public Tdata Current
    {
        get { return current; }
    }
 
    #endregion
 
    #region IDisposable Members
 
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
 
    protected void Dispose(bool disposing)
    {
        if (disposing)
        {
            var disposeCurrent = current as IDisposable;
            if (disposeCurrent != null)
                disposeCurrent.Dispose();
 
            var disposeState = state as IDisposable;
            if (disposeState != null)
            {
                disposeState.Dispose();
                //safe; have checked already above.
                //type of state == type of initialstate
                ((IDisposable)initialState).Dispose();
            }
        }
    }
 
    #endregion
 
    #region IEnumerator Members
 
    object System.Collections.IEnumerator.Current
    {
        get { return current; }
    }
 
    public bool MoveNext()
    {
        var result = moveNext(state);
 
        if (result.HasValue)
        {
            current = result.Value.Right;
            state = result.Value.Left;
            return true;
        }
        else
            return false;
    }
 
    public void Reset()
    {
        state = initialState;
    }
 
    #endregion
}

object.Equals handles null values correctly

Porges — Thu, 27 Mar 2008 20:58:12 +0000

Here’s the source code, as disassembled by Reflector:

public static bool Equals(object objA, object objB)
{
    return ((objA == objB) || (((objA != null) && (objB != null)) && objA.Equals(objB)));
}

It seems that not even Microsoft knows this! I spotted this code, from ASP.NET’s MVC implementation, on Scott Hanselman’s blog:

return (other != null) &&
  (((other._first == null) && (_first == null)) ||
    ((other._first != null) && other._first.Equals(_first))) &&
  (((other._second == null) && (_second == null)) ||
    ((other._second != null) && other._second.Equals(_second)));

This can be rewritten as:

return (other != null) &&
  object.Equals(other._first, _first) &&
  object.Equals(other._second, _second);

Much nicer!

A simple BigNum library for .NET

Porges — Sat, 13 Oct 2007 08:05:51 +0000

Update

Due to minor demand, the code is also available: BigNum source.

Please note that I haven’t actually touched the code since it was first written. I’m sure there’s some things that don’t work properly. If you’re doing anything big with this you probably want to write some ‘destructive’ update functions for adding, etc. At the moment every time you add, subtract, etc, a completely new BigInt is returned. To make it faster you’d want to just update the number in-place.

Original content…

I’ve created a simple wrapper for GMP. At the moment only BigInts are implemented, but I expect to have BigRationals and BigFloats coming along soon enough. (Edit: this never happened.)

Usage

I think this is very close to as-you’d-expect. The only minor thing that might come as a surprise is that BigInts aren’t value types; since they need destructors, they can’t be. The rest is fairly straightforward:

static void Main(string[] args) {
    BigInt n;
    for (ulong i = 100; i <= 999; i++) {
        n = BigInt.Factorial(i);
        Console.WriteLine(n);
    }
    Console.ReadLine();
}

This code executes with sub 5-second times, which I’m pretty pleased with. I’m not sure what kind of performance decrease you get through using GMP under managed code.

Caveats

Consider this alpha software
The included GMP DLL is compiled with none of the magical assembly they provide. If you want to, you can compile it yourself with all this enabled, and you should be able to just use it as a drop-in replacement.

Download

Available here: BigNum library. Documentation is available.

Fun(c) with C# 3.0

Porges — Tue, 09 Oct 2007 02:03:31 +0000

Looking through the list of predefined (or, in Microsoft’s parlance, standard) query operators defined in C# 3.0, there is one that stands out as missing: the ‘map’ function. However, with the new query expression syntax, this is trivial to define:

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();

Lazy Lists in C#

Porges — Thu, 27 Sep 2007 21:23:36 +0000

I had the thought—while browsing through some old code—that the code I used to implement futures in C# would be useful for doing things lazily, if you just moved the evaluation phase to when the value was actually demanded… this started me off thinking about how to implement a proper lazily-evaluated list in C#.

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 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();

NullPointerException

Porges — Thu, 24 May 2007 21:26:41 +0000

Why is this such an insidious error in Java? (An opinion piece!)

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.

Implementing futures in C#

Porges — Tue, 13 Feb 2007 08:03:15 +0000

Why?

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.

Sans-serif fonts for coding

Porges — Tue, 19 Sep 2006 00:41:30 +0000

After reading a post about colour schemes and font choices for use in an IDE, it seems I’m one of the only people on the planet that uses non-monospace fonts for coding. So, in the spirit of equal access, I’ve decided to try a couple of different fonts in MonoDevelop. While it doesn’t have the greatest highlighting support at the moment, or any code folding (although I suspect these shortcomings are due to libgtksourceview), it’s still good enough for my purposes. My colour coding is based upon the default, but with blue keywords instead of green, and the comments changed to a light grey colour to make them more ignorable (the default is a bright blue which is quite startling).

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.

Toilets and Thread Synchronization in C#

Porges — Sat, 16 Sep 2006 07:15:15 +0000

It dates from 2003, but this is still the best explanation of thread synchronization using Monitors that I’ve read.

DBus, Mono, Rhythmbox, and Beagle, Oh My!

Porges — Fri, 15 Sep 2006 10:26:38 +0000

So I had this idea of writing a quick search plugin for Beagle to search Rhythmbox’s current playlist titles. They would show up in the search GUI and then you’d double-click on one and it’d handle this (probably through a pseudo-URL like playlist://rhythmbox/my-playlist-name which seems to be the de facto standard amongst Beagle plugins) by sending a DBus event to Rhythmbox to start playing this playlist. Sounds simple enough.

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…