Immutability in C# Part Two: A Simple Immutable Stack

MSDN Blog Postings » Immutability in C# Part Two: A Simple Immutable Stack

MSDN Blog Postings » Immutability in C# Part Two: A Simple Immutable Stack — Tue, 04 Dec 2007 21:28:05 GMT

PingBack from http://msdnrss.thecoderblogs.com/2007/12/04/immutability-in-c-part-two-a-simple-immutable-stack/

re: Immutability in C# Part Two: A Simple Immutable Stack

TSHAK — Tue, 04 Dec 2007 22:42:54 GMT

Correct me if I'm wrong, but with this approach if I wanted to get the traditional behavior of Stack.Pop I would need to perform a Stack.Peek before Stack.Pop as the value (i.e. "head") is not part of the Stack returned by Stack.Pop. I find this odd, but maybe only due to how I've been programmed to think about a Stack.

re: Immutability in C# Part Two: A Simple Immutable Stack

J D — Tue, 04 Dec 2007 23:47:32 GMT

TSHAK:

That's true, but I can't imagine it could reasonably work any other way and still preserve immutability.

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Wed, 05 Dec 2007 00:01:08 GMT

Any why is it the case that _looking_ at a data structure should _require_ you to change its contents? That has never made any sense to me.

re: Immutability in C# Part Two: A Simple Immutable Stack

AdamM — Wed, 05 Dec 2007 00:42:59 GMT

That's the same behavior as the STL's stack class. Seems reasonable (and not at all unusual) to me.

re: Immutability in C# Part Two: A Simple Immutable Stack

Jay Bazuzi — Wed, 05 Dec 2007 00:57:29 GMT

Cool stuff.

I'd make one change, from:

private static readonly EmptyStack empty = new EmptyStack();

public static IStack<T> Empty { get { return empty; } }

to:

public static IStack<T> Empty = new EmptyStack();

As per:

http://blogs.msdn.com/jaybaz_ms/archive/2004/04/29/123333.aspx

Keep up the immutable fight! (whatever that means)

re: Immutability in C# Part Two: A Simple Immutable Stack

Kaveh Shahbazian — Wed, 05 Dec 2007 01:36:40 GMT

I wrote something like a Monad (which I have named it Monad!) in C# 3. I can achieve immutability throe it to an acceptable degree. Still I am meditating on it. But it looks somehow interesting to me. Here is the code:

public class Monad<T> : IMonad<T>

{

private Monad (T inner) { this.__InnerHolder = inner; }

private Monad () { }

private readonly T __InnerHolder;

private T Inner { get { return __InnerHolder; } }

public static IMonad<TInner> Unit<TInner> (TInner inner) { return new Monad<TInner> (inner); }

public static Func<A, IMonad<R>> Lift<A, R> (Func<A, R> fun)

{

if (fun.IsNull ()) throw new ArgumentNullException ("fun", "'fun' can not be null.");

return (a => Unit<R> (fun (a)));

}

public static IMonad Bind<A, B> (IMonad<A> a, Func<A, IMonad> fun)

{

if (fun.IsNull ()) throw new ArgumentNullException ("fun", "'fun' can not be null.");

return new Monad (fun (a.Monad.Inner).Monad.Inner);

}

#region IMonad<T> Members

Monad<T> IMonad<T>.Monad

{

get { return this; }

}

#endregion

}

public static partial class MonadExtra

