I've been working on the CLR team now for slightly over 2 years (FYI: been at MSFT for 5.5). I've learned a great deal in that time about managed code (and native code too), new programming concepts, managing large teams (there are about 150 us now) and some other odds and sundries. I've also had access to early hardware from our friends at AMD and Intel. None of that surprises me now, nor would it have suprised me back in late 2003 (when I started). One concept that I have picked up that I didn't expect was around correctness. Maybe I just missed class the day they taught "correctness", but it was new to me, at least to the degree it is taken seriously on this team.

I took a look @ Wikipedia to see what it thought about correctness. The definition there flirts with what I think of correctness, but it isn't quite it. The closest bit on Wikipedia is this bit:

"In theoretical computer science, correctness of an algorithm is asserted when it is said that the algorithm is correct with respect to a specification. Functional correctness refers to the input-output behaviour of the algorithm (i.e., for each input it produces the correct output)."

If I can construe those two sentences into something slightly more precise, w/rt what I'm thinking ... An algorithm can be considered correct if it produces a result that is predictable (including predictably random) and satisfies the requirements of all of its users (including potential users) under all required scenarios (including potential scenarios).

Another way of thinking of this is not going half-way with an implementation for some method. You need to solve the entire problem from all angles. You need to consider the turkish i and the multiple sort orders of the thai character set (sorry:pdf link). You also have to consider proper locking semantics, avoiding race conditions and dead locks when called/exercised from multiple threads. One can all consider "not guaranteed to be thread safe" as another form of correctness, since the contract is specified up front. One could argue that stance though. You also have to ensure that you clearly specify the expected behaviour of operations, particularly when casting between data types. You also have to determine what should be done when you run out of stack, memory or other resources. What happens when the machine loses power in the middle of an operation. Are you in a consistent state when the machine comes back to life?

So, back to the CLR team ... I find that the concept of correctness comes up a lot in our design sessions and general conversations. The world, in a very real way, is building massive amounts of code across an infinite number of possibilies and scenarios on top of the runtime. It is impossible for each (or any) of us on the CLR team to understand all of those scenarios, let alone take them all into consideration at each step during our development. Instead, we try to learn about as many weird and wacky ones as possible to help us, but correctness is really the thing that guides us each day. It may well turn out that our platform is not feature-rich enough in some niche areas. That's fine, and will always be the case to some degree. Developers still need to write code ;) What isn't acceptable is that our platform operates incorrectly (lack of correctness) in some corner case (or worse yet, general case) scenario. Provided that we think hard and build correctness into every layer of our platform and line of code, we can be certain that the runtime will perform properly and correctly in those infinite number of possibilities and scenarios.

That's one of the reasons why I love working on this team ... not as much because I want to ensure that the runtime is correct in all cases, but because I find it incredibly interesting learning what the correct behaviour is in all those cases. Sometimes it is obvious, but other times it requires a lot of thought to understand why something is correct if done that way. And even more interesting yet is when you're the guy (or gal) who needs to determine what the correct behaviour is, and defend it to your peers. That sort of analysis and hard thinking definitely requires those extra brain cells and cycles that are not neccessarily used every day. And then you sleep really well the next night ;

I posted almost a month ago about all the searches that I've been noticing on my blog about gacutil.exe. I believe I've determined the question that at least some of the folks are wanting to ask. Folks don't know where to get it.

gacutil.exe and other tools such as ildasm.exe are part of the .NET Framework SDK. The .Net Framework admin tool, which used to be part of the redist, is now part of the SDK.

There may be some confusion around gacutil in particular. It has never shipped with the redist, but apparently a servicing package of the redist in the Everett (v1.1) timeframe used it as part of its servicing logic (oops) and didn't properly clean up after itself (double oops). As a result, there may be developers out there that have gotten used to gacutil being in the framework directory. If that's the case, we're sorry for giving the wrong impression. gacutil is intended to be a developer-only tool, used as part of development.

Instead of using gacutil at deployment time (as our not-so-smart servicing package did), you should use MSI or code against the fusion APIs yourself (with the former being the preferred method). For more info, you might take a look through Junfeng's blog.

Happy GACing.

I'm still on this anonymous delegates kick. Maybe I'm on the wrong team and should consider a move to the C# team??

I've seen references to the feature of anonymous delegates as both "anonymous delegates" and "anonymous methods". From a philosophical standpoint, both seem like bad names. It had been bothering me for a while, so I decided to ask my fellow CLR buddy, Joe, the question. Joe is a good person to go to since he's a lot smarter than me. Joe handles concurrency and threading for our team. Joe was doing such a good job at concurrency that they decided that he could handle another job ;)

