Effects of Intuition

In the march of pure functional programming toward pervasive mainstream use the notion of effects have become an interesting topic. I’ve begun looking at what you might call “the effect spectrum” or “the effect zoo”: the different kinds of effects and what they do (to your program).

I shall name these functions by personal preference, these names are likely unconventional but they have “symbolic” value.The first examples will not be effects at all but I will gradually move into effects over the next few posts, well maybe just one more post. I have a few ideas queued up on time-slicing, “forced” pre-emption (OS terminology abuse alert) and exceptions.

The structural notation will be a “pseudo/semi-formalism”, Haskell-like.

Exhibit 1: Non [ineffective]

This function takes no arguments, computes nothing, does nothing and returns no result. It is the computational equivalent of brain death.

structure

() → ()

substance

public void non()
{
}

Exhibit 2: Som [ineffective]

This function takes one argument and returns that argument. The “zero” function may be seen as a special case of the “one” function, accepting only the empty tuple.

structure

a → a

substance

public void som<T> (T x)
{
  return x;
}

Exhibit 3: Som-Non [ineffective]

This function takes one argument and returns nothing as a result, never caring about what the argument actually was, you might call this a comatose function: it gets everything you say but can’t respond back with anything (the empty tuple () being the equivalent of silence).

structure

a → ()

substance

public void somnon<T> (T x)
{
}

Exhibit 4: Non-Som [ineffective]

This function takes nothing and returns something. It is the dual of comatose – it can only give and it always gives the same thing.

structure

() → a

substance

public T nonsom<T>()
{
   return default(T);
}

Exhibit 5: Som-Time [time-"in"-effective]

This function takes something and returns that same thing, after some time. You might say it’s the functional equivalent of bullet-time; it slows down time (if e.g. we define time as state-transitions; ticks, or whatever). This means it has an effect, meaning its “effective” but this time-effect also makes it “in-effective”.

structure

a → Δ a

substance

public T somtime<T>(T x)
{
   Thread.Sleep(1000);
   return x;
}

One may argue whether this function actually contains a [side-]effect (messing with time) or not. In a sense all functions mess with time, as in the real world they take time to compute. So the result is some delta into the future where the argument is some point in the past, depending on when you look at it.

As part of my continued pursuit of the Lambda Lecture Series (my name for it) on Channel 9, I’ve summoned up a brain-storm worth of examples that show the symmetry and dualism of some functions and types. I’m not yet familiar with the higher-level abstract concepts of Arrows so arrow here simply means function.

References
– Types – Arrows – Duals [SkyDrive]

Let’s fix C.A.R. Hoare’s billion dollar mistake for C#: Null-pointer dereferences. – Isn’t hindsight great?

By default, C# reference types are nullable, meaning one can assign a null value to a variable of a reference type. These null values can propagate away from the point of origin and spread terror and havoc. There is a good and sound principle in software engineering that says: fail early, fail often. This means that a program should detect or exhibit a software defect right where it occurs (which is as soon as it occurs; well possibly sooner using static analysis and symbolic execution) and it should exibit a predictable behavior towards it, failing each time, reflexively. A program that just carries on can end up making much more damage along the way and can be harder to debug.

Then of course we might choose to interpret what we mean by “fail”. It might be a brutal failure or a recovered failure. The base philosophy has to be that the defect is at least signalled at its origin, handled or not.

One approach to dealing with this issue is using contracts. One can annotate function and method definitions with pre- and post-conditions expressing that the input and output of a piece of code will not and must not accept or deliver a null value. If spread everywhere, this will help catch the error where it occurs. It’s like a finely masked web spread out over the code, which will not allow a null value much freedom to move around before it is caught: thus enforcing the fail fast principle.

In Microsoft .Net, traditionally, there has not been support for contract programming or what is known as Design by Contract from Eiffel. People can write their own assert functions and sprinkle them all over the place which may help but it is not a very good contract solution. Things improve in .Net 4.0 with language-agnostic contract support.

A different approach is to have types help out.

In software engineering we face the same problem over and over again: in an imperative world it used to be fine to have object be mutable by default. In the new manycore world this approach is untennable. Similarly, in the past, it used to be (somewhat) ok to have reference types include null in the domain. It just turns out that in practice this was a really bad mistake. Null-pointer exceptions én masse. In the first case a paradigm shift forces us to change strategy, at least gradually. In the second, a painful history of bugs teaches us better ways.