{

public static IMonad<TInner> Unit<TInner> (this TInner inner) { return Monad<object>.Unit<TInner> (inner); }

public static Func<A, IMonad<R>> Lift<A, R> (this Func<A, R> fun)

{

return Monad<object>.Lift<A, R> (fun);

}

public static IMonad Bind<A, B> (this IMonad<A> a, Func<A, IMonad> fun)

{

return Monad<object>.Bind<A, B> (a, fun);

}

public interface IMonad<T>

{

Monad<T> Monad { get; }

}

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Wed, 05 Dec 2007 02:35:35 GMT

Quite fine. You can think of C# 3.0 query expressions as using a form of monads. I might do a series of blog articles about that at some point.

re: Immutability in C# Part Two: A Simple Immutable Stack

grauenwolf — Wed, 05 Dec 2007 07:39:55 GMT

Why doesn't Pop use a ref variable to return the value?

re: Immutability in C# Part Two: A Simple Immutable Stack

Kaveh Shahbazian — Wed, 05 Dec 2007 09:29:33 GMT

Sorry for scrambled code! I have replaced < and > with html literals. It seems that i was wrong about them!

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Wed, 05 Dec 2007 10:50:47 GMT

For the third time: why should it be necessary to _change_ the data structure in order to _look_ at it? A Pop which returns the value is a design flaw; it conflates two logically distinct and separate operations into one method.

re: Immutability in C# Part Two: A Simple Immutable Stack

silky — Wed, 05 Dec 2007 13:11:09 GMT

this is fine enough i suppose, but it seems that it just pushes management to someone else.

i.e. you, the caller, now have to constantly pass the stack around, instead of having it as a member variable or similar.

i mean it's immutable, fine. but so what? now life is harder when we use it. it kind of seems like this sort of strategy would be more error prone; pushing more work back onto the caller.

re: Immutability in C# Part Two: A Simple Immutable Stack

Anthony Jones — Wed, 05 Dec 2007 16:46:29 GMT

Silky, This only part 2. You have to be patient and wait for the Journey to unfold.

re: Immutability in C# Part Two: A Simple Immutable Stack

Steve — Wed, 05 Dec 2007 16:48:43 GMT

@Jay:

public static readonly IStack<T> Empty = new EmptyStack();

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Wed, 05 Dec 2007 18:46:57 GMT

I don't understand; why can you not have an immutable stack as a member variable? (In a couple posts I'll be having data structures with immutable stacks as member variables.)

Integers are also immutable. What are the disadvantages of immutable stacks which are shared by immutable integers? How do immutable integers "push work back onto the caller"?

re: Immutability in C# Part Two: A Simple Immutable Stack

Tom Kirby-Green — Wed, 05 Dec 2007 19:34:24 GMT

I think silky was objecting to:

this.s = this.s.Push(...);

rather than just:

this.s.Push(...);

Given the advantages that immutability gives you when thinking about systems in flight I think the tiny bit of extra syntax is a very small code tax.

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Wed, 05 Dec 2007 20:37:16 GMT

If that is really your concern then you are clearly not yet in the "immutable" mindset. Why would you change the value of a member variable? Design the system so that the "variable" is immutable, and you never need to worry about changing it!

re: Immutability in C# Part Two: A Simple Immutable Stack

Thomas Danecker — Wed, 05 Dec 2007 22:11:30 GMT

I'd love to see such immutable objects in the framework soon. The implementation is that easy and straight-forward and it's so nice to work with immutable things when doing parallel stuff. It's really a very important requirement (in addition to the parallel extenstions) of .net to be successfull in the future where heavy parallelism is as important as oop.

If someone really can't live with the IMO clean distinction between pop and peek, it's as easy as one simple extension method to have what you want:

public static IStack<T> Pop(this IStack<T> stack, out T value)

{

value = stack.Peek();

return stack.Pop();

}

re: Immutability in C# Part Two: A Simple Immutable Stack

silky — Thu, 06 Dec 2007 02:17:01 GMT

Tom: Yes, that's what I mean.

Eric: Look at what tom has done; his usage there shows that he's kind of bypassed the point of your immutable stack. From his apps perspective "this.s" is not immutable. It changes because it's constantly re-assigned to something new.

The point is that he still needs to use the stack in a non-immutable fashion (i.e. changes need to be reflected in other parts of the code, etc).

My point was that an immutable stack is fine (I understand the concept) but it still requires you to use it differently (which you could do just as fine with a regular stack). The only difference is that it forces you to. Which is, I suppose, your point, but to me it seems more interesting to perhaps focus on the mysterious surrounding implementation that will make the application using this stack more "Thread Safe" then one that doesn't. It'll still require a smart programmer to do it, IMHO.

