Spec#

ALT.NET Open Spaces, Seattle Day 2 Recap

Matthew Podwysocki — Tue, 22 Apr 2008 23:14:41 GMT

In my previous installment of recapping the events from ALT.NET Open Spaces, Seattle, I covered pretty much the opening ceremonies as it were. The weather was definitely interesting the entire weekend. Who would believe that we had snow, hail and rain for most of the time we were there in the latter half of April? Mind you it didn't stick, but if you believe in God, there is something to be said of ALT.NET coming to town.

Coverage Galore

Jeffrey Palermo was gracious enough to capture the opening ceremonies on video for all to see. Here are some of the videos and they are well worth watching. Really gives you an idea of how to run a good Open Spaces. Doc did a wonderful job as a facilitator for the event. And yes, that's me in the black coat in the background setting up for the event.

ALT.NET Open Spaces, Seattle - Part 1
An introduction by Doc on the meaning of Open Spaces
ALT.NET Open Spaces, Seattle - Part 2
More introduction and the suggestion of topics. Everyone who submitted topics had to get in the middle of the room and declare their topic of interest.
ALT.NET Attendees - Why Did You Come to ALT.NET?
Jeffrey interviews various attendees such as the some Microsofties (Scott Guthrie, Harry Pierson, Glenn Block, Don Smith), CodeBetter guys (Greg, Jeremy, JP Boodhoo, Ian Cooper), Scott Bellware, the Israelis (Udi, Roy, Justin and Ayende), Martin Fowler, John Osborn, Jim Shore, etc on what ALT.NET means to them and why they came.

Dave Laribee also has a ton of video as well. Most recently, the Fishbowl conversation about the polyglot programmer has been posted here. The debate starts with Jeremy Miller, Ted Neward, Charlie Calvert, Scott Hanselman and others. Really good conversation posted.
So, as you can see from the videos it was a pretty diverse crowd. And, hey, we managed to get all of 5 women there too! Peter Laudati posted the schedule here which was initialed by all who wanted to see that particular discussion.

IronRuby Session

Since John Lam wasn't around on Friday for the topic submittal, I so graciously put his name in for him. Luckily he agreed so we were good to go for the first session. We didn't have any canned presentations which is nice. Instead, John focused more on how far IronRuby has yet to go. It was interesting that he is using the Rubinius specs in order to validate IronRuby. Also of note, it was pretty cool to see that Spec# has been used for the IronRuby compiler.

Covering Spec#

Unfortunately, the functional programming talk that I planned with Dustin Campbell was put right along side the Spec# talk, so I had to make a choice. I picked Spec# as it was the first Open Spaces they had done. As I said before, one of the major things I wanted to talk about was Spec# at ALT.NET. Both Greg Young and I were pretty interested in getting Rustan Leino and Mike Barnett to show off the technology to the masses. And what better way than to show a bunch of geeks like us this technology. Anyhow, Mike and Rustan did a really good presentation to show off Spec# to a mass audience. For those not familiar with Spec#, I did a whole series on this on my old blog here. Basically, the intent of Spec# is to provide Design by Contract specifications in your classes and have that exposed to the outside world. So, no more guessing about the preconditions, postconditions and invariants of your system, instead, we can be pretty explicit about it.

The problem that they are facing is that Spec# is not just an additive to the C# compiler, instead it's a separate compiler that is compliant with the C# 2.0 specification. The problem is that C# 3.0 introduces a few more items, albeit mostly syntactic sugar for the most part, and yet Mike is really one of the only guys doing the Spec# compiler. So, making it C# 3.0 compliant is a pretty daunting task. Instead, a future focus is on making language neutral pieces available to all .NET languages just as we saw briefly in the System.Core.dll assembly under the Microsoft.Contracts namespace. The point of inviting them was to help bring their cause to a wider audience. Anders Hejlsberg and Mads Torgersen need to put this on their mind as to how to incorporate, and I'll make sure it's widely known.

It was great to see Scott Hanselman quite excited about the technology and hopefully you'll see more of it from him soon. Also, stay tuned to InfoQ for more Spec# related items as well. I intend to cover things again shortly to talk about some other new things in Spec# as well as the new release. Stay tuned for that...

ASP.NET MVC

Phil Haack and Brad Abrams hosted a discussion on ASP.NET MVC which was pretty positive overall. There has been a number, around 5% that Microsoft has been throwing out there as a number of people that would be adopting ASP.NET MVC over traditional web forms. The audience was rightly skeptical of such a number and wish that they would cut it out. Instead, it could have the effect of scaring away people from adopting this framework as their choice for ASP.NET web applications. I can totally understand that the numbers could be there due to the ISV market which make controls for ASP.NET web forms which is something that the MVC framework doesn't support. Another request was to support open source javascript frameworks better. But overall, Phil and Brad were pretty receptive and it was an overall positive experience.

Are We Innovating?

Scott Hanselman convened a talk asking "Are We Innovating or Are We Just Porting?" in which that very question was asked. If you look at the open source frameworks that exist within the .NET space, it's not hard to see what he's talking about:

JUnit => NUnit, MbUnit, xUnit.net
Hibernate => NHibernate
Spring => Spring.NET
Ruby on Rails => MonoRail
jMock => NMock, Rhino Mocks, Moq
And the list goes on...

But when you look at the list the other way around, we really don't see it going the other way. Is it because that in the Java world, frameworks weren't provided by Sun as they were for Microsoft? Or was it something else? The answer of course isn't easy and maybe it's not in the frameworks area that we need to look. For example such applications as Paint.NET is truly innovative in my opinion. I wouldn't have half the picture content on this blog as easily without it. Also, some open source blogging engines work quite well as well. So, there is innovation, but if you look to recent times, have we caught up?
To Be Continued...

Singularity - C# OS Released on CodePlex

