A C# library to write functional code - Part II - Tuples

AC# library to write functional code - Part II - Tuples | Air Condition Service and Supplies in Your City

Wed, 09 Apr 2008 05:00:51 GMT

PingBack from http://airconditioner.crutoo.com/2008/04/08/ac-library-to-write-functional-code-part-ii-tuples/

re: A C# library to write functional code - Part II - Tuples

Jacob — Wed, 09 Apr 2008 19:57:29 GMT

What about:

internal static bool DSEquals<T>(T left, T right) {

if (left == null && right == null)

return true;

if (left == null && right != null)

return false;

var len = left as IEnumerable;

var ren = right as IEnumerable;

if (len == null && ren == null)

return left.Equals(right);

if (len != null && ren != null)

return SequenceEqual(len, ren);

return false;

}

Great work! What about anonymous types?

Adam Cooper — Wed, 16 Apr 2008 16:47:44 GMT

Luca,

Thanks so much for sharing this, both your posts and the source code.

I really like your idea of bringing some (more) of F#'s goodness to C#. I spent some time investigating if F# was the right tool for some of our company projects and, while I think F# is fantastic, our domain is one of storing and retrieving lots of hierarchical data, a domain which is ideal for an object-oriented language like C#. So C# is the clear choice for us (in the vast majority of cases). However, there are quite a few aspects of functional programming I'm really beginning to admire.

I've never been happy with the OO paradigm of many-inputs-one-output, and I find your Tuples solution exciting. Can you comment on how your Tuples implementation differs from anonymous types in C#?

Thanks and keep up the good work,

Adam Cooper

re: A C# library to write functional code - Part II - Tuples

lucabol — Wed, 16 Apr 2008 19:26:06 GMT

Thanks for the kind words.

There are two differences:

1. Anonymous types allow you to give a name to each property, while tuple don't.

2. You cannot return anonymous types from methods or passing them as parameters. So their used is limited to the body of a method.

Overall anonymous types are a mix of tuples and records. I'll talk about records in an upcoming post.

A C# library to write functional code - Part III - Records

Luca Bolognese's WebLog — Mon, 21 Apr 2008 20:35:42 GMT

Previous posts: Part I - Background Part II - Tuples Now that we know what Tuples are, we can start talking

Community Convergence XLIII

Charlie Calvert's Community Blog — Wed, 23 Apr 2008 23:58:14 GMT

Welcome to the forty-third issue of Community Convergence. The last few weeks have been consumed by the

re: A C# library to write functional code - Part II - Tuples

Configurator — Thu, 24 Apr 2008 11:12:14 GMT

I'm wondering: Doesn't CheckNull cause an infinite loop?

Usually when checking null, I would use ReferenceEquals(t, null) because == would call the type's operator ==, which checks for null causing an infinite loop.

If CheckNull accepted an object and wasn't generic, if would use object's ==, which works for null. But since it's generic it should use the == that you supplied.

Am I missing something here?

re: A C# library to write functional code - Part II - Tuples

Eamon Nerbonne — Thu, 24 Apr 2008 12:04:04 GMT

I've also needed to build these things, and have also run into some of the same issues you seem to have here - like the surprising unhandiness of structs (and even more surprising slowness).

Incidentally, your hash-code is no good. You don't want to use a symmetric combination of two hash codes, since that means that F.Tuple(true,false) is equal to F.Tuple(false, true) in terms of hashcode. A non-symmetric combination is probably best; but the instantly obvious subtraction is definitely not a good idea, since that means that all tuples of two elements with identical members have a hash-code of 0.

I choose to scale the hashcode with a prime number. Trial and error on my test-set (consisting of lower-case strings which may not be representative for others) found that 137 is fine; so that's what I use, but I haven't researched the issue.

Further, if your tuples will be used extensively in things like lookup tables, then hash-code calculation becomes relevant: you might want to store the hashcode once and reuse it (which can also help speed up equality comparisons when these are performed outside of a hash table).

re: A C# library to write functional code - Part II - Tuples

lucabol — Thu, 24 Apr 2008 20:11:46 GMT

It doesn't go into an infinite loop because it is generic. We cannot call the overload == because at that point in the code we don't know what it is. So we box it and 'compare the pointer' insted. The commented IL for the function should clarify:

.method public hidebysig static void CheckNull<T>(!!T t) cil managed

{

.maxstack 2

.locals init (

[0] bool CS$4$0000)

L_0000: nop

L_0001: ldarg.0

L_0002: box !!T // We box it

L_0007: ldnull

L_0008: ceq // We compare it

L_000a: ldc.i4.0

L_000b: ceq

L_000d: stloc.0

L_000e: ldloc.0

L_000f: brtrue.s L_0017

L_0011: newobj instance void [mscorlib]System.ArgumentNullException::.ctor()

L_0016: throw

L_0017: ret

}

re: A C# library to write functional code - Part II - Tuples

lucabol — Thu, 24 Apr 2008 20:12:23 GMT

Eamon: I know my hash is bad. I was too lazy to produce a better one :)

re: A C# library to write functional code - Part II - Tuples

David Nelson — Mon, 28 Apr 2008 07:42:14 GMT

The problem with your "this should never be null" logic is that it prevents the user from ever writing code like this:

Tuple<int, int> MyMethod()

{

Tuple<int, int> result = null;

// Some code which may or may not set result

if(result == null)

{

// Some other code which always sets the result

}

return result;

}

This is a reasonably common pattern. Your code is checking for null in the wrong place. It is not unreasonable that any Tuple reference might sometimes be null. Tuples should only be checked for null where it is sure that they should never be null.

re: A C# library to write functional code - Part II - Tuples

lucabol — Mon, 28 Apr 2008 20:27:17 GMT

Hi David,

I used this code to learn functional programming. In that style variables are immutable, which makes the code you present invalid. So, in my scenario, my decision makes sense.

In a more generic sense, you have to trade off the annoyance of not being able to write the code you present and the annoyance of not catching bugs because you return false instead of throwing. Reasonable people can come up in different places in that debate.

Tuples vs. Dictionaries

John Mertus — Sun, 04 May 2008 04:56:50 GMT

Why not just return a dictionary from the function. The key of the dictionary are the names of the elements of the class, the value objects. For example

var Person = GetPerson(<some id>);

int age = Person["age"]).ToInt32()

string name = Person["FirstName"].ToString();

(Here .ToInt32 is the damn extension C# should have for objects, why the hell doesn't it)

Of course

The big problem is the data binding becomes a var in the java sense; that it is like a late binding and fails at runtime not compile time. But it gives a better syntax and is more readable than tuples.

re: A C# library to write functional code - Part II - Tuples

David Nelson — Mon, 05 May 2008 01:47:21 GMT

@John

"Here .ToInt32 is the damn extension C# should have for objects, why the hell doesn't it"

Because the vast majority of types cannot be reasonably represented by an Int32. Presumably if such a ToInt32 method existed, these types would all have to throw an exception. Why would you want to add a parsing method to every single object which will fail most of the time?

The Quest for Quick-and-Easy Immutable Value Objects in C#

adamjcooper.com/blog — Tue, 03 Jun 2008 23:59:59 GMT

The Quest for Quick-and-Easy Immutable Value Objects in C#

A C# library to write functional code - Part V - The Match operator

Luca Bolognese's WebLog — Tue, 15 Jul 2008 12:46:24 GMT

Other posts in the series: Part I - Background Part II - Tuples Part III - Records Part IV - Type Unions