As an aside, recently Dr. Erik Meijer and team have dualized the IEnumerable/IEnumerator types, creating the quite beautiful IObservable/IObserver types. In other words, the two type sets form eachothers duals. That is not to say that the former is no longer needed but it’s one more example of dualization. Mutable vs Immutable another (well an opposite at least).

New since, what, .Net 2.0 is Nullable<T>. This type allows us to define primitive (struct) types as nullable by wrapping them in another type that signal whether the wrapped value is actually null. It will not work for classes since they are already nullable and the Nullable type is defined to only work for T where T is a struct type.

The obvious thought here is: OK, we had integers that we needed to be nullable. Now we have objects that we need not to be nullable. Let’s “dualize” this. And so I made a simple struct to demonstrate the idea. This would benefit from language support but can really help out on its own. The Nullable<T> type has syntactic support in C# via the T? notation.

The definition is as follows.

  public struct Unnullable<T> where T : class
  {
    public Unnullable(T x)
    {
      if (x == null)
        throw new NullReferenceException();
      item = x;
    }
    
    public T Item
    {
      get
      {
        return item;
      }
    }
    
    private readonly T item;
  }

I made it up an early morning, after waking up far far too early and it has to be tested out thouroughly. But just quickly trying some obvious null assignments fails. Even not assigning a value to a newly declared Unnullable<T> variable will fail at compile-time; well, even before, as Intellisense and background compilation will warn you before you run a regular compile. At least if you use Visual Studio.

It’s impossible to construct an Unmutable that contains a null. So it really is un-nullable. At least if not resorting to evil means such as reflection. If this type is used, whereever it is used it will provide null-safety, i.e. non-nullness.

In a not too distant future we may see this built into C# and VB, maybe even on the class level where we can say that a class is unnullable by design. This may create other problems that we’ll defer indefinitely – for now.

References

- A Channel 9 thread on ideas for C# 5.0

There is a new lecture series on Channel 9 by Dr. Erik Meijer. It is about functional programming and is using Haskell as the the means of expression although the exact language is not so important; but Haskell is appropriate in that it is pure, lazy and has a discrete syntax.

There was a couple of questions about the execution of the programs in the beginning of the series and so for weekend fun I prepared a small document that shows two different (actually not so different) REPL’s. These may be used to execute Haskell expressions directly.

References

• Lecture Series [channel 9]
• Lecture Reference [SkyDrive]

Program code follows order. Syntax and semantics. But when run, it can be very unpredictable and unordered. Chaos out of order you might say. A clear picture of this are fractals (although they embody both order and chaos at the same time); a better example may be random numbers.

Actually, most of the time we deal with pseudo-random numbers, that is, numbers that operate on a seed value and calculate some other number based on this seed value. But then, if we know the seed value, we can compute the “random” number, so unless the seed value itself is random, we don’t have a truly random number.

More troublingly, how can we even determine that a number is random? Well, let’s not go there. Instead, let’s try to bring order to the chaos that is randomness in Random in the .Net Framework. In particular, rather than fetching one “random” number at a time, we should see randomness is a stream of numbers.

So the definition* is as follows

public static IE<int> Random(this int seed,
     int min = 0, int max = int.MaxValue)
{
    var r = new Random(seed);
    while (true)
        yield return r.Next(min, max);
}

So this looks pretty good, now instead of calling r.Next explicitly, and thereby invoking a side-effect, we just get a sequence of pseudo-random or chaotic numbers based on a seed value.

This means we have pure randomness: functional randomness where chaos is a function of order, that is we get the same randomness for the same seed, every time; at least unless the implementation of Random breaks and suddenly gives us new randomness for the same seed value; something which would be highly… irregular.

Now we can create a random combinator which given an IEnumerable and a seed value, will predictably randomize this IEnumerable into a new IEnumerable.

public static IE<T> Random<T>(this IE<T> s, int seed = 0)
{
    var n = s.Count();
    return from i in seed.Random(0, n).Distinct().Take(n)
           select s.ElementAt(i);
}

Simple, predictable, composable.