Matthew Podwysocki — Wed, 12 Mar 2008 00:03:26 GMT

Update: If you want the .iso I used for the VPC, check it out here on my SkyDrive.

During my research and posts about Design by Contract and Spec# and my interactions with folks from Microsoft Research, I came across Singularity OS, an operating system written in an offshoot language based upon C#. In that time, I realized that the Singularity team extended Spec# and the Design by Contract and static verification pieces of it into a new language called Sing#.

Fast forward to last Tuesday. Almost five years after the start of development, it has finally been released onto CodePlex as an open source non-commercial academic license and can be found here. After reading about it and talking with some Microsoft Research folks about it, I had to give it a shot. That's one of the things I love about working at Microsoft is the fact that I can interact with people like these on a periodic basis.

History of Singularity

During my long commute to and from work, I have the pleasure of listening to many podcasts. Although I like the ones in the .NET space with Hanselminutes and DotNetRocks, I also like to venture into the Ruby and outside community where I'm pretty comfortable as well. So, one of my absolute favorites is Software Engineering Radio for the serious talk and geeking about languages and architecture. Lo and behold, the latest episode, Episode 88, covers Singularity with Galen Hunt where he talks with Markus, the host about the history and features of the OS. I suggest you listen to that before we go any further. Also, a good overview can be found here in PDF format.

If you think about most operating systems we run today, the essence of what they are is dated back in the 1970s and C and Assembly based. Back in 2003, Galen and team started this effort to write an operating system in managed code. Over 90% of the system is written in a language called Sing# which is an extension of Spec# which I will get into shortly. But, Singularity consists of three major parts, Software Isolated Processes (SIPs), contract-based channels, and manifest-based programs.

SIPs are interesting parts of Singularity. They provide a sandbox as it were for program execution free from meddling from outside processes. This includes its own memory space, threads and so on. In fact, memory and threads cannot be shared from one SIP to the other, so the vectors for malicious code are cut way down.

Contract-Based Channels are another interesting aspect of Singularity. It's a built-in feature of the Sing# language which I will get to in the next section. In short, what it provides is a quick and verifiable way of communicating between processes with messages. To support this, the Spec# language had to be extended to support this.

Lastly, manifest based programs are interesting because it defines the code that runs within the SIP and its behaviors. In Singularity, there really is no such thing as Just In Time Compiling (JIT) as all code needs to be loaded into memory and statically verified before it can be executed, which is something a JIT cannot do. But on the other side of this, it makes dynamic languages and late binding impossible as well. So, to work around this, they devised a plan called Compile Time Reflection, so you know your dependencies beforehand and uses Dependency Injection in a way to inject the appropriate dependencies. Really slick stuff!

Sing#

Rustan Leino and others in Microsoft Research had already begun an effort called Spec# to provide Design by Contract features to the C# language and a static verifier to prove that code is in fact working as the contracts were written. Just a quick aside, we're going to be lucky enough to have Rustan at ALT.NET Open Spaces, Seattle to talk about it and Design by Contract (Shameless Plug). Anyhow, back to the topic at hand. Spec# didn't have enough for the static verification that needs to happen. So, instead, Sing# brings us Contract Based Channels for creating message declarations and a set of named protocol sets. Any communication that crosses processes must use contract based channels. These messages that it passes have declarations that state the number and types of arguments for each message and an optional message direction. Each state specifies the possible message sequences leading to other states in the state machine.

