Sunday, December 4, 2011

Building a PC, Part VII: Rebooting

I've had more or less the same PC, with various updates, since 2007. I've written about most of it here:

While the advice in those original articles is still quite sound, my old 2007 era case was feeling mighty creaky. I needed a new chassis. I also wanted a motherboard that supported native 6 Gbps SATA for the latest generation of SSDs that truly benefit from them. The buzz around the Sandy Bridge based Core i7-2600k was nearly deafening, and I've fallen completely in love with my last HTPC build based on the same technology. (Oh, and even if you already read that article, read it again because I added new PicoPSU and case information that takes it from awesome to sublime – on the order of 17 watts idle!)

So I decided it was time to build myself a nice Sandy Bridge system. What I ended up with is easily the best case and motherboard combination I've ever laid hands on. Read on!

I cut out a lot of the initial research work by relying on my old, dear friends at Tech Report and their current workstation recommendations:

As for the case, I was impressed by the Tech Report review of the Corsair 600T, which even comes in a heart-stopping pseudo stormtrooper white. WANT.


When it comes to power supplies, I'm crazy about efficiency, and fortunately there are now lots of so-called "80 Plus Gold" PSUs out there now, offering a staggering 90% efficiency under most loads. Power supply efficiency is important, because the rest of that heat is dumped back into your case. The less efficient your PSU, the more heat buildup you'll have under load. I chose the Seasonic X-760 – which, when bench tested, indeed delivered the promised 90% efficiency – but any high quality 80 Plus Gold model will generally do.

The CPU (and possibly, depending on your tastes, the video card) is the biggest heat generator inside your PC. The better and more efficient the CPU cooler, the quieter your whole system can be. This also affects how much you can overclock. I chose the Thermalright Venomous-X Silent Edition on the basis of it being the current top dog for efficiency, and because it had a simple mounting system. Large coolers can be a real bear to install. And did I mention it comes with an especially quiet fan out of the box, too?

Once I had all the parts in hand, it was a simple matter of building it up, as documented in my previous post series. I adore this Corsair case; it is an absolute joy to work in. Everything in it is cleverly designed, from the rear cable routing area with rubber grommets all over the place for easily passing cables back and forth, to the tool-less 2.5" and 3.5" bays, to the super easily removable side panels. It's like they read a giant list of all my prior complaints with every PC case I've ever used and fixed every. single. last. one of them.

The end result is what you see here:


There are some significant tweaks visible in the above picture that I do recommend:

  1. Use tin snips to remove the rear exhaust grill. We don't need it back there, and the exhaust airflow is critical. Fan grills affect low-speed fan airflow more than you'd think:
    Wire grills also have an effect: ~20%. This was checked with an anemometer on several different fans of 80, 92 and 120mm size, at full and lower speeds. The airflow reduction went as high as 24% but it was never below 19%. At 12V, the reduction in airflow with most fans will be relatively harmless, though there is an increase in turbulence noise (audible to me). But at the low airflow rates SPCR members run fans, I think the airflow reduction is significant.
  2. Install a 140mm rear exhaust fan. The Noctua NF-P14 is expensive at $25 but is cleverly designed to give you 140mm of super-quiet fan in the space a 120mm fan would normally take. It just barely fits in the rear exhaust fan slot with a little nudging. But it does fit; it's the beige fan in the above picture. It also comes with its own speed reducers and accessories.

  3. Use fan speed reducers on all the fans. The case has two 200mm fans, and the 140mm fan we're adding. I couldn't get the Asus motherboard's "QFan" fan control system to work, as it seems to require 4-pin fans, and all the ones I had (including the ones that came with the case) are 3-pin. While I do prefer dynamic, temperature based control when I can get it, the next best thing is to use hardware to slow down the fans. I like the Zalman-ZM-RC56 resistor connector as the simplest solution, but it's getting hard to find for some reason. The Zalman Fan Mate 2 will also work, and allows you to individually adjust the speed of each fan. The case also has a built in fan controller – that's the knob you see on the front top – but I found it too limited in range for my purposes.

  4. Add acoustic foam to taste. Between inexpensive eggcrate foam and thin, adhesive backed open-cell foam, you can easily reduce that last 10-20% of fan noise to a very pleasant white noise. It works well in the areas pictured, and also on the interior of the side panel "facing" the fans. See item 6 in my Building a Quiet PC post for details.

And then, of course, the overclockening. What kind of geek would I be if I didn't attempt to turn this baby up to 11? This is another area where Sandy Bridge is a revelation: so long as you buy one of the blessed "K" series processors, overclocking is as simple as setting the multiplier to the desired value. It is ridiculously simple. And my results, for once, were immediately as good as the ones everyone else was crowing about: 4.4 GHz totally stable!


(beware: there is one nasty little issue with the Asus motherboard's auto-overclock feature. The PLL Overvoltage setting, which auto-overclock "helpfully" enables, completely bollixes up resuming from sleep. Just turn it off, and all is well. I don't even want to tell you how long it took me to figure that one out.)

The total package with a nice SSD delivers a near-perfect Windows Experience score:


I won't lie to you. This is not a compact build. It's big! Those roomy side areas come at a cost, and that makes it a very wide case. But that's to be expected for a desktop powerhouse machine. And since my last case lasted me from 2007-2011, I'll happily accept a little bulk for something that's easy to work on and upgrade over time.


It's a fantastic new reboot of my system, and I didn't expect to be this excited about the final result. This is not merely an incremental improvement over what I had, it's much quieter, easier to work on, and when overclocked to 4.4 GHz, noticeably faster too. (I do slightly mourn the loss of 8 GB of RAM, but I'll survive.)

In this build, I already had hard drives, DVD drive, a sound card, and so forth … but for completeness' sake I'll list everything here if you want to mirror this setup. Realize that some of this comes down to personal taste, so I'm just listing what I recommend. Feel free to change anything out, and bear in mind that Sandy Bridge has decent default onboard video as well.

Remember, if you can put together a LEGO kit, you can build this totally sweet PC for yourself, too. Good luck and happy building!



Eduasync part 17: unit testing

In the last post I showed a method to implement "majority voting" for tasks, allowing a result to become available as soon as possible. At the end, I mentioned that I was reasonably confident that it worked because of the unit tests... but I didn't show the tests themselves. I felt they deserved their own post, as there's a bigger point here: it's possible to unit test async code. At least sometimes.