re: Immutability in C# Part Two: A Simple Immutable Stack

Gabe — Thu, 06 Dec 2007 12:36:28 GMT

I think Thomas has a good idea. It's pretty rare that I want to remove an item from a stack without looking at it. Hence, it makes sense to combine those two operations. That combination of operations is traditionally called Pop, thus I expect an operation called Pop to both remove an item from a stack and tell me what it is. Otherwise you've just reimplemented a List, only with methods named Peek/Pop/Push instead of car/cdr/cons.

All stacks should have a Push and Peek that work as implemented here. However, I've never seen something called a Stack with an operation that discards the top item and doesn't return it. The Pop function that doesn't return the item should be called something like Discard.

It would be nice if I could do this in C#:

Stack<T> s; var v;

s, v = s.Pop();

re: Immutability in C# Part Two: A Simple Immutable Stack

Gonzalo — Thu, 06 Dec 2007 13:08:15 GMT

Wouldn't it be better to define Pop as follows?

public T Pop(out IStack<T> stack)

{

stack = tail;

return head;

}

re: Immutability in C# Part Two: A Simple Immutable Stack

Thomas Danecker — Thu, 06 Dec 2007 13:50:07 GMT

The benefit of the other implementation (I think the pattern also has a name but I don't remember) is, that you can do the following:

T one, two, tree;

stack.Pop(out one).Pop(out two).Pop(out three)...

This pattern is very nice.

Eric, it would be nice to have same typical usage pattern of this immutable stack. The community here doesn't see the possibilities, an immutable stack would offer to us.

Though I also can't imagine of anything really concrete yet.

The stack would be useful if you're passing it to other methods. But you'd be required to wait for the invoked method till it returns a stack without the element popped by this method. Not really a parallel workflow.

IMO, for a parallel workflow, you'd rather need an atomic pop method which also returns the popped element.

With this immutable stack you'll have to do something like this:

T item = stack.Peek();

tellOthers(stack.Pop());

This task can't be run in parallel without any synchronization.

I like immutable types and I think there's really a way to use them in a reasonable fashion. I also like Eric's implementation in this post, really nice.

So my question to Eric: How is this stack used? I just can't imagine...

re: Immutability in C# Part Two: A Simple Immutable Stack

Thomas Danecker — Thu, 06 Dec 2007 14:03:47 GMT

That's how it could be used in a parallel world:

Stack<T> temp;

{

temp = stack;

}

while(Interlocked.CompareExchange(ref stack, temp.Pop(), temp));

T value = temp.Peek();

It's nicer than the usage of a mutable stack, but not nice.

re: Immutability in C# Part Two: A Simple Immutable Stack

silky — Thu, 06 Dec 2007 15:21:26 GMT

IMHO a Pop without looking at the contents of the stack is actually quite common.

re: Immutability in C# Part Two: A Simple Immutable Stack

Dave — Thu, 06 Dec 2007 17:22:46 GMT

I think I've actually used stacks that use the Peek/Pop style more than the Pop-only style. For example, STL's stack template has a top() to grab the top element and a pop() that returns nothing.

re: Immutability in C# Part Two: A Simple Immutable Stack

Olmo — Thu, 06 Dec 2007 18:53:57 GMT

Hi Thomas, I was just tinking in a solution like yours. Would be possible to make a helper method for this common operation for any kind or inmutable data structures:

Assign(ref stack, s=>s.Pop());

Where

void Assign<T>(ref variable, Func<T,T> fun)

{

T val;

{

temp = variable;

}

while(Interlocked.CompareExchange(ref variable, fun(temp), temp));

}

God bless lambdas :)

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Thu, 06 Dec 2007 19:04:46 GMT

Re: don't you always want to see what you're popping?