I just want to dig through some code to see exactly what that looks like:

    class DirectoryServiceWorker
    {
        private TRef<DirectoryServiceContract.Exp:Start> epRef;
        private DirNode! dirNode;

        private DirectoryServiceWorker(DirNode! dirNode,
                                      [Claims] DirectoryServiceContract.Exp:Start! i_ep)
            requires i_ep.InState(DirectoryServiceContract.Start.Value);
        {
            epRef = new TRef<DirectoryServiceContract.Exp:Start>(i_ep);
            this.dirNode = dirNode;
            base();
        }

If you notice from above, you can see some Spec# goodness in there including NonNull types using the ! keyword and also requires preconditions. It's pretty well written and a lot of fun to dig through. If you want to learn more about compilers and operating systems, now is the time to sift through the source code and get your geek hat on.

Building the Image

If you want to actually run Singularity, the team has provided as part of the zip file, a way to build the operating system. You'll simply need the following:

Windows Debugging Tools
.NET Framework 1.1
Virtual PC 2007
MSBuild

There is a really well documented PDF file that comes as part of the download to walk you through the build procedure step by step. Basically, you kick off an MSBuild process which builds the image and then you can mount an iso image to see the results.

I was able to get the results in about 10 minutes or so for the build process. Then again, if you're running Vista, you need to be sure to launch the configure.cmd as an elevated process in order to kick things off properly. That was the first hurdle. But once I got that going, the rest was easy. And I got a pretty cool result as well when I ran the VPC image. Look at the goodness:

I have played with it just yet all that much. I'm figuring what I can do with it next. But, that's part of my copious spare time which doesn't seem to exist much anymore.

Conclusion

I've done well with my learning plan this year to keeping to what is on my plan and not deviating from it. Luckily languages such as Spec# and Sing# still fall into that category. It's pretty fascinating stuff and great to get my hands on an operating system using managed code. It's pretty impressive from the things I've read and the code I've read. I'm only hoping that research projects such as this make a significant impact on future versions of Windows, let alone future versions of most operating systems. Until next time...

Design by Contract Revisited with C# and .NET

Matthew Podwysocki — Fri, 01 Feb 2008 00:32:20 GMT

In a previous post, I talked about various attempts at frameworks that are trying to do Design By Contract (DBC) in .NET. Many simply just come across as simple validation frameworks without the heart of DBC which is the contract. Where is the contract? Well, dig through my code and find out! It's something that I've been harping on time and time again is that without transparency to the caller and callee of the contract, it's just another validation framework. You'll hear either myself or Greg Young on that, I'm sure.

The only approach that has worked so far has been Spec# in the .NET world. Unfortunately, still a research product, isn't available for us to use commercially. So, until that time in which it is thoroughly weaved into the .NET framework as a whole outside of the internals of System.Core.dll, we have to look at alternatives.

Eiffel

Before we look at another framework, I just want to walk you through a sample of the original DBC language, Eiffel. This gives you an idea what I'm talking about.

my_list.do_all (agent (s: STRING)
     require
         not_void: s /= Void
     do
         s.append_character (',')
     ensure
         appended: s.count = old s.count + 1
     end)

As you can see, it's clearly stated as part of the language what the requirements are, and what its return will be. That's the really slick part about it that we don't have unless we go to Eiffel.NET, but it's not using the latest and greatest .NET APIs, so it's pretty much a nonstarter. So, let's look at yet another framework.

LinFu DesignByContract

Philip Laureano, who has done a lot with LinFu including Aspect Oriented Programming (AOP) among other things has taken a stab at DBC for all .NET languages and not just C# which Spec# has done. He posted the LinFu.DesignByContract2 article on CodeProject that is well worth checking out.

Earlier, he posted one about the LinFu framework on CodeProject as well which includes the following:

A simple IoC container
Design by Contract framework
Dynamic Proxy
Reflection (Mixins, Duck Typing and Multiple Dispatch)
Delegates with lambdas for universal event handling

But, let's get back to the DBC part, you'll remember the basic tenets of the philosophy:

What do we expect?
What do we return?
What do we maintain?

We also throw in a few Eiffel constructs in terms of inheritance which are also quite important. And they are:

The precondition may only be weakened by inheritance
The postcondition can only be strengthened by inheritance

Well, enough about the basics, let's look at the framework itself. Let's first look at a simple sample I whipped up:

public class StringCollection
{
   private int count;
   string[] strings = new string[5];

   [EnsureCountIncremented]
   public virtual void Add([NotNull] string value)
   {
        // NotNull doing
        // Debug.Assert(!string.IsNullOrEmpty(value));

        // Add value and redefine

        // EnsureCountIncremened
        // Debug.Assert(count == count + 1);
   }
}

So, what you see here is that I put a postcondition making sure that the count is incremented by one as I'm adding a string to my array. Also, I have the precondition that my string value is not null. But, how does that work?

In order to do that we need to implement a few interfaces. Let's look at the one for preconditions.

public interface IMethodContract
{
    IList<IPrecondition> Preconditions { get; }
    IList<IPostcondition> Postconditions { get; }
}

public interface IPrecondition : IMethodContractCheck
{
    bool Check(object target, InvocationInfo info);
    void ShowError(TextWriter output, object target, InvocationInfo info);
}

Ok, so now, I need to implement that somehow for my custom attribute. That would look similar to this:

public sealed class NotNullAttribute : Attribute, IPrecondition
{
     public bool Check(object target, InvocationInfo info)
     {
          string value = target as string;
          if(!string.IsNullOrEmpty(value))
               return true;
     }

     public void ShowError(TextWriter output, object target, InvocationInfo info)
     {
          output.WriteLine("string value cannot be null or blank");
     }

     public bool AppliesTo(object target, InvocationInfo info)
     {
          return target is string;
     }

     public void Catch(Exception ex)
     {

     }
}

So, it's pretty interesting and clever how this is being done. But still without the static checking of Boogie and so on, it still falls well short of real DBC.

For those interested in postconditions and invariants, those are also supported through the interfaces as shown below:

public interface IPostcondition : IMethodContractCheck
{
    void BeforeMethodCall(object target, InvocationInfo info);
    bool Check(object target, InvocationInfo info, object returnValue);
    void ShowError(TextWriter output, object target, InvocationInfo info,
        object returnValue);
}

public interface IInvariant : IContractCheck
{
    bool Check(object target, InvocationInfo info, InvariantState callState);
    void ShowError(TextWriter output, object target, InvocationInfo info,
        InvariantState callState);
}

So, as I said, quite interesting and clever the way of handling the DBC concepts through interfaces. The libraries were also written to support the Eiffel constructs of inheritance. So, very well written I must admit.

Conclusion

I just began to scratch the surface with what you can do with this framework and it's very well written. But, still at the end of the day, it's not statically checked through a Boogie and a theorem prover to ensure the contracts hold. That's the crucial part missing in this equation. I'm sure more will come to mind on the subject. Until next time...

Design by Contract and C# (without Spec#)

Matthew Podwysocki — Tue, 22 Jan 2008 05:58:34 GMT

After finishing the mini-lecture circuit and my often viewed dive into Spec#, I decided to see if anyone else was working in the Design By Contract (DBC) arena with C#. Greg Young and I often talk about this subject and various scenarios where it would make sense, and where it wouldn't. Hopefully we'll hear more from the Spec# team shortly about the futures.

It turns out there are two other attempts at what Spec# does, and that's what I'm going to dive into today.

Back to Basics

So, first, let's get back to the basics with regard to Design By Contract and what we're trying to achieve. Remember back in my Spec# posts, I gave a basic introduction to DBC. If you want a more complete introduction, check out the Eiffel documentation here which covers the topic in details. As you may remember, Eiffel was designed with DBC in mind as its key feature.

Back in 2002, Kevin McFarlane submitted an article on CodeProject called Design by Contract Framework to introduce DBC principles into a simple library for basic needs. This was originally for the 1.0 framework, but could easily be ported if need be. Currently this project doesn't use generics or any of the other .NET 2.0+ features. Anyhow, let's get into a sample of how it works.

The class that is the heart of the operation is the Check class. The basic listing, minus overloads, is as follows:

// Contract verifier
public static class Check
{
     // Preconditions
     public static bool Require(bool assertion) { ... }

     // Postconditions
     public static bool Ensure(bool assertion) { ... }

     // Invariants
     public static bool Invariant(bool assertion) { ... }

     // Assertions
     public static bool Assert(bool assertion) { ... }
}

// Base contract exception
public class DesignByContractException : Exception { ... }

// Preconditions exception
public class PreconditionException : DesignByContractException { ...}

// Postconditions exception
public class PostconditionException : DesignByContractException { ...}

// Invariants exception
public class InvariantException : DesignByContractException { ...}

// Assertions exception
public class AssertionException : DesignByContractException { ...}

And a simple example using this framework in a CustomerCollection would be as such:

public void Add(Customer value)
{
     // Check precondition
     Check.Require(value != null);

     // Check for postcondition
     int oldCount = customerList.Count;
     customerList.Add(value);
     int newCount = customerList.Count;
     Check.Ensure(newCount == oldCount + 1);
}

As you can see, it's a pretty simple implementation, but unfortunately, it requires you the developer to think extra hard about putting these things in as well as checking your invariants along the way. Spec# or C# with the Spec# postcompiler give you that which this does not. So, at the end of the day, it's not much more powerful than the Validator Block inside the Enterprise Library.

What this is also missing is one of the vital pieces of DBC which is in regard to inheritance of contracts. In an earlier post on Spec#, I covered the basics of the following:

Preconditions cannot be strengthened or modified
Postconditions cannot be weakened, but can be augmented with logical ANDs

Yet Another Approach

What the older solution lacked was using custom attributes to decorate a given class with its contract. Andrew Matthews has taken another interesting approach in a series of blog posts. Each one of these is interesting in its own right.

In this series, Andrew is trying to find ways to make C# work with Spec# like attributes. It's an interesting concept with all the munging he's had to do. So, here's where he started:

First time around:

[Requires(“arg1 > 10″)]
[Requires(“arg2 < 100″)]
[Ensures(“$after(Prop1) == $before(Prop1) + 1″)]

As you can see, it's not very type safe, nor really verifiable with the parsing. So, something else had to be done. C# as a language cannot accept lambdas and other constructs within custom attributes, so this approach won't work.

Instead, this is the newer approach with the use of extension methods

public static void Require<T>(this T obj, Expression<Func<T, bool>> pred)
{
    var x = pred.Compile();
    if (!x(obj))
        throw new ContractException(pred.ToString());
}

This allows for such verifications as follows:

public void Add(string value)
{
     this.Require(x => !string.IsNullOrEmpty(value));
     ...
}

Pretty interesting approach, but at the end of the day, is it more verifiable. Do you have a theorem prover on this? No, and that's the unfortunate part. DBC isn't as useful until the contract itself is part of the method signature. So far Spec# has been the only option to do this.

.NET 3.5 Implementation

As you may have noted from my series, Spec# features have already been woven into the .NET framework, in particular System.Core.dll. Anyhow, the heart of the operation is in the Contract class. You may note when looking through .NET Reflector, the use of the conditional attribute as follows:

[Pure, Conditional("USE_SPECSHARP_ASSEMBLY_REWRITER")]

What this particular attribute means is that it's going to run the Spec# post-processor on the given C# assembly to produce the theorem checks. This is where the true value of Spec# comes from to be able to tell whether or not I am fulfilling my contract during compile time. At runtime, it's less than helpful in that regard.

Conclusion

Some people are doing some interesting things with Design By Contract and trying to shoehorn it into the .NET framework. Unfortunately, unless tightly integrated with the BCL, I don't think it's going to happen. Spec# is a great tool for this and I certainly hope/expect that it will become further part of the .NET framework in future releases.

On a side note, if you are interested in DBC and Spec#, you may be interested in the ALT.NET Open Spaces, Seattle which I am currently involved in organizing. Both Greg Young and I will be there and don't be surprised to find more people interested in it as well for a session. We hope to open registration soon and I expect it will fill up fast!

DC ALT.NET Meeting 1/15/2008 Reminder

Matthew Podwysocki — Mon, 14 Jan 2008 04:26:40 GMT

For those who missed it, our DC ALT.NET group will meet on January 15th at 7PM. I'm hoping for a great turnout of passionate developers in the DC Metro area. Hope you can make it. Also, don't forget to join the list as we discuss more issues and our next meeting stuff.

The meeting this month will bring ALT.NET to CMAP. Are you a developer who always keeps an eye out for a better way? Do you look outside the mainstream to adopt the best practices of any development community, including Open Source, Agile, Java, and Ruby communities? Are you always looking for more elegant, more simple, more maintainable solutions? If so, then you might be an ALT.NET practitioner!

This group follows the Open Space Technology model. In Open Space, a facilitator explains the process and then participants are invited to co-create the agenda and host their own discussion groups.

This model follows the four basic principles:

Whoever comes are the right people
Whatever happens is the only thing that could have
Whenever it starts is the right time
When it's over, it's over

Topics for discussion can include the following as well as others:

Model View Controller Pattern (ASP.NET MVC/MonoRail)
Inversion of Control (IoC) containers and Dependency Injection (Spring.NET/Castle Windsor/StructureMap)
O/RM Tools (NHibernate/ActiveRecord/Entity Framework/LINQ)
Test Driven Development
Domain Driven Design
Behavior Driven Development
Design by Contract and Spec# (my topic I'll be bringing)
Enterprise Design Patterns in .NET

Time and Location:
Tuesday, January 15, 2008 7:00 PM

SM Consulting
1306 Concourse Drive
Suite 200
Linthicum, MD 21090

Come, participate, and make your voice heard! Come meet passionate developers like yourself in the active discussion! We are looking to host the next one in Virginia and have a roving location per month so that more people in the metro DC area can participate.

C# - vNext

Matthew Podwysocki — Sat, 12 Jan 2008 02:20:01 GMT

I've been reading lately about what people are interested in with the next version of C#. It's amazing to think how far the language has come from the early days. Many of the newer features of the language with 3.0 by far have made it a better language.

So, what did we get with the latest C# 3.0?

Object Initializers
Automatic Properties
Anonymous Types
Extension Methods
Lambda Expressions
LINQ
Collection Initializers

By far, I agree with most of Jeremy Miller's sentiments regarding C# vNext, including:

Mixins
Ruby-like Symbols
Hash language features
Automatic Delegation

I'll throw Spec# features and Duck Typing onto the pile. As you may note from my earlier posts, parts already exist in .NET 3.5 libraries, so it's not hard to imagine that might open up a bit. Plus, since I've given several presentations on the matter, I'm pretty into it. But, also some of F#'s features are great as well that I'd like to see more merging includes mutables. A good introduction to F# can be found here. But, then again, why not just stick to F#?

What might in store for C# 4.0 anyhow? Well, if you follow Eric Lippert, one of Microsoft's best bloggers, like I do, there are some things that are very interesting that he's been working on including Covariance and Contravariance with his ten post series:

Each of these are worth a read:

Also, could immutability be another thing coming? If you're a follower of Domain Driven Design, you like Value Objects and Immutability. Spec# also introduces this concept to C# as well through the use of attributes. And since parts of Spec# covers this, it's also very likely. Anyhow, Eric Lippert also covers this in a "hypothetical way":

But, with all new features, there are diminishing returns as noted by Ian Cooper. I'd have to agree with this point. At some point, what are these new features going to give you when other languages can do these things more naturally? If, say C# doesn't have a certain feature, but IronRuby does, why not use IronRuby? Also, keeping on piling on features will ultimately make the language more complex and sifting through the various answers to find the right one becomes a bit harder.

I disagree with others like Jeremy that call for an end and stick a fork in C#. It's not done yet and I think it holds much more promise before we call it a day.

.NET 3.5, Design by contract and Spec# Wrapup

Matthew Podwysocki — Tue, 08 Jan 2008 04:07:47 GMT

Update: Adding Visual Studio Integration discussion
Update: Stay tuned for additional posts in this series as things permit

Well, this is my last post in the series to wrap things up. This will be updated as things come to mind, as they always do in a series like this. There may have been unclear things that I will attempt to explain a little further, plus clarify and explore new things.

Let's get caught up from the series:
Part 1: Spec# introduction
Part 2: Method Contracts (Preconditions/Postconditions)
Part 3: Invariants
Part 4: Object Ownership/Assertions & Assumptions
Part 5: Frame Conditions/Inheritance/Boogie
Part 6: Implementing a non-null string collection in Spec#

Now let's go over some topics I may have missed earlier:

Constructor behavior
Pure methods
Immutables
Visual Studio Integration with C#

Constructor Behavior

When using non-null types in your Spec# code, you need to be careful about when your object is initialized. In .NET, the order of the calling of constructors is non-deterministic, meaning that the base constructor may be called before the super class's. In Spec#, if you have a non-null field declared, you must initialize it, so therefore you need to control the order in which the constructors are called. Fortunately, Spec# gives you that capability, and allows you to call the base constructor at any time during the constructor of your superclass through the use of the base keyword. Below is an example of that:

public class NonNullStringCollection
{
     private List<string!>! strings;

     public NonNullStringCollection()
     {
          strings = new List<string!>();
          Debug.WriteLine("Before base constructor");
          base(); // Must call this after initializing all non-null fields
          Debug.WriteLine("After base constructor");
     }
}

So, unlike C# and others, we have the ability to control the flow of our constructors. By this, it is pretty powerful as we need to do this. How does it look like in IL where I'll highlight where it verifies the call of the constructor
.method public hidebysig specialname rtspecialname instance void .ctor() cil managed
{
    .maxstack 8
    L_0000: ldarg.0
    L_0001: newobj instance void [mscorlib]System.Collections.Generic.List`1<string modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType)>::.ctor()
    L_0006: stfld class [mscorlib]System.Collections.Generic.List`1<string modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType)> modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType) SpecSharpSample.NonNullStringCollection::data
    L_000b: ldstr "Before base constructor"
    L_0010: call void [System]System.Diagnostics.Debug::WriteLine(string)
    L_0015: ldarg.0
    L_0016: call instance void [mscorlib]System.Object::.ctor()
    L_001b: ldstr "After base constructor"
    L_0020: call void [System]System.Diagnostics.Debug::WriteLine(string)
    L_0025: ret
}

