I promised that stability was going to be a feature, and actually I think it allready is.
I’ve been using QG extensively in production over the last year (there’s three or four projects I’m currently involved with that are using it, and I know of quite a few others).

Some ‘known issues’ have popped up though.
If you know you’re way around the lib there’s always a way to work around it, but recently I’ve been able to tear myself away from the Haskell compiler (and, I must admit, ‘Dwarf Fortress’) for long enough to start adressing these issues in a more fundamental manner.

One breaking change, unfortunately, was neccesary :

As of yesterday, relations are no longer bidirectional.
This means that if you define (f.i.) a OneToMany relation between a ‘Parent’ class and a ‘Child’ class, a Parent instance will no longer be automatically generated if you ask the generator for a Child instance.
There is now a ManyToOne method for just this case.

Believe me, It simplifies matters. Not only in quickgenerate, but for quickgenerate users (i.e. the client code) aswell.
All kinds of circular misery is now easily avoided.

As it really didn’t take me that long to update a production project with about two thousands tests, where about a quarter of them relied on this feature, and it actually simplified a lot of the code, I do believe it is worth the change.

I don’t think it will affect too many users as I’m probably the only one generating entire domains with just the one generator.
You can still do that if you want to though, you only need a couple of extra lines of code now.
You can combine the OneToMany with a similar ManyToOne, infinite recursion will be avoided, and you get the same behaviour that was there before, including all the problems that come with it.

So, once again, for those of you that are impacted, I’m sorry, but it needed to be done.

Also on the list for the 0.5 release.
– better support for inheritance.
– better support for the generation of constructor parameters and the ability to choose between different constructors.

Both features are now available through the ‘StartingValue’ method but a more intuitive API would be desirable.

There’s also a request for backing field generation, but I’m still hoping I can pull this off without taking a dependency hit to an external library.

In the meantime I’ve added a QuickGenerate.NHibernate.Testing.Sample project to the solution, as it seems that this is what most people are using it for these days.
Any issues that pop up while you’re trying to do this, just send me a failing test/use-case (and/or patch) and I’ll definitely look into it.
It’s still quite a simple example.
I’m using sqlite to demonstrate possibilities and, well, sqlite is … limited.
Feel (very) free to get involved in this part of the code .
And if anybody feels like contributing an E.F./AutoMapper/LLBGen/Ditto/whatever example, please do.
The AutoMapper example is on my todo list as you might have gathered from a previous post.

Specific Generator requests are also, as always, still welcome.

F.i. a ‘ShortGenerator’ was added recently and someone suggested a generator based on Regex expressions.
But seeing as how I hate RegEx with a passion (*), I’m going to leave that one as an exercise for some of the more masochistic devs out there .

(*) : have a look at Parsec for a decent, and really, only slightly more verbose, alternative.

On a sidenote :
– Once I’ve reached the QG 1.0 milestone, I promise I will give QuickDotNetCheck some much needed love.
I’d really like to clean up all of the QG tests and replace them with QDNC tests, but, … small steps, …

I gave a very general description of what it is and what it’s used for and of them said : ‘It sounds beautiful, but I have no idea what you’re talking about’.

So here’s an example.

The ‘metaphysical’ description goes something like this :

A lifting function takes a function that operates in a certain context as it’s argument and returns a transformation of that function that can operate in a different context.

A C# example :

Consider the following class which wrappes an int and that I have imaginatively called Wrapper :

public class Wrapper
{
    public Wrapper(int value)
    {
        Value = value;
    }

    public int Value { get; private set; }
    public override string ToString()
    {
        return string.Format("{0} wrapped", Value);
    }
}

And then we have the following functions which operate on int’s.

public int Add(int a, int b)
{
    return a + b;
}

public int Multiply(int a, int b)
{
    return a * b;
}

public Wrapper Lift(Func<int, int, int> f, Wrapper a, Wrapper b)
{
    return new Wrapper(f(a.Value, b.Value));
}

Then we can use the two functions above and apply them to instances of Wrapper like so :

Console.WriteLine(Lift(Add, new Wrapper(41), new Wrapper(1)));

Console.WriteLine(Lift(Multiply, new Wrapper(333), new Wrapper(2)));

Now I can’t think of a lot of situations (well I can’t think of any actually) where code like that would be useful in C# but let’s see what we can do with it in Haskell.

Translating above code :

data Wrapper = Wrapper Int
  deriving Show 

It’s pretty identical to the C# Wrapper class although we don’t need all that boilerplate code.
The deriving Show part gives us a default ToString Implementation f.i.

