Comments on: Code Contracts #5: Method purity

By: Bent Rasmussen

Bent Rasmussen — Tue, 02 Mar 2010 06:00:35 +0000

I more pressing question for me is: what about LINQ to Objects. Are iterators impure? — they use IDisposable so I guess yes. That’s a bit of a shame though as they are quite useful for specifications too even if only applied in run-time checks in debug mode.

By: Robert Janzen

Robert Janzen — Sun, 16 Aug 2009 14:02:14 +0000

Hi Matthias,

thank your for this good discussion. It is a great example for demonstration how [Pure()] works. I have a small annotation. I think you don’t need decorate the property getters. Code Contract tools assume the property getters are pure.

Robert

By: Code Contracts #6: Modelling constraints and state | .NET ... out of the dark

Sun, 10 May 2009 08:21:18 +0000

[...] automatically. Code Contracts can help us in this case very well by the use of object invariants. One more time making things explicit helps you as programmer and other programmers that use or extend your [...]

By: Matthias Jauernig

Matthias Jauernig — Mon, 04 May 2009 06:06:31 +0000

Hi AJ,

I didn’t want to dismiss purity as quality completely from the parallelism topic, so perhaps I have failed to express myself very well. What I wanted to say was, that while I see purity as important characteristic, I don’t see direct implications to the topic of auto-parallelism because of this “one side of the medal” thing: A pure method is like “I don’t write shared state, but I can read it”. So I didn’t want to dismiss the relationship in general, but just wanted to say: there is no direct implication, that means an implication that brings auto-parallelism directly to life. If you couldn’t agree again, please let me know. Your opinion is appreciated everytime.

Thanks, Matthias

By: AJ.NET

AJ.NET — Sun, 03 May 2009 12:10:02 +0000

“Are there any direct implications to parallelism? The answer is: no. … one could think, that method purity brings automatic parallelism of calls to such methods to life. But that’s not true.”
I guess I cannot agree with you here. Actually purity is a very important characteristic in the (research) area of automatic parallelization, i.e. letting the compiler or runtime figure out how to parallelize your code.
If you have three calls to pure functions in a sequence, some automat may decide to run them in parallel and without locks. Of course purity is neither sufficient to automating parallelism (e.g. if one method depends on the result of another), nor is parallelism the only end to purity (call rearranging may be done for different reasons). Anyway, dismissing the relationship is like saying “streets are not made for cars” just because streets may also be used by moter cycles and car can drive off-road…