If you look at the C# version through Reflector, you'll notice no difference whatsoever:

public NonNullStringCollection()
{
    this.data = new List<string modopt(NonNullType)>();
    Debug.WriteLine("Before base constructor");
    Debug.WriteLine("After base constructor");
}

Pure Methods

If you want to call a method in a specification, then the method you call must be pure, which means it has no effect on the state of objects allocated at the time the method is called. In order for a method to be considered pure, it must be marked with the PureAttribute, ConfinedAttribute or StateIndependentAttribute in the Microsoft.Contracts namespace. In order to do this, it's rather easy:

[Pure]
public void DoesNotModifyState() { ... }

All three of the above attributes mark the method as pure. It also declares what the method may read, so let's look at that below:

PureAttribute - this method may read anything
ConfinedAttribute - this method can only read the state of the receiver object and its representation objects
StateIndependentAttribtue - this method does not read any mutable part of the heap.

Over time, it's the plan of the team to migrate to just a simple PureAttribute and I'm not sure as of this writing if that is done. The default read permission is set to the ConfinedAttribute, so until the name change is complete, it's best to use that one.

Immutables

Some objects in the .NET framework will remain "peer consistent" forever once their constructor has finished. Recall back to the ownership and invariants discussion for that definition. If a type is marked with the ImmutableAttribute, then the fields and such are not allowed to be modified once it has left the constructor. To think about these, think of such objects as DateTime, Guid and other value objects, by the fact that you cannot modify them once they have been created.