Testing code involving asynchrony is generally a pain. Introducing the exact order of events that you want is awkward, as is managing the threading within tests. With a few benefits with async methods:

  • We know that the async method itself will only execute in a single thread at a time
  • We can control the thread in which the async method will execute, if it doesn't configure its awaits explicitly
  • Assuming the async method returns Task or Task<T>, we can check whether or not it's finished
  • Between Task<T> and TaskCompletionSource<T>, we have a way of injecting tasks that we understand

Now in our sample method we have the benefit of passing in the tasks that will be awaited - but assuming you're using some reasonably testable API to fetch any awaitables within your async method, you should be okay. (Admittedly in the current .NET framework that excludes rather a lot of classes... but the synchronous versions of those calls are also generally hard to test too.)

The plan

For our majority tests, we want to be able to see what happens in various scenarios, with tasks completing at different times and in different ways. Looking at the test cases I've implemented I have the following tests:

  • NullSequenceOfTasks
  • EmptySequenceOfTasks
  • NullReferencesWithinSequence
  • SimpleSuccess
  • InputOrderIsIrrelevant
  • MajorityWithSomeDisagreement
  • MajorityWithFailureTask
  • EarlyFailure
  • NoMajority

I'm not going to claim this is a comprehensive set of possible tests - it's a proof of concept more than anything else. Let's take one test as an example: MajorityWithFailureTask. The aim of this is to pass three tasks (of type Task<string>) into the method. One will give a result of "x", the second will fail with an exception, and the third will also give a result of "x". The events will occur in that order, and only when all three results are in should the returned task complete, at which point it will also have a success result of "x".

So, the tricky bit (compared with normal testing) is introducing the timing. We want to make it appear as if tasks are completing in a particular order, at predetermined times, so we can check the state of the result between events.

Introducing the TimeMachine class

Okay, so it's a silly name. But the basic idea is to have something to control the logical flow of time through our test. We're going to ask the TimeMachine to provide us with tasks which will act in a particular way at a given time, and then when we've started our async method we can then ask it to move time forward, letting the tasks complete as they go. It's probably best to look at the code for MajorityWithFailureTask first, and then see what the implementation of TimeMachine looks like. Here's the test:

public void MajorityWithFailureTask()
    var timeMachine = new TimeMachine();
    // Second task gives a different result
    var task1 = timeMachine.AddSuccessTask(1, "x");
    var task2 = timeMachine.AddFaultingTask<string>(2, new Exception("Bang!"));
    var task3 = timeMachine.AddSuccessTask(3, "x");

    var resultTask = MoreTaskEx.WhenMajority(task1, task2, task3);

    // Only one result so far - no consensus

    // Second result is a failure

    // Third result gives majority verdict
    Assert.AreEqual(TaskStatus.RanToCompletion, resultTask.Status);
    Assert.AreEqual("x", resultTask.Result);

As you can see, there are two types of method:

  • AddSuccessTask / AddFaultingTask / AddCancelTask (not used here) - these all take the time at which they're going to complete as their first parameter, and the method name describes the state they'll reach on completion. The methods return the task created by the time machine, ready to pass into the production code we're testing.
  • AdvanceTo / AdvanceBy (not used here) - make the time machine "advance time", completing pre-programmed tasks as it goes. When those tasks complete, any continuations attached to them also execute, which is how the whole thing hangs together.

Now forcing tasks to complete is actually pretty simple, if you build them out of TaskCompletionSource<T> to start with. So all we need to do is keep our tasks in "time" order (which I achieve with SortedList), and then when we're asked to advance time we move through the list and take the appropriate action for all the tasks which weren't completed before, but are now. I represent the "appropriate action" as a simple Action, which is built with a lambda expression from each of the Add methods. It's really simple:

public class TimeMachine
    private int currentTime = 0;
    private readonly SortedList<int, Action> actions = new SortedList<int, Action>();

    public int CurrentTime { get { return currentTime; } }

    public void AdvanceBy(int time)
        AdvanceTo(currentTime + time);

    public void AdvanceTo(int time)
        // Okay, not terribly efficient, but it's simple.
        foreach (var entry in actions)
            if (entry.Key > currentTime && entry.Key <= time)
        currentTime = time;

    public Task<T> AddSuccessTask<T>(int time, T result)
        TaskCompletionSource<T> tcs = new TaskCompletionSource<T>();
        actions[time] = () => tcs.SetResult(result);
        return tcs.Task;

    public Task<T> AddCancelTask<T>(int time)
        TaskCompletionSource<T> tcs = new TaskCompletionSource<T>();
        actions[time] = () => tcs.SetCanceled();
        return tcs.Task;

    public Task<T> AddFaultingTask<T>(int time, Exception e)
        TaskCompletionSource<T> tcs = new TaskCompletionSource<T>();
        actions[time] = () => tcs.SetException(e);
        return tcs.Task;

Okay, that's a fair amount of code for a blog posts (and yes, it could do with some doc comments etc!) but considering that it makes life testable, it's pretty simple.

So, is that it?

It works on my machine... with my test runner... in simple cases...

When I first ran the tests using TimeMachine, they worked almost immediately. This didn't surprise me nearly as much as it should have done. You see, when the tests execute, they use async/await in the normal way - which means the continuations are scheduled on "the current task scheduler". I have no idea what the current task scheduler is in unit tests. Or rather, it feels like something which is implementation specific. It could easily have worked when running the tests from ReSharper, but not from NCrunch, or not from the command line NUnit test runner.

As it happens, I believe all of these run tests on thread pool threads with no task scheduler allocated, which means that the continuation is attached to the task to complete "in-line" - so when the TimeMachine sets the result on a TaskCompletionSource, the continuations execute before that call returns. That means everything happens on one thread, with no ambiguity or flakiness - yay!

However, there are two problems:

  • The words "I believe" aren't exactly confidence-inspiring when it comes to testing that your software works correctly.
  • Our majority voting code only ever sees one completed task at a time - we're not testing the situation where several tasks complete so quickly together that the continuation doesn't get chance to run before they've all finished.

Both of these are solvable with a custom TaskScheduler or SynchronizationContext. Without diving into the docs, I'm not sure yet which I'll need, but the aim will be:

  • Make TimeMachine implement IDisposable
  • In the constructor, set the current SynchronizationContext (or TaskScheduler) to a custom one having remembered what the previous one was
  • On disposal, reset the context
  • Make the custom scheduler keep a queue of jobs, such that when we're asked to advance to time T, we complete all the appropriate tasks but don't execute any continuations, then we execute all the pending continuations.

I don't yet know how hard it will be, but hopefully the Parallel Extensions Samples will help me.