Here’s the ‘lift’ function :

lift f (Wrapper a) (Wrapper b) = Wrapper (f a b)

We don’t have to define the add and multiply functions in Haskell as operators are functions as well, so there is no need to wrap them in yet more boilerplate code.

Let’s fire up the GHCI and verify that it behaves as expected.

>lift (+) (Wrapper 41) (Wrapper 1)
Wrapper 42
>lift (*) (Wrapper 2) (Wrapper 333)
Wrapper 666

Well that seems to work.

But even though everything is type checked at compile-time (Haskell being a static language just like C#), Haskell’s rich type system allows us to generalize even further to an extent that is simply not possible in C#.

The lift function does not touch the value of the Wrapper’s field, so it really could be anything and the function would still work.

Let’s change the definition of our Wrapper datatype to a more general version by introducing a type parameter.

data Wrapper a = Wrapper a
  deriving Show

The a is the type parameter, kind of like a generic in C#, albeit quite a bit more powerful.
Retrying the code again in the GHCI gives exactly the same result as before.
But now we can also do it for other types f.i. :

Doubles :

>lift (+) (Wrapper 41.5) (Wrapper 0.5)
Wrapper 42.0

Concatenating strings :

>lift (++) (Wrapper "hello ") (Wrapper "world")
Wrapper "hello world"

The types of the wrapped value don’t even have to be same as long as the function we’re lifting matches the parameters.
F.i. :

>let convertAndAppend a b = (read a):b 
>lift convertAndAppend (Wrapper "1") (Wrapper [2,3,4])
Wrapper [1,2,3,4]

‘read’ is similar to C#’s Parse(Int/Double/DateTime/…) functions and (:) is the operator for appending an element to a list.
So ‘a’ should be a string and ‘b’ should be a list of things that ‘a’ can be parsed into.

In Haskell the compiler is your friend, all this just works but when you try to do something nonsensical such as multiplying two strings you get a compile time error.

>lift (*) (Wrapper "hello ") (Wrapper "world")

<interactive>:1:6:
    No instance for (Num [Char])
      arising from a use of `*'
    Possible fix: add an instance declaration for (Num [Char])
    In the first argument of `lift', namely `(*)'
    In the expression: lift (*) (Wrapper "hello ") (Wrapper "world")
    In an equation for `it':
        it = lift (*) (Wrapper "hello ") (Wrapper "world")

Now even though I already think all that kind of parametric polymorphism is pretty kewl and useful, let’s look at why lifting is such an integral part of the Haskell language.

Take the following data structure :

data Session = Session ClockTime ClockTime

And then we have the following function that calculates the total number of seconds elapsed for a given session.

sessionLength (Session begin end) =  tdSec $ diffClockTimes end begin

This is a ‘pure’ function.
Meaning it has no side-effects and every time we pass in the same Session parameter we can be sure we get the same result.

Now consider the following function :

timeIt = do
  begin <- getClockTime
  putStr "Timing, press any key to stop."
  getChar
  end <- getClockTime
  return $ Session begin end 

This function gets the current time (through getClockTime), then waits for the user to press a key gets the current time again and returns a Session structure with both times filled in.

It’s pretty easy to see that this function is not referentially transparent.
It will return a different result every time we call it.
So what happens when we want to apply our pure function to the result of this ‘impure’ function.

>sessionLength timeIt 

<interactive>:1:15:
    Couldn't match expected type `Session'
                with actual type `IO Session'
    In the first argument of `sessionLength', namely `timeIt'
    In the expression: sessionLength timeIt
    In an equation for `it': it = sessionLength timeIt

The compiler starts moaning.

The error message already explains it but looking at the actual type of our functions will make things clearer if you’re not used to Haskell’s compiler errors.

>:type sessionLength 
sessionLength :: Session -> Int
>:type timeIt 
timeIt :: IO Session

sessionLength takes a Session as a parameter and returns an Int (the number of seconds elapsed).
timeIt however, does not return a Session, but an IO Session.

So what’s this IO thing.

This is Haskell’s way of saying that we’re executing code that produces side-effects.

Seeing as the getClockTime function is impure, everything we do with the result of that will also be impure.

This kind of code is executed inside a specific context.
In this case the IO Monad.
And once something is inside a Monad it can never, ever, ever escape it.

This protects us from leaking side-effects into places where we don’t expect them.

It does however restricts us a little.

One solution would be to rewrite the sessionLength function to allow for side effects but that would deprive us of all of the advantages (such as ease of program verification for one) of pure code.

A better way to deal with this is lifting.

Although nothing is ever allowed out of the IO Monad, we _are_ allowed to bring things in.
More specifically we can lift pure functions into the IO Monad.

Similarly as in our Wrapper toy example the Control.Monad module defines a lifting function called liftM which does just that.
It takes a pure function and lifts it into the IO Monad context.

So this :

>liftM sessionLength timeIt 
Timing, press any key to stop.
2

Behaves exactly the way we want.

And now we can write most of our program and algorithms in a pure coding style and separate the side-effects in a very specific place that we then ofcourse unit-, or better yet, quickcheck-test like hell.

A String in Haskell is actually a list of Char’s.
I.e, :

"hello world" == ['h', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd']

The ‘:’ operator is for appending an element to a list, I.e. :

"hello world" == 'h':['e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd']

"hello world" == 'h':'e':'l':'l':'o':' ':'w':'o':'r':'l':'d':[]

The compareLine function.

compareLine :: Int -> Int -> String -> String -> String

What follows the functions signature, might look like a bunch of overloads to most C# devs, but it is actually pattern-matching.
When we call this function the arguments are matched against the expression on the left of the assignment operator, and if a match is found the expression on the right is executed.
These patterns are evaluated in the order that they are defined, so let’s go over them, one by one.

End of line or empty strings

compareLine lineIndex colIndex [] []

Both Strings however _are_ matched.
[] is the empty list, and in the case of a Char List, also an empty string. So : “” == []

This pattern will only match if we pass in two empty strings. I.e. :

compareLine 42 666 "" ""

Different string length

compareLine lineIndex colIndex [] (y:ys) = 		failure lineIndex colIndex
compareLine lineIndex colIndex (x:xs) [] = 		failure lineIndex colIndex

The new part of this pattern uses the list append operator.

(x:xs) is a common way of writing :
an x (atleast one) followed by a bunch of xs (could be zero).

Or differently put, a list with atleast one element.

In above pattern (x:xs) will match :
– “hello world”, which could be written as ‘h’:”ello world”
– “h”, which could be written as ‘h’:[]
But not “”.
In the context of our recursive compareLine function this pattern evaluates when one line is longer than the other.

Different Char’s

compareLine lineIndex colIndex (x:xs) (y:ys) | x /= y = failure lineIndex colIndex

‘/=’ is Haskell’s inequality operator.

x and y are defined in the pattern left of the guard.
In the same way parameters are bound to argument names, values broken down by patterns are assigned to the names used in the pattern.
Which means x is the first element of the first string parameter and y is the first element of the other string parameter.

The guard is doing char comparison.

Above pattern evaluates if we have two non-empty strings, and the first character of the first string differs from the first character of the second string.

Recursion

compareLine lineIndex colIndex (x:xs) (y:ys) | x == y = compareLine lineIndex (colIndex + 1)  xs ys

Knowing what we know we can read the pattern now as : we have two non-empty strings, and the first character of the first string _equals_ the first character of the second string.
The interesting part here is the right hand expression.
This is where the recursion happens.
We keep the lineIndex, increment the colIndex counter and pass in the decomposed ‘tail’ lists (xs and ys).
F.i.

compareLine 0 0 "hello" "hello"

('h':"ello") ('h':"ello") | 'h' == 'h'

compareLine 0 1 "ello" "ello"

module FileCompare (
    fileDiff
)

Modules are the primary way of encapsulation in Haskell.
The statement above exposes one function to the outside-world : ‘fileDiff’.
Everything else we use in the module can not be used anywhere else, it is ‘private’.

Import statement(s)

import System.IO (readFile)

Quite similar to the using statement in c#, this declares dependencies of one module on another.
An interesting thing to note though, is that I am able to restrict which functions of the System.IO module (namespace if you will) are imported.
In this case I’m only using readFile so I inform the compiler of this, which will allow it to optimize.

It also expresses intent quite clearly.
If I inadvertently use something else I _will_ get a compiler error.
I.e. the module’s declaration will give me some important clues of what is going on in the implementation.

The failure function

failure :: Int -> Int -> String
failure lineIndex colIndex  =
    "Files differ at line : " ++ (show lineIndex) ++ ", column : " ++ (show colIndex) ++ "."

The first part is the function’s signature.
It’s name followed by it’s arguments and ending with the return type.
So this one takes two Int’s and returns a String.

The slightly weird arrow notation actually makes sense if you take in to account currying.

The following (not very usefull) functions show this by example.

failureOnLineTwo :: Int -> String
failureOnLineTwo lineIndex colIndex = failure 2

failureOnLineTwoColumnThree :: String
failureOnLineTwoColumnThree = failureOnLineTwo 3

As you can tell from the signature ‘failureOnLineTwo’ is a function that takes an int and returns a string.
‘failureOnLineTwoColumnThree’ is just a string. All the free parameters have been filled in so it evaluates to a value.

‘++’ is Haskell’s string concatenation operator.

[Test]
public void MapperShouldNotCauseExtraQueries()
{
    using(0.Queries())
    {
        Mapper.Map(entityResultFromQuery);
    }
}

public class QuerySpy : IDisposable
{
    private readonly int expectedNumber;
    private readonly NHibernateSqlLogSpy spy;

    public QuerySpy(int expectedNumber)
    {
        this.expectedNumber = expectedNumber;
        spy = new NHibernateSqlLogSpy();
    }

    public void Dispose()
    {
        Assert.AreEqual(expectedNumber, spy.Appender.GetEvents().Count());
    }
}

public static class NumberOfQueriesUsedExtension
{
    public static QuerySpy Queries(this int expectedNumber)
    {
        return new QuerySpy(expectedNumber);
    }
}

public class NHibernateSqlLogSpy : LogSpy
{
    public NHibernateSqlLogSpy() : base("NHibernate.SQL") { }
}

public class LogSpy : IDisposable
{
    static LogSpy()
    {
        XmlConfigurator.Configure();
    }

    private readonly MemoryAppender appender;
    private readonly Logger logger;
    private readonly Level prevLogLevel;

    public LogSpy(string loggerName)
    {
        logger = LogManager.GetLogger(loggerName) as Logger;
        if (logger == null)
            throw new NullReferenceException();
        prevLogLevel = logger.Level;
        logger.Level = Level.Debug;
        appender = new MemoryAppender();
        logger.AddAppender(appender);
    }

    public MemoryAppender Appender { get { return appender; } }

    public virtual void Dispose()
    {
        logger.Level = prevLogLevel;
        logger.RemoveAppender(appender);
    }
}

Kind of takes me back to my busking days.

But thanks too my innate ability of not getting stressed out about anything, I am once again in this (for most people) non-enviable position.

Fortunately I’ve got something lined up soon.

But I must say, it does feel as if a weight has lifted of my shoulders.

A lot of useless stuff I accumulated over the past couple of years has been sold or just simply thrown away.
This includes dvd players, tv’s, lot’s of technological gadget’s, my kids stuff that they don’t care about anymore but that were still floating ’round, lot’s of rodent cages and accessories that I once used when I was trying to train a bunch of gerbils/rats etc …

And I kept only what I value most (a guitar or two-three, my macbook, some clothes, …)

I really wish I could get rid of the car aswell .

I’ve told this story a number of times, but a long time ago we used to hang out in this one guy’s place.
He was the only one with a regular job.
At one point he got a vcr recorder (yep it’s quite a while back).
So we ended up watching movies in his place quite often.
And then it broke down.
Everybody was ticked off.
So he send it in for repairs.
A week later he got it back, walked into the apartement, hooked it up and we started watching a movie.

Half way through he got up, yanked the ‘ken thing out and threw it out of his window.
Seeing as he lived on the fourth floor not much was left of it.
Everybody just stared at him and one person asked : ‘What did you do that for?’
He replied :
Before I had the ‘ken thing I was happy.
When I bought it and it worked I was happy.
When It broke down it made me unhappy.
I don’t like it when _things_ make me unhappy, so I reckon I’m better off without it.

Let go, …, just, … let it go.

After that I got really interested in Haskell, so I experimented.
But the unforgiving nature of the type system was really hard to deal with and I had a lot of trouble implementing anything usefull.
I managed to pull some things off, but really didn’t get why.

Recently I have picked it up again, and it’s all starting to make sense.

Still having trouble making stuff compile and getting things to work.
The fact that I’m using a different setup/IDE/OS than before, probably isn’t helping.
But I’m really, _really_ having fun with this.

Currently looking into Happstack/HStringTemplate/et-all in order to deliver a simple web app, and I was quite proud of myself that I got a ‘hello world’ working with minimal code, and that I actually understood all of what is going on .

Another thing that I’m currently investigating is Parsec, Haskell’s built in parser.
Delivering the power of regular expressions _without_ sacrificing readability.
It is not that much more verbose than that horrendous regex stuff, but I can actually program it without having to resort to some kind of tool that translates it for me.

Here’s a small (unrelated to all of the above) thing I cooked up :

module FileCompare (
    fileDiff
) where


import System.IO (readFile)

failure :: Int -> Int -> String
failure lineIndex colIndex  =
    "Files differ at line : " ++ (show lineIndex) ++ ", column : " ++ (show colIndex) ++ ".";

compareLine :: Int -> Int -> String -> String -> String
compareLine lineIndex colIndex [] [] = 				    ""
compareLine lineIndex colIndex (x:xs) [] = 			    failure lineIndex colIndex
compareLine lineIndex colIndex [] (y:ys) = 			    failure lineIndex colIndex
compareLine lineIndex colIndex (x:xs) (y:ys) | x /= y = failure lineIndex colIndex
compareLine lineIndex colIndex (x:xs) (y:ys) | x == y =	compareLine lineIndex (colIndex + 1)  xs ys

compareLines :: Int -> [String] -> [String] -> String
compareLines lineIndex (x:xs) (y:ys) = 	(compareLine lineIndex 0 x y) ++ (compareLines (lineIndex +1) xs ys)
compareLines lineIndex [] (y:ys) = 	"File two contains more lines then file one."
compareLines lineIndex (x:xs) [] = 	"File one contains more lines then file two."
compareLines lineIndex [] [] = 		"Files are identical."

diff :: String -> String -> String
diff a b = compareLines 0 (lines a) (lines b)

fileDiff :: FilePath -> FilePath -> IO String
fileDiff f1 f2 = do
  fileOne <- readFile f1
  fileTwo <- readFile f2
  return $ diff fileOne fileTwo

Performance equals a C++ version and it can easily handle huge files.

Tell me what you think.

For the imperative minded : start reading at the bottom and then move up .

QuickDotNetCheck still isn’t working the way I want to, but I’m going to let it rest for a little while.
I’ll probably iron out a couple of bugs I have recently introduced, so that I can start using it full-time at work.
But after that I’m going to let the idea ripe in my head a little.

So what to do for fun at home.

And then there’s Haskell…

Particulary interested in getting some web-related stuff working.

There’s a reason I prefer Alan Kaye’s publications over Edgar Dijkstra’s, f.i.

I think it has to do with pragmatism versus arrogance.

When I was in my teens I read about relativity theory.
For fun.
And because I wanted to be the smartest kid on the block.
In those days, it wasn’t exactly common knowledge, and I did have a lot of fun hassling my science teachers with questions they couldn’t answer.

Recently, I’ve noticed, relativity is far more widely understood, and most people coming out of university have a much better grasp of it than I do.

After reading all that, I took some things as axioms :
– nothing travels faster than the speed of light.
– there is no such thing as action at a distance.
– nothing, not even light, can escape a black hole’s gravitational field.
– the conservation laws (notably the second law of thermodynamics, and conservation of baryon number)
– etc…

Most of these things have been proven wrong by observation in recent years.

So theories were adapted, or thrown out completely, as they should be.
Although the latter option does happen less and less.

The one thing that annoys me up to a point of boiling anger, is that some ‘scientists’ seem reluctant to accept an alternative view and even ridicule it, until a ‘peer’ higher up on the pecking order tells them that’s it’s actually a viable idea.

Just visit some of the physics forums for some ‘discussions’ that make some of the net storms in the software blogosphere seem like a friendly exchange of ideas.

The holographic universe theory (and even more so the holographic mind theory) was regarded as fringe theory for a while until some respected scientists got behind it.

Just to make things clear, I have serious apprehensions to above mentioned hypothesis’s (see my previous post), but I would never have to arrogance to debunk it, because I realize I’m not qualified to do so.

Yet, people who have studied longer than I have and should understand the math, seem to have no problem in doing so (debunking it I mean) on just first glance.
And they often employ the same unscientific methods that they accuse the other party of using.

Being just an interested laymen, I’m looking for an objective, scientific approach to the theories/models I’m interested in, and this is really hard to find.

Engelbarts dream seems further off than ever.

And here’s one thing that _really_ ticks me off.

The Crackpot Index, by John C Baez.

The next phrase should be read whilst imagining mr brando in ‘Apocalypse Now’.

‘The Arrogance, The Arrogance, …’.

One should not increase, beyond what is necessary, the number of entities required to explain anything.

So please, science dudes, get a grip.