[Immutable]
public classCoordinate
{
     public Coordinate()
     {
          this.longitude = LongitudeMinValue;
          this.latitude = LatitudeMaxValue;
          base();
     }

     public Coordinate(double latitude, double longitude)
     {
          this.longitude = longitude;
          this.latitude = latitude;
          base();
     }

     public Coordinate Add(double latitude, double longitude)
     {
          return new Coordinate(this.latitude + latitude, longitude + this.longitude);
     }
}

As you can note, I'm not changing this after I've finished constructing them. I don't mean Value Objects in the DDD sense of the word, although it could possibly apply here as well when it comes to Entities versus Value Objects. Anyhow, by default, these value objects are peer consistent. The String class is immutable, so your program can always invoke methods on strings because since it is always immutable, it will always be peer consistent.

In order to make your own objects immutable, you need to make sure it has no peers. The static verifier, Boogie, checks to make sure no expose operations (expose keyword) is applied in the class as well. Fields using the PeerAttribute are not allowed in immutable classes. Also, there is no need to own an immutable object, since the reason for owning an object is to keep it peer consistent, and by default, immutable objects are peer consistent.

There are three restrictions you must note when using an immutable object.

A Constructor of an immutable class must end by calling its base constructor.
Can only be declared if the base class is also immutable
A class or interface that derives from an immutable type must also be declared immutable.