No, you don't. For example, consider the stack used by the script engine runtime to keep track of temporary variables. We have separate operations for "peek at the temporary variables" and "these temporaries are dead, remove them from the stack". We have no need to know what the _values_ of the temps are when they become dead!

I am not sure why I have to keep on saying this. Peeking and popping are logically distinct operations. If you want to combine them, then you can always write an extension method which does so. But if you package them together and later want to split them apart, that's hard to do. A well-designed interface is factored so that things which are logically distinct are actually distinct.

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Thu, 06 Dec 2007 19:07:34 GMT

Re: when would you use immutable objects?

I wrote a program just the other day that has two threads. One constantly recalculates what comes down to an immutable bitmap. The other thread takes whatever bitmap is the latest available and displays it. I do not need to ever worry that the drawing thread's "copy" will ever be updated halfway through rendering, because the structure in question is immutable. Likewise, the calculation thread doesn't ever have to worry that it can't continue to do calculations because it is waiting on the rendering thread to unlock the resource for writing.

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Thu, 06 Dec 2007 19:09:17 GMT

Or, here's another use. Suppose you have a database consisting of an immutable search tree. You add and delete a bunch of stuff from the tree. If you have an immutable stack of immutable search trees, then you can do undo/redo operations trivially and efficiently on add/delete operations on the search tree. Undo/redo is usually both more efficient and much more straightforward to implement if you have immutable state.

re: Immutability in C# Part Two: A Simple Immutable Stack

J. Daniel Smith — Wed, 12 Dec 2007 00:29:19 GMT

How about enabling Code Analysis? (throw InvalidOperationException() instead of a raw Exception()).

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Wed, 12 Dec 2007 01:45:10 GMT

Showcasing well-designed exception handling is not the point of this series of articles.

re: Immutability in C# Part Two: A Simple Immutable Stack

David — Thu, 13 Dec 2007 02:18:22 GMT

@Eric,

But in your bitmap example, there still has to be a thread-safe way for the drawing thread to 1) replace its current copy with the latest copy, or 2) retrieve the current copy on every iteration (depending on how it is implemented). This of course is not difficult to do, but once you have done it, what advantage does the immutability of the data structure really offer you? Your threads are never accessing the same object at the same time, so what difference does it make whether it is immutable or not? All you have really made a case for is duplicating objects rather than making them thread-safe; that is not the same thing as making them immutable. I think you have still yet to make a compelling case for why building thread-safety into C# and/or the CLR is an advantage.

re: Immutability in C# Part Two: A Simple Immutable Stack

Ruxo — Fri, 21 Dec 2007 13:02:34 GMT

Look at this Stack abused class:

class WorkQueue {

private IStack<WorkItem> workQueue = Stack<WorkItem>.Empty;

public void EnqueueWorkItem(WorkItem item) {

workQueue = workQueue.Push(item); // No lock needed because it's immutable??

}

public WorkItem DequeueWorkItem() {

WorkItem topItem = workQueue.Peek();

workQueue = workQueue.Pop(); // No lock needed because it's immutable??

}

Does this mean "thread-safe" ability of immutable objects can't apply here, doesn't it? Because, in practical use, you still have to sync those operations in parallel world.

So what is the really benefit of immutable object? Isn't it just syntactic sugar?

re: Immutability in C# Part Two: A Simple Immutable Stack

Michael Parker — Fri, 21 Dec 2007 20:48:51 GMT

Ruxo, the stack in your example is still thread-safe - it is WorkQueue that isn't thread-safe, and you'll notice that it isn't immutable...

re: Immutability in C# Part Two: A Simple Immutable Stack

Ruxo Zheng — Sat, 22 Dec 2007 07:25:22 GMT

Thanks Michael. Point taken. But, then, where's the real benefit of Stack's "thread-safe"? The point is, I think, working with a stack, we usually need to access one with the most updated data. So we need synchronization at some place. This immutable stack so seems like new way to express the usage. Would it finally become style preference fight?

re: Immutability in C# Part Two: A Simple Immutable Stack

Jared Parsons — Thu, 03 Jan 2008 04:22:53 GMT

I love this series.

The only part I don't like is that Stack<T>.Pop returns an IStack<T>. Instead have Stack<T> be non-sealed and define virtual members. Let EmptyStack overrdie the bad ones that need to throw (Pop,Push,Peek).

Since you're no longer dealing with a sealed class, the Jitter won't be able to avoid virtual calls for the Pop,Push,Peek methods. However since most methods in the original implementation return interfaces. AFAIK (which doesn't mean it's still true) all mtehod calls on interfaces require virtual dispatch because it could be a Transparent Proxy. This was true ages ago though so I'm not suer if it's still valid.

The upside is that you don't have to worry about Stack<T> vs IStack<T>.

</nit picky complaint>

re: Immutability in C# Part Two: A Simple Immutable Stack

roaan — Thu, 03 Jan 2008 16:47:47 GMT

Would one still define this stack as immutable if T is mutable.

It probably depends what one defines as the "state" of the object.

If one was to take a snapshot of the object (call it s1), then call stack.Peek.DoSomethingMutable(), then take another snapshot (s2), then s1 != s2.

(Again, depending on the definition of equals)

This then begs the question how deep must the "immutablility" be (e.g. member variables, member variables of member variables, member variables of member variables of member variables) in order for an object do be defined as immutable.

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Thu, 03 Jan 2008 19:04:19 GMT

That question was the subject of part one of this series. Did you start with part two?

re: Immutability in C# Part Two: A Simple Immutable Stack

roaan — Thu, 03 Jan 2008 19:48:07 GMT

Yes :$

Found part one, thanks

re: Immutability in C# Part Two: A Simple Immutable Stack

Jeff Hartmann — Fri, 04 Jan 2008 15:23:21 GMT

This stack has no utility to multithreaded programming when more then one thread is getting objects from the stack. Peek and Pop are traditionally combined into a single operation (which is atomic or locked in the multithreaded case) so that an external lock around both the peek and pop operation is not needed. If one thread is putting things on the stack and two others are getting work from it in a LIFO fashion then they can both get the same piece of information to work on.

Of course this is most likely not the problem this stack was designed to solve.

Immutable data structures can be nice, but well designed syncronized/atomic operations still need to be used to communicate between the threads.

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Fri, 04 Jan 2008 19:35:29 GMT

> Of course this is most likely not the problem this stack was designed to solve.

Correct. There are (at least) two kinds of thread safety:

1) Objects are "thread safe" because all changes made by all threads are visible to all threads.

2) Objects are "thread safe" because changes made by one thread are invisible to other threads.

Immutable stacks implement the latter kind of safety. A safe-in-the-latter-sense stack has the property that it has predictable behaviour. You push something on it, it gets one bigger. A safe-in-the-first-sense stack does not have this property -- you push something on it, and you have absolutely no idea what the size of that thing is because n other threads might have been pushing and popping it at the same time.

And, combining this with the comments above -- in a stack designed to have the first kind of thread safety, it makes more sense to combine "peek" with "pop". After all, you have no idea after "peeking" the stack that the item you just peeked is still on the top of the stack, or even on the stack at all. Eliminating peek means that you can at least guarantee that popping the stack gives you an element that was once at the top of the stack and is no longer.

re: Immutability in C# Part Two: A Simple Immutable Stack

Koos Dering — Tue, 08 Jan 2008 09:52:22 GMT