Anyway, Joe agreed that both names are misleading. Here's what we came up with for what the features would be if you interpreted the names literally:

- anonymous delegates: the ability to define a delegate (the actual declaration) in a more dynamic manner, in which you do not need to statically define the signature/contract of the delegate up-front. Joel and I did a quick co-routines implementation on top of the framework last summer. My first thought was to use delegates. This failed pretty quickly given that you need to delegate signature to be something better than "public delegate Object[] CoRoutineDelegate(Object[])".

- anonymous methods: the ability to define and generate a method in a more dynamic manner, in which you do not need to statically define the signature/contact of the method up-front or care which class it sites on. All you really want here is some sort of handle/reference to that method that you can pass around and call through as needed.

The second definition here feels a lot more like what I've been calling anonymous delegates. In fact, that's more or less how this feature that we've been discussing actually works. I guess "anonymous methods" is really a better term.

Just for kicks, I decided to make a category on anonymous methods so that folks can link back to all the posts, since there are quite a few now. I'm hoping that this post was the last one on the subject, unless I get some interesting feedback from the C# team. With that, it's now time to get back to my factoring features in Whidbey series, which is in dire need of some attention.

I recently posted twice (one and two) on anonymous delegates. I guess they really caught my attention for some reason, even though I've known about them for a long time. The remaining question to close out this debate is whether anonymous delegates are the .Net Framework answer to closures. Another related topic is continuations. I'm certain that these are not that.

First, what is a closure?

Here is how wikipedia defines closures:  "Unlike garden-variety functions which retain no memory of what happened in previous calls, closures are capable of storing information across function calls."

Here is another explanation from guile, which is an open source scheme interpreter that I've never heard of before: "The concept of closure is the idea that a lambda expression "captures" the variable bindings that are in lexical scope at the point where the lambda expression occurs. The procedure created by the lambda expression can refer to and mutate the captured bindings, and the values of those bindings persist between procedure calls. "

My definition is (as of 5 mins ago): a closure is the outcome of capturing both the in-scope variables used by a block of code and the block of code itself to the end of preserving their relationship beyond the normal lifetime of those in-scope local variables. As a result, the local variables can be shared across all calls to the block of code (i.e. method). 

So, do anonymous delegates in C# v2.0 conform to the definition of lexical closures? That seems to be a matter of great debate. It is amazing when you start to look at a topic and then you realize that there has been a whole crowd to the party before you. Anonymous delegates in C# appear to be just such a topic. Brad appears to have been interested in the topic about a year ago. Brad takes the stance (at least at that time) that anonymous delegates are not closures. abhinaba also takes the same stance. Dan Muller takes the opposite opinion, believing that C# has implemented closures.

I've come to the conclusion that anonymous delegates are closures. If you look at my somewhat-in-depth explanation of anonymous delegates in my last post, you'll see that the way they work seems to conform to the three definitions above. In summary, the C# compiler generates a class on your behalf which contains both an instance method (which is your anonymous delegate) and fields that map directly to the in-scope variables that you access in the containing method. All access to these variables are wired up to these generated fields on the class. That generated class is in itself the closure. Being heap-allocated, it naturally can have a different lifetime than what the containing method has on the stack, given that stack-frames have a tendency to go way.

I have a mail out to the C# team asking them their opinion on this interesting subject. I'm curious to see how they'll respond.

Here is a better example of using an anonymous delegate that proves, in my mind, that they are lexical closures. I sure hope my definition of closures is correct ;)

Here's the code. Please do guess what it does or better yet, compile and run it. The important aspect is to guess which values of "s" do or do not match.

using System;

using System.Threading;

 

 

namespace AnonDelegateTest2

{

    class Program

    {

        delegate void FunkyDelegate();

 

        static void Main(string[] args)

        {

            FunkyDelegate fd = GetDelegate();

 

            for (Int32 i = 0; i < 10; i++)

            {

                fd();

            }

        }

 

        static FunkyDelegate GetDelegate()

        {

            String s = DateTime.Now.Ticks.ToString();

 

            FunkyDelegate fd = delegate()

            {

                Console.WriteLine("Entering fd");

                Console.WriteLine(s);

                s = DateTime.Now.Ticks.ToString();

                Thread.Sleep(100);

                Console.WriteLine(s);

                Console.WriteLine("Leaving fd");

                Console.WriteLine();

            };

 

            return fd;

        }

    }

 

}