Now looking back at the previous post “Information”, we might be inspired to decompose randomness into a stream of bits instead; I mean, why should we deal with pesky integers. Looks like a random choice of number system to me.

public static IE<bool> Random(this bool seed)
{
    var r = new Random(seed ? 1 : 0);
    while (true)
        yield return r.Next(0,1) == 1;
}

And so there you go. Pure, predictable, pseudo-random numbers in the most simple package there is: a stream of bits.

* Notice that IE is short-hand for IEnumerable.

I have always been interested in breaking down data and concepts into fundamental pieces. In a way everything can be decomposed into bits, at least in the realm of data.

And so it always appeared unnatural to me that programming languages or libraries did not naturally express this this fact that the bit is the unit of information. This is particularly unnatural when dealing with information where data that is not neatly packed into bytes. A truly compositional way of parsing should build upon bits, even if at least 8 bits or more are read from disk, memory or whereever.

So I set out to formulate this in C#. This is only the beginning but here’s what the very initial alpha functions code looks like.

First we define* decomposition for bool values (bits), this is obviously the simplest case as we cannot decompose this case (well, we could, but let’s not go there)

public static IE<bool> Information(this bool x)
{
    yield return x;
}

Next we decompose bytes

public static IE<bool> Information(this byte x)
{
    return Enumerable.Range(0, 8 )
           .Select(i => ((x >> i) & 1) == 1)
           .Normalize();
}

Then we define a normalization combinator that orders bits according to the current architechture’s Endianness

public static IE<bool> Normalize(this IE<bool> s)
{
    return BitConverter.IsLittleEndian ? s.Reverse() : s;
}

And so on and so forth. As you can see this is very limited so far, but you can imagine combining these to decompose byte streams from files, etc. And so this will allow you do be completely oblivious to endianness and decomposition of bytes etc. All you see are bitstreams.

As said, this is alpha. I have almost no experience with binary parsing and such, but this should be interesting for diving into that area.

* Notice that IE is short-hand for IEnumerable!

C# allows you to model sets via enumerations (the enum kind of type). Take for example

public enum Choice
{
    Either,
    Or
}
.

Now how if one wanted to model not just a choice but a choice between values. There is no way to do that with C# enums as of today.

Languages with algebraic data types (ADTs) allow this, witness this example

public enum Either<α, β>
{
    either(x: α);
    or(x : β);
}
.

Notice that this specification does not depend on the choice of values to necessarily have the same type or any particular type, this is just using parametric polymorphism. Don’t be distracted by the greek symbols, you could have used any identifier, such as S and T, as is common in .Net land.

Suffice it to say I wanted to adapt this for C# to see if I could possibly model choice in a nice way. And so I first tried this

public enum Choice
{
    Either,
    Or
}

public sealed class Either<α, β>
{
    private Either(α a = default(α), β b = default(β))
    {
        this.First = a;
        this.Second = b;
    }

    ...

    public readonly α First;

    public readonly β Second;

    public readonly Choice Choice;
}
.

Now of course in this example we could have used a bool because the set only has two types, but really we don’t want to be limited to that, and we also want the type to say what “true” is and what “false” is.

The real dissatisfying aspect of this solution is that it separates the “tag set” from the value set – you have two constructs instead of one. This is clearly a dissatisfactory solution.

And so working a bit more with this, I came up with this solution

public abstract class Choice<α, β>
{
    protected Choice(α a = default(α), β b = default(β))
    {
        this.First = a;
        this.Second = b;
    }

    public readonly α First;

    public readonly β Second;
}

public sealed class Either<α, β> : Choice<α, β>
{
    public Either(α x)
        : base(x, default(β))
    {
    }
}

public sealed class Or<α, β> : Choice<α, β>
{
    public Or(β x)
        : base(default(α), x)
    {
    }
}
.

This specification, although not as clean as a pure ADT specification, has desirable properties. A type of choice is expressed as a subtype. Testing a value for what kind of choice it is amounts to using the is operator, as in “a is Either<int,bool>”.

I’m going to be experimenting with what can be done with this style and this type family in particular.

The solution has some validation because I believe it is similar to the hybrid functional object-oriented language Scala uses, which is quite state-of-the-art in this respect; some memories of Scala must have been floating around when solving this.

Feel free to use.

Or -