One would think Eric wants an object-type between 'struct's and 'class'es: (at compilers' discretion) having reference-implementation but always value-semantics.

re: Immutability in C# Part Two: A Simple Immutable Stack

Francois Tanguay — Wed, 09 Jan 2008 07:17:22 GMT

Two things:

Regarding Pop returning the Head:

public static class StackExtensions

{

public static IStack<T>(this IStack<T> stack, out T value)

{

value = stack.Peek();

return stack.Pop();

}

And as to users who want "mutable usage", you could do a mutable wrapper

public class MutableStack<T>

{

private IStack<T> innerStack;

public MutableStack(IStack<T> stack) { innerStack = stack; }

public void Push(T value) { innerStack = innerStack.Push(value); }

public T Pop() { T value; innerStack = innerStack.Pop(out value); return value; }

public bool IsEmpty { return innerStack.IsEmpty; }

public T Peek() { return innerStack.Peek(); }

}

re: Immutability in C# Part Two: A Simple Immutable Stack

Jim W. — Tue, 15 Jan 2008 18:18:10 GMT

Thanks for the great ideas... I'm actually thinking an immutable stack might be great as the Undo/Redo stack in a puzzle game I'm building. It might even come in handy in the puzzle generation phase... providing a nice way to manage and analyze alternative "paths".

re: Immutability in C# Part Two: A Simple Immutable Stack

Richard K. — Wed, 16 Jan 2008 03:18:12 GMT

Eric,

Thread safety is more than just 'immutable'. In systems where performance is an issue, where thread safety is an issue, and where stack size can be significant, an immutable stack provides one type of thread safety at the cost of performance (in much the same way immutable strings can impact performance if you don't take the underlying mechanisms of strings into account).

I do not deny that immutability is a way to solve these problems, but we can't oversimplify the problem of parallel programming. The trade-offs between the use of immutable objects (strings, stacks, whatever) vs. more traditional techniques must be COMPLETELY understood by the engineers solving the problems, there is no simple 'off the shelf solution'.

If you are not implying this, my apologies, I just seem to be getting this impression from many in this thread, and its dangerous thinking (there are no silver bullets).

re: Immutability in C# Part Two: A Simple Immutable Stack

Eric Lippert — Wed, 16 Jan 2008 03:28:16 GMT

Of course there are no silver bullets in multithreaded programming. That is a corrollary of the fact that there are no silver bullets in ANY kind of programming. A point that I return to over and over again in this blog is that good design and engineering is a process of making and identifying tradeoffs.

My point in this series is merely to point out that designing, implementing and using immutable data structures gives you yet another tool in your toolbox which you can consider when faced with a tough problem, particularly a problem involving multithreading. Whether it is the right tool or not depends upon the task at hand.

Immutability in C#

Community Blogs — Thu, 17 Jan 2008 02:45:08 GMT

For some reason, there's been a lot of buzz lately around immutability in C#. If you're interested in

re: Immutability in C# Part Two: A Simple Immutable Stack

Richard K — Fri, 18 Jan 2008 00:41:29 GMT

Eric,

Excellent.. then you and I are in agreement, since there are most definitely uses for immutability in the toolbox... as long as they are intelligently applied.

re: Immutability in C# Part Two: A Simple Immutable Stack

Siderite — Wed, 23 Jan 2008 18:35:58 GMT

I have to agree with Kaveh Shahbazian on this one: fun cannot be null. :)

My question is why change a way of programming in order to teach people immutability when you can change the compiler to take care of things like that in care of concurency and multi-processor computing? I think the whole FP and immutability buzz is generated by people thinking to abstractly to be able to debug anything :)

PipeSingleReaderNoLock

jaredpar's WebLog — Mon, 03 Mar 2008 08:46:39 GMT

Previously we discussed a multi-thread safe queue like data structure using locks as an internal synchronization

PipeSingleReaderNoLock

Noticias externas — Mon, 03 Mar 2008 08:55:54 GMT

Previously we discussed a multi-thread safe queue like data structure using locks as an internal synchronization

Immutability

Steve's Tech Talk — Mon, 17 Mar 2008 19:17:26 GMT

Functional programming is in. There is a lot of buzz around the future of functional programming as applications

re: Immutability in C# Part Two: A Simple Immutable Stack

Gustav — Tue, 22 Jul 2008 17:11:07 GMT

This is genius...

I'm using this algorithm to store the numbers 1-40 in a immutable stack:

IStack<int> s0 = Stack<int>.Empty;

IStack<int> s1 = s0.Push(1);

IStack<int> s2 = s1.Push(2);

IStack<int> s3 = s2.Push(3);

IStack<int> s4 = s3.Push(4);

IStack<int> s5 = s4.Push(5);

IStack<int> s6 = s5.Push(6);

IStack<int> s7 = s6.Push(7);

IStack<int> s8 = s7.Push(8);

IStack<int> s9 = s8.Push(9);

IStack<int> s10 = s9.Push(10);

IStack<int> s11 = s10.Push(11);

IStack<int> s12 = s11.Push(12);

IStack<int> s13 = s12.Push(13);

IStack<int> s14 = s13.Push(14);

IStack<int> s15 = s14.Push(15);

IStack<int> s16 = s15.Push(16);

IStack<int> s17 = s16.Push(17);

IStack<int> s18 = s17.Push(18);

IStack<int> s19 = s18.Push(19);

IStack<int> s20 = s19.Push(20);

IStack<int> s21 = s20.Push(21);

IStack<int> s22 = s21.Push(22);

IStack<int> s23 = s22.Push(23);

IStack<int> s24 = s23.Push(24);

IStack<int> s25 = s24.Push(25);

IStack<int> s26 = s25.Push(26);

IStack<int> s27 = s26.Push(27);

IStack<int> s28 = s27.Push(28);

IStack<int> s29 = s28.Push(29);

IStack<int> s30 = s29.Push(30);

IStack<int> s31 = s30.Push(31);

IStack<int> s32 = s31.Push(32);

IStack<int> s33 = s32.Push(33);

IStack<int> s34 = s33.Push(34);

IStack<int> s35 = s34.Push(35);

IStack<int> s36 = s35.Push(36);

IStack<int> s37 = s36.Push(37);

IStack<int> s38 = s37.Push(38);

IStack<int> s39 = s38.Push(39);

IStack<int> s40 = s39.Push(40);

programming was never easier before, but the best is, it's threadsafe ;) no one will ever change the stuff i stored in the stack.

thank you Eric, made my day...

re: Immutability in C# Part Two: A Simple Immutable Stack

Daniel Earwicker — Tue, 11 Nov 2008 18:26:23 GMT

I'm coming to this really late, and I'm probably failing to see the joke, so this is a waste of time, but I can't resist informing Gustav that he could have written:

Enumerable.Range(1, 40).Aggregate(Stack<int>.Empty, (s, n) => s.Push(n));

ImplicitStyleManager: Under the Hood

Microsoft Weblogs — Mon, 24 Nov 2008 23:46:46 GMT

In this post I'll delve into the functional programming techniques that were used to develop ImplicitStyleManager

re: Immutability in C# Part Two: A Simple Immutable Stack

Saw — Thu, 27 Nov 2008 12:20:51 GMT

IStack<int> s1 = Stack<int>.Empty;

IStack<int> s2 = s1.Push(10);

s2 = s2.Push(15); //??

would it possible or should the above statement exists in immutable world?

I tried to run the statement, and it appear that the s2 now has head with value 15, and it's tail have a IStack which the head value is 10. Kinda strange to me as I still new to this world.

It is consider that the s2 been mutated?

re: Immutability in C# Part Two: A Simple Immutable Stack

Saw — Fri, 28 Nov 2008 04:32:15 GMT

Here is a link talk about the rules for immutable type:

http://www.bluebytesoftware.com/blog/2007/11/11/ImmutableTypesForC.aspx

Rules number five:

5. Immutable types must not leak the ‘this’ reference during construction.

public IStack<T> Push(T value) { return new Stack<T>(value, this); }

Wonder if the above statement break the rules?

InvocationExpression and LINQ to Entities

meek — Sun, 07 Dec 2008 17:19:03 GMT

I talked a little bit about patterns using InvocationExpression in a previous post (you might want to

InvocationExpression and LINQ to Entities

VS2010学习 — Wed, 10 Jun 2009 09:20:01 GMT

I talked a little bit about patterns using InvocationExpression in a previous post (you might want to