I'm not going to claim this is "the" way of unit testing asynchronous methods. It's clearly a proof-of-concept implementation of what can only be called a "test framework" in the loosest possible sense. However, I hope it gives an example of a path we might take. I'm looking forward to seeing what others come up with, along with rather more polished implementations.

Next time, I'm going to shamelessly steal an idea that a reader mailed me (with permission, of course). It's insanely cool, simple and yet slightly brain-bending, and I suspect will handy in many situations. Love it.



Friday, December 2, 2011

Gimme Bar+TwitterFeed+PHP = One-click Syndication - » PHP

I recently set up a new Twitter account that shares links to some of the smaller stories I come across in my news reading for called @phpquickfix. I recently had started playing with Gimme Bar more and wondered how easy it?d be to set it up as a backend repository for some links. Thanks to some hints from other blog posts, it was super easy to set up a ?one click syndication? system that combines Gimme Bar, Twitterfeed and a little bit of PHP.

Here?s how it?s set up:

  • I have an account for the PHP Quick Fix over on Gimme Bar here. I use their Chrome extension (and sometimes the bookmarklet) to grab the pages that I want to add.
  • There?s a little PHP script I put together that does a few things ? first, if the cached json from the Gimme Bar feed is out of date, it grabs it and wgets the latest from their API. Then it parses this json and outputs it as a simple RSS feed. You can see the result here.
  • Finally, we add Twitterfeed into the mix ? it pulls from the RSS feed and posts it to Twitter automatically.

The end result is a system where I can click ?Gimme the Page? to my public collection and let the services do the rest. There?s no automation in the link selection ? it?s all chosen with my own ?human aggregation system?. I think it?s a pretty simple solution to the problem ? plus it has the added benefit of making a good collection of hand-picked PHP resources for anyone to pull from.

UPDATE: You can also directly access the PHP Quick Fix posts over on it?s feed:



Nobody's Going to Help You, and That's Awesome

I'm not into self-help. I don't buy self-help books, I don't read productivity blogs, and I certainly don't subscribe to self-proclaimed self-help guru newsletters. Reading someone else's advice on the rather generic concept of helping yourself always struck me as a particularly misguided idea.

Apparently I'm not the only person to reach this conclusion, either.

I spent two years reading all the self-help books I could find. As of a year ago, I had read 340 self-help books. Because I?m insane.

My conclusion from all that reading?

95% of self-help books are complete bullshit.

To be clear, I am all for self-improvement. Reading books, blogs, and newsletters by people who have accomplished great things is a fine way to research your own path in life. But these people, however famous and important they may be, are not going to help you.

Unfortunately that's not the answer he wanted. To him, my answer [that nobody was going to help him become successful] was really discouraging. To me, if I was receiving that answer from someone else, it would be really encouraging.

I like being reminded that nobody's going to help me - that it's all up to me. It puts my focus back on the things I can control - not waiting for outside circumstances.

Take it from The Ultimate Productivity Blog:


Reading self-help advice from other people, however well-intentioned, is no substitute for getting your own damn work done. The sooner you come to terms with this, the better off you'll be.

Get out there and do stuff because you fundamentally enjoy it and because it makes you better. As a writer, as an analyst, as a techie, whatever. Learn to love practicing the fundamentals and do it better each time. Over time, quality does lead to success, but you have to be patient. Really patient. Turns out, "overnight" success takes years. Maybe even decades. This is not a sprint, it's a marathon. Plan accordingly.

For example, I don't care if anyone reads what I write here. I'm writing to satisfy myself first and foremost. If others read it and benefit from it, fantastic -- that's a welcome side effect. If I worry about who is reading, why they're reading, or if anyone is even reading at all, I'd be too paralyzed to write! That'd be the least productive outcome of all.

That's not to say that some introspection about the nature of your work isn't useful. It is. Even the weary self-help student I quoted above concluded that 5% of self-help advice surprisingly wasn't bullshit. The one book he recommended without hesitation? 59 Seconds: Think a Little, Change a Lot.


Despite my deep reservations about the genre, I ordered this book based on his recommendation and a number of credible references to it I noticed on the Skeptic Stack Exchange.

Why does this self-help book work when so many others fail? In a word, science! The author goes out of his way to find actual published scientific research documenting specific ways we can make small changes in our behavior to produce better outcomes for ourselves and those around us. It's powerful stuff, and the book is full of great, research backed insights like this one:

A group of participants were asked to select a negative experience. One group of participants were then asked to have a long chat with a supportive experimenter about the event, while a second group were invited to chat about a far more mundane topic - a typical day.

Participants who had spent time talking about their traumatic event thought the chat had been helpful. However, the various questionnaires told a very different story. In reality the chat had no significant impact at all. They might just as well have been chatting about a typical day.

In several studies, participants who have experienced a traumatic event have been encouraged to spend just a few minutes each day writing in a diary-type account of their deepest thoughts and feelings about it. For example, in one study participants who had just been made redundant were asked to reflect upon their deepest thoughts and feelings about their job loss, including how it had affected both their personal and professional lives. Although these types of exercises were both speedy and simple, the results revealed a remarkable boost in their psychological and physical well-being, including a reduction in health problems and an increase in self-esteem and happiness.

The results left psychologists with something of a mystery. Why would talking about a traumatic experience have almost no effect but writing about it yield such significant benefits? From a psychological perspective, talking and writing are very different. Talking can often be somewhat unstructured, disorganized, even chaotic. In contrast, writing encourages the creation of a story line and structure that help people make sense of what has happened and work towards a solution. In short, talking can add to a sense of confusion, but writing provides a more systematic, solution-based approach.

Therefore, the real world change you would make based on this advice – the proverbial 59 seconds on the book jacket – is to avoid talking through traumatic experiences in favor of writing about them. Not because some self-help guru said so, but because the published research data tells us that talking doesn't work and writing does. Not exactly intuitive, since talking through our problems with a friend always feels like the right thing to do, but I have certainly documented many times over the value of writing through a problem.

59 Seconds is so good, in fact, it has rekindled my hopes that our new Stack Exchange Productivity Q&A can work. I'd love for our productivity site to be founded on a scientific basis, and not the blind cult of personality I've come to expect from the self-help industry.

Remember, nobody's going to help you … except science, and if you're willing to put in the required elbow grease each and every day – yourself.



JavaScript Constructors Were a Mistake and Should Be Removed



Optional argument corner cases, part three