Higher-Order High-Resolution Timer for the Masses

Timing code is so common that many timers exist in the .Net Framework. One can resort to simplistic timing via Environment.TickCount DateTime.Now, but this is a low-resolution timer that does not accurately reflect the current tick count and is therefore not usable for precision timing. As this[1] MSDN article shows, its resolution is actually 10 ms for modern versions of Windows (NT 3.5 or later).

Also see this[2] article about three timing tactics for .Net.

(System.Diagnostics.) Stopwatch to the rescue. This class is a simple stopwatch that is easy to use. However even this class can be repetitive to use many times. The way to make this even easier is to create a higher-order function. I wanted to create such a function but figured it would be nice to include in my extension method library on codeplex.

The problem is that dispatching off an action is not nice (not even the latest C# 4.0 mitigates this). So I created a new enum type Timer that reflects two units of measure – ticks and milliseconds. Now an extension method can dispatch over this type and measure time for a delegate. This is how the code is used (work is an Action that performs the work to be timed)

var ms = Timer.ms.Time(() => work());

I dare you to simplify this. See code on extensia[3] on codeplex.

If C# worked a little more like I’d like it to, it’d be possible to write something like this, using extension methods

var ms = Work.Time();

Maybe C# 5.0.

The latest improvement here, is a method to show (via (System.Diagnostics.) Trace, which can be fed into the Console via a listener) the timing information in a nicely formatted way – it allows you to write this

Timer.µs.Show(() => Test(), "test");
Timer.Ticks.Show(() => Test(), "test");

The first line displays the measurements in whole microseconds, the seond one in the unit closest to the order of magnitude below or equal to one second. This eases formatting quite a bit. The output of a Ticks measurement looks like

test() finished in 235025 ticks (100 ms)

As you can see the appropriate unit (milliseconds) is chosen. This number is calculated based on Stopwatch.Frequency which defines the resolution of the underlying timer.

Notice the that the special character “µ”, which is a nice cherry on the top for this interface. I have also begun using the greek alpha, beta and gamma symbols for parametric type names to make them stand out more (although these symbols are also be useful for math variables, so it’s not a clear cut case on their usability for this purpose).

2009/10/10: updated the post with a correction and a couple of references: it is not Environment.TickCount that is (necessarily) imprecise (relatively speaking), it is DateTime.Now. However Stopwatch is the best approach to timing precisely since it exposes the timing frequency and whether the timer is actually high-precision as a boolean property (Environment does not appear to expose frequency information) and it is supposedly the highest-precision timer in the .Net Framework (BCL).

References

• [1] http://msdn.microsoft.com/en-us/library/system.datetime.now.aspx
• [2] http://reflexangle.blogspot.com/2009/04/datetimenow-vs-systemdiagnosticsstopwat.html
• [3] http://extensia.codeplex.com

I have been increasingly using XLinq for various small tasks and it really is quite productive.

Recently however, a problem arose whereby a colleague asked for a solution to how he could possibly deal with XML documents with any namespaces in the same way.

That is, it whether an element was called {foo}bar or {}bar could not have any significance to his code.

Therefore I devised a couple of simple extension methods to deal with this issue. The solution, which is easily replicatable with a little knowledge of LINQ and System.Xml.Linq, is used like this

var isbn = doc.LElement("book").LElement("isbn");

.
I reimplemented these with provisions for attribute support on extensia.codeplex.com – feel free to use.

In the first post on console extension methods I showed how to parse console arguments in an extremely simple way. However this is not quite optimal for formatting exceptions for missing argument exceptions because the distinctions are erased.

Therefore I devised a new way to deal with this where these cases are surfaced as exceptions. It’s pretty simple but nice because since the parameter name is known, it can be used to give very helpful error messages in a catch block. So the idea is to keep the entire console application parsing code in a try block and keep the exceptions separate.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Tests
{
    using Extensia.Console;

    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                var price = args.Argument<decimal>("price");
            }
            catch (Exception e)
            {
                // we get nice exceptions here a la
                // - argument missing for "speed"
                // - unsupported format for "speed"
                // - format error for "speed"
                Console.WriteLine(e.Message);
            }
        }
    }
}

This is a nice and simple model that is even better than the previous one.

The solution (up on extensia.codeplex.com) - feel free to download and use it.