Let's wrap this up with pure methods. An immutable class can only invoke pure methods on its fields due to the state of the object not being allowed to change.

Visual Studio Integration with C#

When you install Spec# for Visual Studio 2005, by default it will install the project templates for Spec#, which includes the standard stuff plus a few extras including:

Class Library
Windows Application
Console Application
Sample Projects
- ArrayList
- Bag
- Subclass with Invariant
- Use Mscorlib contracts

Now when you choose to use the Spec# templates, you give up a lot of the C# features that you have come to love. This also hurts especially when using a tool such as Resharper to make me a productive developer. You also give up auto-indentation as well, so if you want it, you do it yourself!

But, on the positive side of things, you get the feedback from the static verifier to give you the red and green squigglies that display not only syntax errors, but also theorem prover errors coming from Boogie. How cool is that? Also, as I mentioned in a previous post, you get Intellisense to display the contracts of other classes as you highlight them.

But, say for instance, you still want the rich environment of C# to do Spec#. Well, you can do that, too. In my first post in the series, I alluded to the fact that you could do Spec# in C# but to comment it out so that C# doesn't detect it, but Spec# will.

To make a non-liar out of me, create a new C# project, and right click on the project and go to properties and you should see this following screen:

This screen allows you to do compile time checks on your code as you build it. First, the project will build in C#, and then hand it off to Spec# for your post-compilation. It's probably a similar process to what the BCL team did when they incorporated the Microsoft.Contracts namespace into System.Core.dll.

To use these Spec# contracts in your C# code, it's as simple as commenting out your contracts with this:
/*^ Do Spec# thing here; ^*/

Below is a quick example of this:

public class NonNullStringCollection
{
    private List<string/*^!^*/>/*^!^*/ strings;

    public NonNullStringCollection()
    {
        strings = new List<string/*^!^*/>();
        /*^base();^*/
    }

    public void Add(string/*^!^*/ value)
        /*^requires value != null;^*/
        /*^ensures Count == old(Count) + 1;^*/
    {
        strings.Add(value);
    }

    public int Count
    {
        get
            /*^ensures result >= 0; ^*/
        {
            return strings.Count;
        }
    }
}

Let's look at the constructor to make sure our base constructor gets called last:

    .method public hidebysig specialname rtspecialname instance void .ctor() cil managed
    {
        .maxstack 8
        L_0000: ldarg.0
        L_0001: newobj instance void [mscorlib]System.Collections.Generic.List`1<string modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType)>::.ctor()
        L_0006: stfld class [mscorlib]System.Collections.Generic.List`1<string modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType)> modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType) NonNullTypes.NonNullStringCollection::strings
        L_000b: ldarg.0
        L_000c: call instance void [mscorlib]System.Object::.ctor()
        L_0011: ret
    }

If you try compiling without marking base(); in the constructor, you might notice it right at the top of the method call. Also, let's take a look at the resulting C# created for the Add Method:

[Requires("::!=(optional([System.Compiler.Runtime]Microsoft.Contracts.NonNullType,string),string){$1,null}", Filename=@"E:\Work\NonNullTypes\NonNullStringCollection.cs", StartLine=0x12, StartColumn=0x19, EndLine=0x12, EndColumn=0x26, SourceText="value != null"), Ensures(@"::==(i32,i32){this@NonNullTypes.NonNullStringCollection::get_Count{},::+(i32,i32){\old(this@NonNullTypes.NonNullStringCollection::get_Count{}),1}}", Filename=@"E:\Work\NonNullTypes\NonNullStringCollection.cs", StartLine=0x13, StartColumn=0x18, EndLine=0x13, EndColumn=0x2f, SourceText="Count == old(Count) + 1")]
public void Add(string modopt(NonNullType) value)
{
    int old(Count);
    try
    {
        if (value == null)
        {
            throw new ArgumentNullException("value");
        }
        if (value == null)
        {
            throw new RequiresException("Precondition 'value != null' violated from method 'NonNullTypes.NonNullStringCollection.Add(optional(Microsoft.Contracts.NonNullType) System.String)'");
        }
        old(Count) = this.Count;
    }
    catch (ContractMarkerException)
    {
        throw;
    }
    this.strings.Add(value);
    try
    {
        if (this.Count != (old(Count) + 1))
        {
            throw new EnsuresException("Postcondition 'Count == old(Count) + 1' violated from method 'NonNullTypes.NonNullStringCollection.Add(optional(Microsoft.Contracts.NonNullType) System.String)'");
        }
    }
    catch (ContractMarkerException)
    {
        throw;
    }
}
Conclusion