(This is part three of a series on the corner cases of optional arguments in C# 4; part two is here. Part four is here.)

A lot of people seem to think that this:

void M(string x, bool y = false) { ... whatever ... }

is actually a syntactic sugar for the way you used to have to write this in C#, which is:

void M(string x) { M(x, false); }
void M(string x, bool y) { ... whatever ... }

But it is not. The syntactic sugar here is not on the declaration side, but rather on the call side. There is only one method; when you make a call that omits optional arguments, the compiler simply inserts the arguments at the call site. That is:


is rewritten as

M("hello", false);

It would actually be pretty weird if we did it on the declaration side, because what would you do about this?

void N(bool a1 = false, bool a2 = false) { ... whatever ... }

Clearly we can't generate

void N() { N(false, false); }
void N(bool a1) { N(a1, false); }
void N(bool a2) { N(false, a2); }
void N(bool a1, bool a2) { ... whatever ... }

because now we have two methods with the same signature. But why would we need to generate the "a2" method in the first place? Because we added named arguments as well as optional arguments. Someone could call:

N(a2: true);

Clearly we have to rewrite the caller side, not the called side.

An argument with a default value does not change the signature at all, so anything that relies upon signature matching still needs to have an exact match. That is, even though you can say:


and you can say

Action<string> action = (string s)=>{M(s);};

You cannot say

Action<string> action = M;

Because M does not have a signature match with that delegate type; the delegate is expecting a method that takes a string, but you're giving it a method that takes a string and a bool. Where is the code generated that fills in the bool? There is no call site here, and the default value has to be filled in at the call site.

Similarly, you can't do something like this:

class B
  public virtual void M(string x, bool y = false) {}
class D : B
  public override void M(string x) {}

Or this:

class D : B
  public override void M(string x, bool y = false, int z = 123) {}

The signatures have to match to do an override, and default values for missing arguments are not part of the signature.

Next time: more consequences of call-site rewriting.

(This is part three of a series on the corner cases of optional arguments in C# 4; part two is here. Part four is here.)



Breaking changes and named arguments

Before I get into the subject of today's post, thanks so much to all of you who have given us great feedback on the Roslyn CTP. Please keep it coming. I'm definitely going to do some articles on Roslyn in the future; the past few weeks I have been too busy actually implementing it to write much about it.

We introduced "named and optional arguments" to C# 4.0; that's the feature whereby you can omit some optional arguments from a method call, and specify some of them by name. This makes the code more self-documenting; it also makes it much easier to deal with methods in legacy object models that have lots and lots of parameters but only a few are relevant. The most common commentary I've seen about the "named" side of that feature is people noting that this introduces a new kind of breaking change. The commentary usually goes something like:

Suppose you are making a library for consumption by others. Of course if you change details of the public surface area of the library, you can break consumers of the library. For example, if you add a new method to a class then you might make an existing program that compiled just fine now turn into an error-producing program because a call to the old method is now ambiguous with a call to the new method. In the past, changing only the name of a formal parameter was not a "breaking change", because consumers always passed arguments positionally. Recompilation would not produce different results. In a world with named arguments though, it is now the case that changing the name of a formal parameter can cause working code to break.

Though that commentary is certainly well-intentioned and informative, it is not quite accurate. The implication is that this breaking change is something new, when in fact it has always been the case that a library provider could break consumers by changing only the name of a formal parameter. Visual Basic has always supported calling methods with named parameters. In the past, changing the name of a formal parameter was a breaking change for any consumers using Visual Basic, and that's potentially a lot of people. Now it becomes a potential breaking change for even more users. Adding a new feature to C# doesn't change the fact that the risk was always there!

Library providers should already have been cautious about changing the names of formal parameters, and they should continue to be cautious now.




Thursday, December 1, 2011

Async articles

I am pleased to announce that MSDN Magazine is doing a special issue this month on the new "async-await" feature that we are working on for the next versions of C# and Visual Basic. If this subject interests you, see my introductory article for beginners, Mads Torgersen's article on how it works behind the scenes and Stephen Toub's expert-level article on async performance. And of course, for a much longer introduction to the topic, see my long series from earlier this year. If you want to try it out yourself, download the CTP build from the async CTP main page.

Please do keep the great feedback coming! If you have comments, questions or constructive feedback on any aspect of the new feature, please post it to the async forum. Thanks!




Why do we need www?



Optional argument corner cases, part three

(This is part three of a series on the corner cases of optional arguments in C# 4; part two is here. Part four is here.)

A lot of people seem to think that this:

void M(string x, bool y = false) { ... whatever ... }

is actually a syntactic sugar for the way you used to have to write this in C#, which is:

void M(string x) { M(x, false); }
void M(string x, bool y) { ... whatever ... }

But it is not. The syntactic sugar here is not on the declaration side, but rather on the call side. There is only one method; when you make a call that omits optional arguments, the compiler simply inserts the arguments at the call site. That is:


is rewritten as

M("hello", false);

It would actually be pretty weird if we did it on the declaration side, because what would you do about this?

void N(bool a1 = false, bool a2 = false) { ... whatever ... }

Clearly we can't generate

void N() { N(false, false); }
void N(bool a1) { N(a1, false); }
void N(bool a2) { N(false, a2); }
void N(bool a1, bool a2) { ... whatever ... }

because now we have two methods with the same signature. But why would we need to generate the "a2" method in the first place? Because we added named arguments as well as optional arguments. Someone could call:

N(a2: true);

Clearly we have to rewrite the caller side, not the called side.

An argument with a default value does not change the signature at all, so anything that relies upon signature matching still needs to have an exact match. That is, even though you can say:


and you can say

Action<string> action = (string s)=>{M(s);};

You cannot say

Action<string> action = M;

Because M does not have a signature match with that delegate type; the delegate is expecting a method that takes a string, but you're giving it a method that takes a string and a bool. Where is the code generated that fills in the bool? There is no call site here, and the default value has to be filled in at the call site.

Similarly, you can't do something like this:

class B
  public virtual void M(string x, bool y = false) {}
class D : B
  public override void M(string x) {}

Or this:

class D : B
  public override void M(string x, bool y = false, int z = 123) {}

The signatures have to match to do an override, and default values for missing arguments are not part of the signature.

Next time: more consequences of call-site rewriting.

(This is part three of a series on the corner cases of optional arguments in C# 4; part two is here. Part four is here.)



Arabic Support in Java



Regular Expressions in C# ? The Basics

One of the most common coding tasks is to take an input, munch it around and turn it into something different altogether. Are you looking for FedEx numbers in a text file? Do you want to replace “love” with “hate” in your source files? Is a string a valid e-mail address? Problems like these can [...]

This is a post from Martijn's C# Coding Blog.



Wednesday, November 30, 2011

Switched to LuaLaTeX


Have you ever tried to write a little bit complex command in LaTeX? I did at some occasions, and finally it somehow worked, but it has always been ugly. However, there is LuaTeX/LuaLaTeX, it provides real scripting within your documents:

\directlua{   for i=0, 15 do     tex.print("Math: $x_{" .. i .. "}$")   end }

That is just awesome, in plain LaTeX this would be ugly, but it gets even more ugly if you have to deal with floating points, external files etc. Well, for now I do not need any complex macro, so I cannot talk about actual experiences with Lua stuff, but I encountered some problems when translating my LaTeX document to LuaLaTeX two weeks ago.

unicode-math does not work properly

When enabling the unicode-math package for using Unicode characters in formulas (⊂∀∃∂ etc.) I have to select a font using the \setmathfont command, I tried “Latin Modern Math”, “STIXGeneral”, “XITS Math”, “Neo Euler” and “Asana Math”, otherwise Unicode symbols will not get displayed. However, with all of these fonts formulas do not look as good as with standard LaTeX lmodern-package, which is usable from LuaLaTeX, too, \setmathfont will override it. Some of them are too bold, some have ugly ℝ, ℚ, ℂ (\mathbb) and \mathcal symbols etc. Thus I decided to port the uniinput package provided by the Neo project (they create the keyboard layout I am using) to LuaLaTeX. I thought it would be nice to check the Lua capabilities that for, however, I faced the next problem.

Lua is not Unicode aware

That is really annoying, LuaLaTeX’s claim is to support a) sophisticated scripting and b) native Unicode support. However, they choosed Lua as scripting language, which does not support Unicode natively. I could not find the functions I needed to write a succinct macro for declaring a Unicode character in math mode (for examble ℝ should be replaced with \mathbb{R}), simply something to split a 8-bit-UTF-8-string into its Unicode characters and to do conversions between character codes and strings. I did not want to write it myself. Thus I choosed a quick and dirty way: using some regexp-magic and a Ruby script to convert uniinput.sty into uniinput-lualatex.sty. It works now, you can use it if you want to…

Making it working with KileIP

KileIP currently has the latex-command hard coded to display previews of formulas. I was too lazy to fix that and I wanted to be able to fall back to LaTeX if there were unexpected problems, thus I made my document working with both LaTeX and LuaLaTeX:

\usepackage{iftex} \ifPDFTeX   \usepackage[utf8]{inputenc}   \usepackage[T1]{fontenc}   \usepackage{uniinput}   \usepackage{lmodern}   \usepackage{amsmath}   \usepackage{amssymb} \else   \ifLuaTeX     \usepackage{luatextra}     \usepackage{amsmath}     \usepackage{amssymb}     \usepackage{lmodern}     \usepackage{uniinput-lualatex}     \usepackage{fontspec}   \fi \fi

Well, next time I need a complex macro I will certainly use Lua and it will hopefully work with my setup. :)



Eduasync part 13: first look at coroutines with async

(This part covers project 18 in the source code.)

As I mentioned in earlier parts, the "awaiting" part of async methods is in no way limited to tasks. So long as we have a suitable GetAwaiter() method which returns a value of a type which in turn has suitable methods on it, the compiler doesn't really care what's going on. It's time to exploit that to implement some form of coroutines in C#.

Introduction to coroutines

The fundamental idea of coroutines is to have multiple methods executing cooperatively, each of them maintaining their position within the coroutine when they yield to another. You can almost think of them as executing in multiple threads, with only one thread actually running at a time, and signalling between the different threads to control flow. However, we don't really need multiple threads once we've got continuations - we can have a single thread with a complex flow of continuations, and still only a very short "real" stack. (The control flow is stored in normal collections instead of being implicit on the thread's stack.)

Coroutines were already feasible in C# through the use of iterator blocks, but the async feature of C# allows a slightly more natural way of expressing them, in my view. (The linked Wikipedia page gives a sketch of how coroutines can be built on top of generators, which in the general concept that iterator blocks implement in C#.)

I have implemented various flavours of coroutines in Eduasync. It's possible that some (all?) of them shouldn't strictly be called coroutines, but they're close enough to the real thing in feeling. This is far from an exhaustive set of approaches. Once you've got the basic idea of what I'm doing, you may well want to experiment with your own implementations.

I'm not going to claim that the use of coroutines in any of my examples really makes any sense in terms of making real tasks easier. This is purely for the sake of interest and twisting the async feature for fun.

Round-robin independent coroutines

Our first implementation of coroutines is relatively simple. A coordinator effectively "schedules" the coroutines it's set up with in a round-robin fashion: when one of the coroutines yields control to the coordinator, the coordinator remembers where the coroutine had got to, and then starts the next one. When each coroutine has executed its first piece of code and yielded control, the coordinator will go back to the first coroutine to continue execution, and so on until all coroutines have completed.

The coroutines don't know about each other, and no data is being passed between them.

Hopefully it's reasonably obvious that the coordinator contains all the smarts here - the coroutines themselves can be relatively dumb. Let's look at what the client code looks like (along with the results) before we get to the coordinator code.

Client code

The sample code contains three coroutines, all of which take a Coordinator parameter and have a void return type. These are passed to a new coordinator using a collection initializer and method group conversions; the coordinator is then started. Here's the entry point code for this:

private static void Main(string[] args)
    var coordinator = new Coordinator { 

When each coroutine is initially started, the coordinator passes a reference to itself as the argument to the coroutine. That's how we solve the chicken-and-egg problem of the coroutine and coordinator having to know about each other. The way a coroutine yields control is simply by awaiting the coordinator. The result type of this await expression is void - it's just a way of "pausing" the coroutine.

We're not doing anything interesting in the actual coroutines - just tracing the execution flow. Of course we could do anything we wanted, within reason. We could even await a genuinely asynchronous task such as fetching a web page asynchronously. In that case the whole coroutine collection would be "paused" until the fetch returned.

Here's the code for the first coroutine - the second and third ones are similar, but use different indentation for clarity. The third coroutine is also shorter, just for fun - it only awaits the coordinator once.

private static async void FirstCoroutine(Coordinator coordinator)
    Console.WriteLine("Starting FirstCoroutine");
    Console.WriteLine("Yielding from FirstCoroutine...");

    await coordinator;

    Console.WriteLine("Returned to FirstCoroutine");
    Console.WriteLine("Yielding from FirstCoroutine again...");

    await coordinator;

    Console.WriteLine("Returned to FirstCoroutine again");
    Console.WriteLine("Finished FirstCoroutine");

And here's the output...

Starting FirstCoroutine
Yielding from FirstCoroutine...
    Starting SecondCoroutine
    Yielding from SecondCoroutine...
        Starting ThirdCoroutine
        Yielding from ThirdCoroutine...
Returned to FirstCoroutine
Yielding from FirstCoroutine again...
    Returned to SecondCoroutine
    Yielding from SecondCoroutine again...
        Returned to ThirdCoroutine
        Finished ThirdCoroutine...
Returned to FirstCoroutine again
Finished FirstCoroutine
    Returned to SecondCoroutine again
    Finished SecondCoroutine

Hopefully that's the output you expected, given the earlier description. Again it may help if you think of the coroutines as running in separate pseudo-threads: the execution within each pseudo-thread is just linear, and the timing is controlled by our explicit "await" expressions. All of this would actually be pretty easy to implement using multiple threads which really did just block on each await expression - but the fun part is keeping it all in one real thread. Let's have a look at the coordinator.

The Coordinator class

Some of the later coroutine examples end up being slightly brainbusting, at least for me. This one is relatively straightforward though, once you've got the basic idea. All we need is a queue of actions to execute. After initialization, we want our queue to contain the coroutine starting points.

When a coroutine yields control, we just need to add the remainder of it to the end of the queue, and move on to the next item. Obviously the async infrastructure will provide "the remainder of the coroutine" as a continuation via the OnContinue method.

When a coroutine just returns, we continue with the next item in the queue as before - it's just that we won't add a continuation to the end of the queue. Eventually (well, hopefully) we'll end up with an empty queue, at which point we can stop.

Initialization and a choice of data structures

We'll represent our queue using Queue<T> where the T is a delegate type. We have two choices here though, because we have two kinds of delegate - one which takes the Coordinator as a parameter (for the initial coroutine setup) and one which has no parameters (for the continuations). Fortunately we can convert between the two in either direction very simply, bearing in mind that all of this is within the context of a coordinator. For example:

// If we're given a coroutine and want a plain Action
Action<Coordinator> coroutine = ...; 
Action action = () => coroutine(this);

// If we're given a plain Action and want an Action<Continuation>:
Action continuation = ...; 
Action<Coordinator> coroutine = ignored => continuation();

I've arbitrarily chosen to use the first option, so there's a Queue<Action> internally.

Now we need to get the collection initializer working. The C# compiler requires an appropriate Add method (which is easy) and also checks that the type implements IEnumerable. We don't really need to be able to iterate over the queue of actions, so I've use explicit interface implementation to reduce the likelihood of GetEnumerator() being called inappropriately, and made the method throw an exception for good measure. That gives us the skeleton of the class required for setting up:

public sealed class Coordinator : IEnumerable
    private readonly Queue<Action> actions = new Queue<Action>();

    // Used by collection initializer to specify the coroutines to run
    public void Add(Action<Coordinator> coroutine)
        actions.Enqueue(() => coroutine(this));

    // Required for collection initializers, but we don't really want
    // to expose anything.
    IEnumerator IEnumerable.GetEnumerator()
        throw new NotSupportedException("IEnumerable only supported to enable collection initializers");

(Note that I haven't used XML documentation anywhere here - it's great for real code, but adds clutter in blog posts.)

For production code I'd probably prevent Add from being called after the coordinator had been started, but there's no need to do it in our well-behaved sample code. We're only going to add extra actions to the queue via continuations, which will be added due to await expressions.

The main execution loop and async infrastructure

So far we've got code to register coroutines in the queue - so now we need to execute them. Bearing in mind that the actions themselves will be responsible for adding continuations, the main loop of the coordinator is embarrassingly simple:

// Execute actions in the queue until it's empty. Actions add *more*
// actions (continuations) to the queue by awaiting this coordinator.
public void Start()
    while (actions.Count > 0)

Of course, the interesting bit is the code which supports the async methods and await expressions. We know we need to provide a GetAwaiter() method, but what should that return? Well, we're just going to use the awaiter to add a continuation to the coordinator's queue. It's got no other state than that - so we might as well return the coordinator itself, and put the other infrastructure methods directly in the coordinator.

Again, this is slightly ugly, as the extra methods don't really make sense on the coordinator - we wouldn't want to call them directly from client code, for example. However, they're fairly irrelevant - we could always create a nested type which just had a reference to its "parent" coordinator if we wanted to. For simplicity, I haven't bothered with this - I've just implemented GetAwaiter() trivially:

// Used by await expressions to get an awaiter
public Coordinator GetAwaiter()
    return this;

So, that leaves just three members still to implement: IsCompleted, OnCompleted and GetResult. We always want the IsCompleted property to return false, as otherwise the coroutine will just continue executing immediately without returning to cede control; the await expression would be pointless. OnCompleted just needs to add the continuation to the end of the queue - we don't need to attach it to a task, or anything like that. Finally, GetResult is a no-op - we have no results, no exceptions, and basically nothing to do. You might want to add a bit of logging here, if you were so inclined, but there's no real need.

So, here are the final three members of Coordinator:

// Force await to yield control
public bool IsCompleted { get { return false; } }

public void OnCompleted(Action continuation)
    // Put the continuation at the end of the queue, ready to
    // execute when the other coroutines have had a go.

public void GetResult()
    // Our await expressions are void, and we never need to throw
    // an exception, so this is a no-op.

And that's it! Fewer than 50 lines of code required, and nothing complicated at all. The interesting behaviour is all due to the way the C# compiler uses the coordinator when awaiting it.

We need AsyncVoidMethodBuilder as before, as we have some async void methods - but that doesn't need to do anything significant. That's basically all the code required to implement these basic round-robin coroutines.


Our first foray into the weird and wonderful world of coroutines was relatively tame. The basic idea of a coordinator keeping track of the state of all the different coroutines in one sense or another will keep coming back to us, but with different ways of controlling the execution flow.

Next time we'll see some coroutines which can pass data to each other.



Conditional Formatting on Google Docs, farewell excel.



Upcoming speaking engagements

It's just occurred to me that I've forgotten to mention a few of the things I'll be up to in the near-ish future. (I've talked about next week's Progressive .NET session before.) This is just a quick rundown - follow the links for more blurb and details.

.NET Developer Network - Bristol, September 21st (evening)

I'll be talking about async in Bristol - possibly at a high level, possibly in detail, depending on the audience experience. This is my first time talking with this particular user group, although I'm sure there'll be some familiar faces. Come along if you're in the area.

�redev 2011 - Malm�, November 9th

It's a whistle-stop trip to Sweden as I'm running out of vacation days; I'm flying out on the Tuesday evening and back on the Wednesday evening, but while I'm there I'll give two talks:

  • Async 101 (yes, more async; I wonder at what point I'll have given as many talks about it as Mads)
  • Effective technical communication (not a particularly technical talk, but definitely specific to technical communication)

Last year I had an absolute blast - looking forward to this year, even though I won't have as much time for socializing.

Stack Overflow Dev Days 2011 - London, November 14th - cancelled!

Update: Dev Days has been cancelled. I'm still hoping to do something around this topic, and there may be small-scale meet-ups in London anyway.

Two years ago I talked about how humanity had let the world of software engineering down. This was one of the best talks I've ever given, and introduced the world to Tony the Pony. Unfortunately that puts the bar relatively high for this year's talk - at least, high by my own pretty low standards.

In a somewhat odd topic for a Christian and a happy employee of a company with a code of conduct which starts "Don't be evil," this year's talk is entitled "Thinking in evil." As regular readers are no doubt aware, I love torturing the C# language and forcing the compiler to work with code which would make any right-thinking software engineer cringe. I was particularly gratified recently when Eric Lippert commented on one of my Stack Overflow answers that this was "the best abuse of C# I've seen in a while." I'm looking forward to talking about why I think it's genuinely a good idea to think about nasty code like this - not to use it, but to get to know your language of choice more intimately. Like last time, I have little idea of exactly what this talk will be like, but I'm really looking forward to it.



Tuesday, November 29, 2011

Weekend Project: Porting Kickoff to QML

Last week I decided to do a small evening and weekend project to improve my QML skills. As I had worked on quite some QML already for the new screen locker and the window switching layouts, I wanted to do something more complex, but still something to work on in the evenings.

Given also Marco’s post we slowly have to transit the Plasma Workspaces to Plasma Components, so it makes sense to look in the Plasma area for a widget which could use a rewrite.

I decided to try to rewrite our application launcher Kickoff in QML. There are various reasons for it. First of all I am somewhat familiar with the source base as I have in the past worked at least a little bit with it. The code is nicely separated in core and ui parts and makes strong use of Qt’s Model/View/Controller Framework, which means it’s very easy to add a QML based interface to it.

But most important I think that Kickoff is an applet which would benefit most from a QML port. As Kickoff uses the Model/View/Controller Framework it is QWidget based and embedded into Plasma’s Graphicsscene through a proxy widget. If you are familiar with the differences you can spot where Kickoff just does not fit with the rest of Plasma. E.g. the white background or the blue highlight which just does not look and feel like Plasma. Given that Kickoff is one of the first visual elements new users will see it is rather important to present the UI in a consistent and elegant way.

While it is still a work in progress and more a draft, you can get a feeling of the differences in this screenshot:
Classic Kickoff vs. QML based Kickoff

Thanks to the possibilities of QML all the data presented in the QML based Kickoff is currently just mock-data and not yet connected to the real C++ based Models. This gives the possibility to concentrate on the UI without caring about the required changes in the underlying Models.

My expectation is that after the QML port Kickoff should also perform much better. Removing those proxy widgets is clearly a plus and QML allows us to lazy load the data and view components much easier. E.g. in the mockup I presented all the data is loaded only when needed. That is if you only use the favorite tab there is no need to load e.g. the data for the applications. So overall a worthwhile project for learning QML.

Overall we still have plenty of Plasmoids which need a QML port, so get your hands dirty.

Before I close this part, I’d like to invite you all to Plasma Bug Days, which will be held this Friday and Saturday (December 2nd and 3rd), more info on Aaron’s blog. Come give us a hand if you want the 4.8 release to really rock!



KDE Telepathy 0.2 Released

We are pleased to announce the second release of KDE Telepathy.

KDE Telepathy is a suite of applications which together form an instant-messaging client allowing you to talk on Jabber, Gmail, Facebookm, MSN and much more. KDE Telepathy stands out from previous instant messaging clients by being able to integrate into the KDE workspace and plasma, as well as being able to be used like a traditional IM application.

This release features:

  • KWallet integration for storing of passwords
  • A plasmoid for instant access to a contact
  • Ability to set your status to the currently playing track from Amarok, Clementine or any other mpris2-compatiable player
  • Auto Away
  • Progress bar and cancel button for file transfers
  • Over 130 bug fixes and tweaks since 0.1!


The whole team met at the Woshibon 2 sprint in Cambridge, UK (14th-18th September). This sprint was sponsored by both the KDE e.V and Collabora and allowed us to not only sort out many of the details in making this release, but planning out more long term goals as well.

The Future

This is still a very early release and far from what we want to call the "finished product", however all the functionality works and many of us now use it as a daily instant messaging client.

In the future we shall have contact aggregation, audio and video calls as well as more plasma integration, and much more!

We always appreciate the help from more developers, designers and testers; so if you are interested in helping please check out our wiki page at or join in IRC at #kde-telepathy on freenode.

Getting the Latest Release

The latest tarballs are available from KDE's FTP server .

Be sure to check our wiki page for installation guidelines and troubleshooting help.

Packages may be available for your distribution.

Other News

I'm stepping down as manager for the 0.3 release. I have another project I want to work on as well as a tonne of uni work over the Christmas period. I'm handing over to the nearly as awesome Martin Klapetek to sort things out.



What is this thing you call a "type"? Part Two

Well that was entirely predictable; as I said last time, if you ask ten developers for a definition of "type", you get ten different answers. The comments to the previous article make for fascinating reading!

Here's my attempt at describing what "type" means to me as a compiler writer. I want to start by considering just the question of what a type is and not confuse that with how it is used.

Fundamentally, a type in C# is a mathematical entity that obeys certain algebraic rules, just as natural numbers, complex numbers, quaternions, matrices, sets, sequences, and so on, are mathematical entities that obey certain algebraic rules.

By way of analogy, I want to digress for a moment and ask the question "what is a natural number?" That is, what fundamentally characterizes the numbers 0, 1, 2, 3, ... that we use to describe the positions of items in a sequence and the sizes of everyday collections of things?

This question has received a lot of attention over the centuries; the definitive answer that we still use today was created by Giuseppe Peano in the 19th century. Peano said that a natural number is defined as follows:

  • Zero is a natural number.
  • Every natural number has a "successor" natural number associated with it.
  • No natural number has zero as its successor.
  • Unequal natural numbers always have unequal successors.
  • If you start from zero, take its successor, and then take the successor of that, and so on, you will eventually encounter every natural number. (*)

Surprisingly, that's all you need. Any mathematical entity that satisfies those postulates is usable as a natural number. (**) Notice that there's nothing in there whatsoever about adding natural numbers together, or subtracting, multiplying, dividing, taking exponents, and so on. All of those things can be bolted on as necessary. For example, we can say that addition is defined as follows:

  • (n + 0) = n
  • (n + (successor of m)) = ((successor of n) + m)

And you're done; you've got a recursive definition of addition. We can similarly define "less than":

  • (n < 0) = false
  • (0 < (successor of m)) = true
  • ((successor of n) < (successor of m)) = (n < m)

We can define every operation on natural numbers in this way; try defining multiplication, just for fun. (Hint: assume that you've already defined addition.)

We can come up with a similar "axiomatic" definition of "type":

  • Object is a type
  • "Declared" types are types (note that int, uint, bool, string, and so on can be considered "declared" types for our purposes; the runtime "declares" them for you.)
  • If T is a type and n is a positive integer then "n-dimensional array of T" is also a type.

And that's pretty much it as far as "safe" C# 1.0 is concerned. (To be as strict as the Peano axioms for natural numbers we'd want to also throw in some similar safeguards; for example, we don't ever want to be in a situation where the type "one-dimensional array of double" has type equality with the type "int", just as we don't ever want to be in a situation where the successor of a natural number is zero.)

Things get a bit more complex when we throw in generic types and pointer types, but I'm sure you can see that we could come up with a precise axiomatic description of generic types and pointer types with a little bit of work. That is, type parameter declarations are types, generic type declarations constructed with the right number of type arguments are types, and so on.

We can then start piling on algebraic operations. Just as we defined "less than" on numbers, we can define the "is a subtype of" relation on types.

  • T <: object is true for any type T that is not object
  • object <: T is false for any type T
  • if S <: T and T <: U then S <: U
  • ... and so on...

Just as I do not care how numbers are "implemented" in order to manipulate them algebraically, I also do not care how types are "implemented" in order to manipulate them with the rules of type algebra. All I care about are the axioms of the system, and the rules that define the algebraic operators that I've made up for my own convenience.

So there you go; we have a definition of "type" that does not say anything whatsoever about "a set of values" or "a name". A type is just an abstract mathematical entity, a bit like a number, that obeys certain defining axioms, and therefore can be manipulated algebraically by making up rules for useful operators -- just like numbers can be manipulated abstractly according to algebraic rules that we make up for them.

Now that we have a sketch of an axiomatic definition of what a type is, what are we going to do with it?

Perhaps the most fundamental purposes of static type checking in a programming language like C# are to associate a type with every relevant storage location, to associate a type with every (†) relevant compile-time expression, and to then ensure that it is impossible for a value associated with an incompatible type to be written to or read from any storage location. A compile-time proof of runtime type safety (): that's the goal.

The key word there is proof; now that we have developed an axiomatic definition of "type" we can start constructing proofs based on these axioms. The C# specification defines:

  • what type is associated with every compile-time expression; of course, expressions whose types cannot be determined might be program errors
  • what type is associated with every storage location
  • what constitutes an acceptable assignment from an expression of given type ( to a storage location of a given type

The task of the compiler writer is then to implement those three parts of the specification: associating a type with every expression, associating a type with every storage location, and then constructing a proof that the assignment is valid given the rules. If the compiler is able to construct a proof then the assignment is allowed. The tricky bit is this: the specification typically just gives the rules of the system, not a detailed algorithm describing how to construct proofs using those rules. If any proof exists then the compiler is required to find it. Conversely, if no proof exists, the compiler is required to deduce that too and produce a suitable compile-time type error.

Unfortunately, as it turns out, that's impossible in general. A system where it is possible for every expression to be classified as either "type safe" or "type unsafe" in a finite number of logical steps is called a "decidable" system. As Gödel famously proved, natural number arithmetic as axiomatized above is undecidable; there are statements in formal arithmetic that can be neither proved nor disproved in a finite number of logical steps. Assignment type checking is also in general undecidable in programming languages with both nominal subtyping () and generic variance. As I mentioned a while back, it turns out that it would be possible to put additional restrictions on type declarations such that nominal subtyping would become decidable, but we have not ever done this in C#. Rather, when faced with a situation that produces an infinitely long proof of type compatibility, the compiler just up and crashes with an "expression was too complex to analyze" error. I'm hoping to fix that in a hypothetical future version of the compiler, but it is not a high priority because these situations are so unrealistic.

Fortunately, situations where type analysis is impossible in general, or extremely time consuming, are rare in realistic C# programs; rare enough that we can do a reasonable job of writing a fast compiler.

Summing up: A type is an abstract mathematical entity defined by some simple axioms. The C# language has rules for associating types with compile-time expressions and storage locations, and rules for ensuring that the expression type is compatible with the storage type. The task of the compiler writer is to use those axioms and algebraic rules to construct a proof or disproof that every expression has a valid type and that every assignment obeys the assignment compatibility rules.

Though the axioms of what makes a type are pretty simple, the rules of associating types to expressions and determining assignment compatibility are exceedingly complex; that's why the word "type" appears 5000 times in the specification. To a large extent, the C# language is defined by its type rules.


(*) I am of course oversimplifying here; more formally, the real axiom formally states that proof by induction works on natural numbers. That is: if a property is true of zero, and the property being true for a number implies the truth for its successor, then the property holds for all numbers.

(**) It is instructive to consider why the third, fourth and fifth postulates are necessary. Without the third postulate, there need only be one number: zero, which is its own successor! Without the fourth postulate we could say that there are only two numbers: the successor of zero is one, the successor of one is one. Without the fifth postulate there could be *two* zeros: "red zero" and "blue zero". The successor of red zero is red one, the successor of blue zero is blue one, and so on. In each case, the system without the axiom satisfies the remaining four axioms, but in each case it seems very contrary to our intuition about what a "natural number" is.

(†) We fudge this in C# of course; null literals, anonymous functions and method groups are technically classified as "expressions without any type". However, in a legal program they must occur in a context where the type of the expression can be inferred from its surrounding context.

() The cast operator gives the lie to this, of course; one meaning of the cast operator is "there is no compile-time proof that this is type safe; I assert that it is safe, so generate code that checks my assertion at runtime." Also, unsafe array covariance makes this goal unreachable.

() Again, this is fudged in a few places. For example, it is not legal to assign an expression of type int to a variable of type short, unless the expression of type int is a compile-time constant known to fit into a short.

() That is, a language where you state the base type of a newly declared type. Like "interface IFoo<T> : IBar<T>" uses nominal subtyping.