So, as you can note, there are plenty more opportunities to dig deeper and I hope you all get the bug to do so. If I missed anything, let me know! I would love to use such a thing in production, but it's not designed for such right now. Also, the licensing states that it's for academic uses only at this point. But, who knows what the future holds for this. Design, mentor and inspire!

.NET 3.5, Design by contract and Spec# Part 6

Matthew Podwysocki — Mon, 07 Jan 2008 02:58:30 GMT

Updates:
Part7: Spec# Wrapup

On an ongoing coverage of Spec#, I've decided to post some of the actual results of a sample Spec# class and what the results look like in C# and even IL.

Let's get caught up to the previous posts before we continue:
Part 1: Spec# introduction
Part 2: Method Contracts (Preconditions/Postconditions)
Part 3: Invariants
Part 4: Object Ownership/Assertions & Assumptions
Part 5: Frame Conditions/Inheritance/Boogie

By the way, I may have failed to mention that there is a great DotNetRocks broadcast with Rustan Leino, the lead researcher on Spec# which is well worth a listen and can be found here.

Anyhow, let's start with a simple example of a NonNullStringCollection. I'll be a little lazy and use an ArrayList behind the scenes, but let's look for how you handle the method contracts. We'll use preconditions and postconditions, non null types and so on.

using System;
using System.Collections;

namespace SpecSharpSample
{
    public class NonNullStringCollection
    {
        private ArrayList! data;

        public NonNullStringCollection()
        {
            this.data = new ArrayList();
            base(); // Call this after assigning our non-null fields
        }

        public int Add(string! value)
             requires value != null otherwise ArgumentNullException;
             requires !this.IsReadOnly otherwise InvalidOperationException;
             ensures Count > 0;
        {
            return this.data.Add(value);
        }

        public void AddRange(string[]! value)
            requires value != null && forall{int i in (0:value.Length); value[i] != null} otherwise ArgumentNullException;
            requires !this.IsReadOnly otherwise InvalidOperationException;
        {
            this.data.AddRange(value);
        }

        public void Clear()
            requires !this.IsReadOnly otherwise InvalidOperationException;
            ensures Count == 0;
        {
            this.data.Clear();
        }

        public bool Contains(string! value)
            requires value != null otherwise ArgumentNullException;
        {
            return this.data.Contains(value);
        }

        public void CopyTo(string[]! array, int index)
            requires array != null otherwise ArgumentNullException;
            requires index >=0 && index < Count otherwise ArgumentOutOfRangeException;
        {
            this.data.CopyTo(array, index);
        }

        public void Insert(int index, string! value)
            requires value != null otherwise ArgumentNullException;
            requires !this.IsReadOnly otherwise InvalidOperationException;
            requires index >=0 && index < Count otherwise ArgumentOutOfRangeException;
        {
            this.data.Insert(index, value);
        }

        public void Remove(string! value)
            requires value != null otherwise ArgumentNullException;
            requires !this.IsReadOnly otherwise InvalidOperationException;
        {
            this.data.Remove(value);
        }

        public void RemoveAt(int index)
            requires index >=0 && index < Count otherwise ArgumentOutOfRangeException;
            ensures Count == old(Count) - 1;
        {
            this.data.RemoveAt(index);
        }

        public int Count
        {
            get
                ensures result >= 0;
            {
                return this.data.Count;
            }
        }

        public bool IsReadOnly
        {
            get
                ensures result == false;
            {
                return false;
            }
        }

        public bool IsSynchronized
        {
            get
                ensures result == false;
            {
                return false;
            }
        }

        public string this[int index]
        {
            get
            requires index >=0 && index < Count otherwise ArgumentOutOfRangeException;
            ensures result != null;
            {
                return (string) this.data[index];
            }
            set
            requires index >=0 && index < Count otherwise ArgumentOutOfRangeException;
            requires value != null;
            {
                this.data[index] = value;
            }
        }
    }
}

As you can see, I mixed in a bunch of preconditions, postconditions and assertions. While you are developing in Spec#, you might notice that the Intellisense for Visual Studio offers something pretty interesting.

As you may notice, this displays the method contracts for you thus making your life a little easier to fulfill the contracts. Pretty cool, huh?

Now, let's take a look at some of the code that gets translated by Reflector into IL. Let's look at the Add method. Note the preconditions and postconditions as stated in the above class. Also, note the usage of the NonNullType as well. I'll highlight the areas of interest below:

.method public hidebysig instance int32 Add(string modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType) 'value') cil managed
{
    .custom instance void [System.Compiler.Runtime]Microsoft.Contracts.RequiresAttribute::.ctor(string) = { string('::!=(optional([System.Compiler.Runtime]Microsoft.Contracts.NonNullType,string),string){$1,null}') Filename=string('E:\\Work\\SpecSharpSample\\Class1.ssc') StartLine=int32(0x10) StartColumn=int32(0x17) EndLine=int32(0x10) EndColumn=int32(0x24) SourceText=string('value != null') }
    .custom instance void [System.Compiler.Runtime]Microsoft.Contracts.RequiresAttribute::.ctor(string) = { string('::!(bool){this@SpecSharpSample.NonNullStringCollection::get_IsReadOnly{}}') Filename=string('E:\\Work\\SpecSharpSample\\Class1.ssc') StartLine=int32(0x11) StartColumn=int32(0x17) EndLine=int32(0x11) EndColumn=int32(0x27) SourceText=string('!this.IsReadOnly') }
    .custom instance void [System.Compiler.Runtime]Microsoft.Contracts.EnsuresAttribute::.ctor(string) = { string('::>(i32,i32){this@SpecSharpSample.NonNullStringCollection::get_Count{},0}') Filename=string('E:\\Work\\SpecSharpSample\\Class1.ssc') StartLine=int32(0x12) StartColumn=int32(0x16) EndLine=int32(0x12) EndColumn=int32(0x1f) SourceText=string('Count > 0') }
    .maxstack 6
    .locals init (
        [0] class [System.Compiler.Runtime]Microsoft.Contracts.ContractMarkerException exception,
        [1] int32 return value,
        [2] class [System.Compiler.Runtime]Microsoft.Contracts.ContractMarkerException SS$Contract Marker,
        [3] int32 SS$Display Return Local)
    L_0000: ldarg.1
    L_0001: ldnull
    L_0002: beq L_000c
    L_0007: br L_0017
    L_000c: ldstr "value"
    L_0011: newobj instance void [mscorlib]System.ArgumentNullException::.ctor(string)
    L_0016: throw
    L_0017: ldarg.1
    L_0018: ldnull
    L_0019: beq L_0023
    L_001e: br L_0029
    L_0023: newobj instance void [mscorlib]System.ArgumentNullException::.ctor()
    L_0028: throw
    L_0029: ldarg.0
    L_002a: call instance bool SpecSharpSample.NonNullStringCollection::get_IsReadOnly()
    L_002f: brtrue L_0039
    L_0034: br L_003f
    L_0039: newobj instance void [mscorlib]System.InvalidOperationException::.ctor()
    L_003e: throw
    L_003f: leave L_0047
    L_0044: stloc.0
    L_0045: rethrow
    L_0047: nop
    L_0048: ldarg.0
    L_0049: ldfld class [mscorlib]System.Collections.ArrayList modopt([System.Compiler.Runtime]Microsoft.Contracts.NonNullType) SpecSharpSample.NonNullStringCollection::data
    L_004e: ldarg.1
    L_004f: callvirt instance int32 [mscorlib]System.Collections.ArrayList::Add(object)
    L_0054: stloc.1
    L_0055: br L_005a
    L_005a: ldarg.0
    L_005b: call instance int32 SpecSharpSample.NonNullStringCollection::get_Count()
    L_0060: ldc.i4.0
    L_0061: ble L_006b
    L_0066: br L_0076
    L_006b: ldstr "Postcondition \'Count > 0\' violated from method \'SpecSharpSample.NonNullStringCollection.Add(optional(Microsoft.Contracts.NonNullType) System.String)\'"
    L_0070: newobj instance void [System.Compiler.Runtime]Microsoft.Contracts.EnsuresException::.ctor(string)
    L_0075: throw
    L_0076: nop
    L_0077: leave L_007f
    L_007c: stloc.2
    L_007d: rethrow
    L_007f: nop
    L_0080: ldloc.1
    L_0081: stloc.3
    L_0082: ldloc.1
    L_0083: ret
    .try L_0000 to L_0044 catch [System.Compiler.Runtime]Microsoft.Contracts.ContractMarkerException handler L_0044 to L_0047
    .try L_005a to L_007c catch [System.Compiler.Runtime]Microsoft.Contracts.ContractMarkerException handler L_007c to L_007f
}

Now that we looked at the IL, note the exceptions throws and which time. Now that we have done that, study the code above and check for the assertions, the preconditions and postconditions. Let's look at a C# version. Note that it looks very similar to that in the System.Core.dll within the Microsoft.Contracts namespace from some of the classes that we talked about in earlier posts. Once again, I'll highlight the interesting points below.

[Requires("::!=(optional([System.Compiler.Runtime]Microsoft.Contracts.NonNullType,string),string){$1,null}", Filename=@"E:\Work\SpecSharpSample\Class1.ssc", StartLine=0x10, StartColumn=0x17, EndLine=0x10, EndColumn=0x24, SourceText="value != null"), Requires("::!(bool){this@SpecSharpSample.NonNullStringCollection::get_IsReadOnly{}}", Filename=@"E:\Work\SpecSharpSample\Class1.ssc", StartLine=0x11, StartColumn=0x17, EndLine=0x11, EndColumn=0x27, SourceText="!this.IsReadOnly"), Ensures("::>(i32,i32){this@SpecSharpSample.NonNullStringCollection::get_Count{},0}", Filename=@"E:\Work\SpecSharpSample\Class1.ssc", StartLine=0x12, StartColumn=0x16, EndLine=0x12, EndColumn=0x1f, SourceText="Count > 0")]
public int Add(string modopt(NonNullType) value)
{
    try
    {
        if (value == null)
        {
            throw new ArgumentNullException("value");
        }
        if (value == null)
        {
            throw new ArgumentNullException();
        }
        if (this.IsReadOnly)
        {
            throw new InvalidOperationException();
        }
    }
    catch (ContractMarkerException)
    {
        throw;
    }
    int return value = this.data.Add(value);
    try
    {
        if (this.Count <= 0)
        {
            throw new EnsuresException("Postcondition 'Count > 0' violated from method 'SpecSharpSample.NonNullStringCollection.Add(optional(Microsoft.Contracts.NonNullType) System.String)'");
        }
    }
    catch (ContractMarkerException)
    {
        throw;
    }
    int SS$Display Return Local = return value;
    return return value;
}

Conclusion

As you can see, I'm pretty fascinated with Design by Contract and how it applies to .NET. I hope that the next version of C# has this as well as other features I'll cover later. I hope this series was informational and worthwhile as it was for me. Develop, mentor and inspire!

Please let me know if there is anything I missed or would like to see in this series.