I mentioned it a while back, but I have some level of platform interop working with Sencha. By “platform interop,” I mean writing code that uses functions defined elsewhere (i.e. not Scheme built-ins and not custom written stuff). The gunk that enables this usually ends up making a best guess at binding, in some cases performing operations to bridge the type system gap that exists.

One of the interesting things I noticed along the way was how easy it is to work with XML inside Scheme. I do some marshalling back and forth using factories so that, when you're in Scheme, you see S-expressions which can be processed and transformed as ordinary lists of data. When you're using Framework APIs that expect XmlReaders, Documents, and the like, however, they see what they expect. It's admittedly dangerous to perform this style of conversion implicitly, but for the time being it's been the source of some fun experimentation.

For example, generating SOAP is quite simple, etc.:

'(Envelope (:ns s)
     (@xmlns:s "http://www.w3.org/2003/05/soap-envelope")
     (@xmlns:wsa "http://schemas.xmlsoap.org/ws/2004/08/addressing")
     (@xmlns:f123 "http://www.fabrikam123.example/svc53")
   (Header (:ns s)
     (MessageID (:ns wsa) "uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff")
     (ReplyTo (:ns wsa)
       (Address (:ns wsa) "http://business456.example/client1"))
     (To (@mustUnderstand "1") (:ns wsa) "mailto:joe@fabrikam123.example")
     (Action (:ns wsa) (@mustUnderstand "1")
       "http://fabrikam123.example/mail/Delete"))
   (Body (:ns s)
     (Delete (:ns f123)
       (maxCount 42))))

Similar to what's possible in C-omega, quasiquotations enable you to embed calculations in the message. For example, the body node could have been:

'(Body (:ns s)
  ,(generateSoapBody ,42))

Which has the nice effect of substituting the return value of the generateSoapBody function, passing 42 as its argument.

As I said, the greatest thing about this is that you can use all of the list processing techniques that Lisp langauges are good for, existing libraries, and so on, and then easily convert the result back into XML. Parsing, schema and namespace validation, resource resolution (e.g. DTDs) is all done for you by the existing System.Xml Framework libraries.

I know that the linkage between the two technologies has been observed in the past, but it seems like there's a lot of room for innovation in the future. Update: just noticed this page. Some interesting stuff.

I can't imagine what it would have been like to write a CLR/.NET Framework 1.0 book before it was released from the outside. That is, while not working for Microsoft.

I just upgraded from Whidbey Beta1 to PD7, and found a ton of interesting changes. Mostly API renames which, thankfully, are done through obsoleting the old one. This makes migrating much smoother since the build doesn't break, and I can just follow up on the warnings as needed. I have to be better about keeping up from drop to drop. Even without doing that, though, every so often I get wind of a change via email or word of mouth, and make a note to check it out at some point in the future. I basically have a whole set of Outlook folders, one for each chapter, with nearly one hundred todo's... One has to wonder if I'll ever be able to follow up on them all. :)

Luckily, I also have a whole suite of test cases which I am using to verify when something changes. Basically, anything I write about, I write a test case for. This has definitely been one of the best decisions I made towards the beginning of the project. This at least helps to identify areas where the text might now be out of date, and points directly to code samples which are obsolete.

Simon's "how to write a great research paper" material is simply great. I think I need to follow his advice, particularly about starting to write early and often.

I've countless ideas bouncing inside my head, most of which will simply get lost, but many of which I truly believe should see the light of day. I think I'm a bit of an over-thinker, and tend to wait until my ideas sufficiently mature before expressing them. It's weird, but I guess I've always been like that. The problem is, I have so much stuff that goes on in a typical day, so many ideas coming and going, that I'm not able to mature those ideas as I would like. Most of it just gathers dust and eventually dissapears. I suspect a lot of people have this problem.

Ideas are cheap.

There's a significant difference between an idea and an implementation of that idea. This, too, is where I get caught up. Sure I could come up with some nice theoretical goop, but if there's no implementation, what the hell good is it? Somebody might read it someday, but likely not. But unfortunately, implementing an idea is much more costly than simply thinking it. And I tend to get bored pretty quickly anyhow, instead preempting progress in order to gravitate towards better ideas that I perceive to be more worth my time.

It seems to me that the most successful people in our society are those that can follow through and execute on mediocre-to-good ideas. There's much more value in being able to implement an idea (be it your own or somebody elses) than actually thinking it in the first place.

Open source seems to be pretty helpful in solving this problem. Similar to how a senior researcher will often be given a group of folks to implement his/her ideas, if you can start an open source project and convince a bunch of people it's worthwhile you can acheive much more in a shorter period of time than doing it by yourself. Of course, commercial environments are much like this, too, but it's often more difficult to sell ideas in a corporate environment. In a smaller business, you're likely to have a better chance. Starting a start-up to implement your idea is another great option, one that's usually significantly most costly than any of the others above.

I mention all of this without discussing goals. What is the goal of implementing an idea anyhow? For some, I suppose it's money. A good implementation of a good idea probably will get some level of recognition, and with clever distribution models for that idea, you could make some cash. But for a lot of people, I think it's laying the foundation for future ideas. As Simon puts it, infecting your audience with your idea. So when I mention “benefit,“ it's highly subjective based on whether you're a greedy bastard or a naive idealog (of course there are other choices, too ;)).

How does one evaluate the cost/benefit of following through on an idea? I wonder if there are any decent models out there that would help. I suppose choosing between ideas is a bit like branching between possible nodes in a graph in elementary utility theory. Simply calculate the probability of a given outcome, cost of traversing the node, and perceived benefit, and simply seek to minimize cost and maximize benefit. Seems so simple. The inherent lack of structure in human thought troubles me. The fact that I put up with it even more so.

Random.

Back to writing my book.

From Paul Graham's recent post

I think you should say "College is where faking starts to stop working."

This statement is up for interpretation. But I at least think I understand the gist.

I've always been fascinated with academia at least partially for this reason, and I've noticed a progressing desire as I age to be in environments where “faking it” is less and less tolerable. Microsoft is certainly more of a meritocracy, most academic organizations even more so. (Although, from what I hear, tenure tends to spoil this effect in many cases.) I spend countless hours of recreational time in order to improve my own thinking, mostly by studying formal theories and interesting works, but also through exercises such as writing compilers and learning new programming languages and ideas. It frustrates me to no end when somebody can get by, not on the merit or accuracy of their ideas, but rather due to politics or the networking effect of a bunch of fakers who can't recognize the difference.

But I am also very cognizant of what I do not know or understand. This, I think, is equally as important to knowing a lot. Well, at least in a person interesting in contributing at least one idea of importance to a field. Interestingly, Simon makes this same point in his “how to write a good research paper” talk referenced here. He advises that the process of understanding what you do not know helps you to better focus your research activities to fill in the gaps. I couldn't agree more. (In my limited experience.) The sooner you identify these areas, the sooner you can make progress.

I also find it interesting that, through the act of filling knowledge gaps, the foundational knowledge built up in your head seems to shift, sometimes causing other areas to become obsolete. This tends to create new gaps which need to be re-filled in the context of the new shifted foundation, but also creates new and interesting connections and clarifications on previously faulty mental models (which you might have thought were accurate, and which still likely aren't). But it's a beautiful, iterative process. No room for faking. And it certainly never ends.

This can probably fall into the “paranoid programmer“ category... where this time the paranoia is not about async exceptions, but rather about pulling in the JIT unnecessarily.

Back in September, we did a fair amount of work documenting and getting FxCop rules in place to check when the use of generics can cause an NGen'd assembly to JIT. This was mostly in response to our general no-JIT plan that most managed code we ship is on. In particular, Avalon drove us hard to come up with this.

Joel has a great entry about code sharing vis-a-vis generics over on his blog. I'd read that alongside this.

(BTW, in re-reading my DG update entry before posting, I think there's some significant clarification and re-work that we could/should do. Add it to the growing stack of things to do! :))

Generics and Performance

• Do consider the performance ramifications of generics. Specific recommendations arise from these considerations and are described in guidelines that follow.

Execution Time Considerations

• Generic collections over value types (e.g. List<int>) tend to be faster than equivalent collections of Object (e.g. ArrayList) because they avoid boxing items.
• Generic collections over all types also tend to be faster because they do not incur a checked cast to obtain items from the collection.
• The static fields of a generic type are replicated, unshared, for each constructed type. The class constructor of a generic type is called for each constructed type. For example,

public class Counted<T>

{

    public static int count;

    public T t;

    static Counted()

    {

        count = 0;

    }

    Counted(T t)

    {

        this.t = t;

        ++count;

    }

}

Each constructed type Counted<int>, Counted<string>, etc. has its own copy of the static field, and the static class constructor is called once for each constructed type. These static member costs can quietly add up. Also, accesses to static fields of generic types may be slower than accesses to static fields of ordinary types.

• Generic methods, being generic, do not enjoy certain JIT compiler optimizations, but this is of little concern for all but the most performance critical code. For example, the optimization that a cast from a derived type to a base type need not be checked is not applied when one of the types is a generic parameter type.

Code Size Considerations

• The CLR shares IL, metadata, and some JIT’d/NGEN’d native code across types/methods constructed from generic types/methods. Thus the space cost of each constructed type is modest, less than that of an empty conventional non-generic type. But see also ‘current limitations’ below.
• When a generic type references other generic types, then each of its constructed types constructs its transitively referenced generic types. For example, List<T> references IEnumerable<T>, so use of List<string> also incurs the modest cost of constructing type IEnumerable<string>.

Current Code Sharing Limitations

In the current CLR implementation, native code method sharing for disparate generic type combinations occurs only for types constructed over reference type parameters (e.g., List<object>, List<string>, List<MyReferenceType>). Each type constructed over value type parameters (e.g., List<int>, List<MyStruct>, List<MyEnum>) will incur a separate copy of the native code for the methods in those constructed types. For comparison purposes, this is similar to the runtime cost of creating your own strongly typed collection class.

A consequence of this is that using a generic type defined in mscorlib in combination with value type parameters also from mscorlib could cause an NGen image to invoke the JIT during execution, resulting in a negative effect on performance. This is limited to mscorlib because it is the only assembly always loaded domain-neutral, and for a variety of reasons there are limitations on code sharing when working with domain-neutral assemblies. (Note: domain-neutrality is a load time decision, so it is possible that this would affect other assemblies, too.) For generic types that take a single type parameter, for example, t is relatively straightforward to determine whether this will affect your scenario: When instantiating G<VT>, where generic type G and value type parameter VT are both defined in mscorlib, you will JIT unless G<VT> is found in the following list:

ArraySegment<Byte>

Nullable<Boolean>

Nullable<Byte>

Nullable<Char>

Nullable<DateTime>

Nullable<Decimal>

Nullable<Double>

Nullable<Guid>

Nullable<Int16>

Nullable<Int32>

Nullable<Int64>

Nullable<Single>

Nullable<TimeSpan>

List<Boolean>

List<Byte>

List<DateTime>

List<Decimal>

List<Double>

List<Guid>

List<Int16>

List<Int32>

List<Int64>

List<SByte>

List<Single>

List<TimeSpan>

List<UInt16>

List<UInt32>

List<UInt64>

This is so because we have added some code to bake the data structures for these generic instantiations into mscorlib. Because it affects the working set of mscorlib, we couldn’t do it for every possible combination. For generic type instantiations that take multiple type parameters, the rules are more complex: Roughly, when instantiating G<T1…Tn>, where generic type G and each T in T1…Tn are defined in mscorlib, at least one of which is a value type, you will JIT unless G<T1…Tn> is found in the following list (note: substitute Object for any reference type parameter):

Dictionary<Char, Object>

Dictionary<Int16, IntPtr>

Dictionary<Int32, Byte>

Dictionary<Int32, Int32>

Dictionary<Int32, Object>

Dictionary<IntPtr, Int16>

Dictionary<Object, Char>

Dictionary<Object, Guid>

Dictionary<Object, Int32>

KeyValuePair<Char, UInt16>

KeyValuePair<UInt16, Double>

Please notice that JIT will neither occur when using a custom generic type with mscorlib type arguments (e.g. MyType<int>), nor when using an mscorlib type with your own type arguments (e.g. List<MyStruct>).

What is described above is actually the worst case scenario. There are some subtleties that could result in a more relaxed application of these rules. Unless the coverage above has caused you to worry whether you might be affected, it’s probably safe to skip this section. A more comprehensive explanation of these subtle variables follows:

Annotation (RicoM):

Let A be an assembly, G a generic type on n parameters, T1…Tn

A generic type G<T1,…,Tn> shares code with type H<S1,…,Sn> if and only if

- G = H and,

- for all i in [1..n] either

- Ti = Si, or,

- Ti shares code with Si, or,

- both Ti and Si are reference types.

------

Assume that A has been NGen'd, then:

If G is defined in A

- A may use G<T1…Tn> with no restrictions on T1…Tn, no JITting is required,

- A will include G<Object,…,Object> even if it is not otherwise mentioned

- The above two uses are present in A for other assemblies to use

(Remaining cases G not defined in A)

If all of T1…Tn are defined in A

- A may use G<T1…Tn> with no restrictions on T1…Tn, no JITting is required

- Any such G<T1…Tn> will be present in the NGen’d image of A for other assemblies to use

(Remaining case at least one of T1..Tn not defined in A)

If A depends on assembly B and B has a type that shares code with G<T1…Tn>

- A may use G<T1…Tn> as found in B, no JITting is required

- A will not contain code for G<T1…Tn>

(Remaining case, no match possible, this is the fallback position)

A copy of G<T1…Tn> will be emitted into the NGen'd code for A, this code is available for other assemblies to use (subject to these same rules)

If A is loaded domain-specific and G, T1..Tn are all loaded from domain-neutral assemblies then

- The CLR will be unable to use the copy in A and will JIT a new one

Otherwise

- The copy of the code in A is used and there is no JITting

These rules apply transitively to all generic instantiations encountered when JITting the code for both the non-generic classes (which may contain generic members), and generic classes (which may have generic members or parameters themselves) and the “seed” <Object,…,Object> instantiations in the assembly.

In the future, more method sharing may be possible, but a high degree of code sharing over different struct type parameters is unlikely or impossible.

Summary

In summary, from the performance perspective, generics are a sometimes-efficient facility that should be applied with great care and in moderation. When you employ a new constructed type formed from a pre-existing generic type, with a reference type parameter, the performance costs are modest but not zero. The stakes are much higher when you introduce new generic types and methods for use internal or external to your assembly. If used with value type parameters, each method you define can be quietly replicated dozens of times (when used across dozens of constructed types).

• Do use the pre-defined System.Collections.Generic types over reference types. Since the cost of each constructed type AGenericCollection<ReferenceType> is modest, it is appropriate to employ such types in preference to defining new strongly-typed-wrapper collection subtypes.
• Do use the pre-defined System.Collections.Generic types over value types in preference to defining a new custom collection type. As was the case with C++ templates, there is currently no sharing of the compiled methods of such constructed types – e.g. no sharing of the native code transitively compiled for the methods of List<MyStruct> and List<YourStruct>. Only construct these types when you are certain the savings in dynamic heap allocations of avoiding boxing will pay for the replicated code space costs.
• Do use Nullable<T> and EventHandler<T> even over value types. We will work to make these two important generic types as efficient as possible.
• Do not introduce new generic types and methods without fully understanding, measuring, and documenting the performance ramifications of their expected use.

I guess maybe I'm a moron, but I just don't get posts like these (here and here).

Targeting the CLR is just like targeting any other machine, such as x86 for example. It just happens to be a little easier. Fortunately, we provide a big bag of pre-built abstractions. If you want to party with a category of other languages that already target the platform, you can choose to take advantage of these abstractions and be labeled CLS compliant. I'll be the first to admit that this entails some sacrifice, and a bit of kowtow to the C# gods. But it's a freaking choice. And not doing it leaves you no worse off than if you chose to target a different platform. Further, you can opt to produce verifiable code and take advantage of the runtime's security sandbox. This too requires little sacrifice, although your solutions might not seem as clever. Or not.

You're free to build up your own abstractions. You still get a bunch for free, like a kickass GC, a crapload of libraries (my Scheme runtime lib mostly consisted of one or two calls into Framework code), tools for debugging/profiling, and so on. Write 'em from scratch if you wish, it's all good. I know a lot of people enjoy writing GC's in their spare time (I'm not trying to be funny... it seems like a terribly complex and challenging exercise).

But, if somebody claims they can't write a dynamic language compiler on the CLR, well, they're certainly incapable of producing a dynamic language compiler that targets x86 or any other machine/VM. Or they're lying. So it hardly matters. It doesn't require too much imagination.

If somebody claims they can't write a dynamic language compiler on the CLR that interopates well with other CLR languages, we're working on making this better. But it seems that this is an even bigger challenge if you intend to interoperate at a layer above the platform altogether. So again, things certainly aren't worse on the CLR.

But hey... I'm now just another Redmond-ite who has had a little too much kool-aid for dinner. Oh! I'm late for my evening brainwashing session. BillG is good. BillG is great. ;)

Just a quick reminder, as Brad and Kit mentioned, a bunch of the CLR and BCL team will be at the Chili's in the Bellevue Crossroads mall tomorrow (Tue, 3/22). Starts at roughly 5:30pm... I'm hoping there will be more customers and partners than Microsoft employees!

I was just working on some early work on the STG->IL compiler I mentioned last week. Perhaps my brain is just shifting a little too much into functional mode, but I designed my entire AST to avoid any fields for almost all nodes. Things that would ordinarily call for fields are just pairs (or higher order combinations of pairs, such as triples and lists). I don't know if this is good, bad, or whatever, but it's certainly interesting.

For example, given the nonterminals:

prog : binds
binds : var1 = lf1; ...; varn = lfn (where n >= 1)
lf : varsa \u varsb -> expr

Well, prog just derives from binds. Binds is simply a list of pairs of vars and lfs (lambda forms). Vars are just symbols (which themselves are just strings, but alas I can't derive from string in the Framework since it's sealed, so here I do need a field unless I choose to just use List<char>), and lambda forms are just quintuples of other stuff. All of these use a marker interface IAstNode to indicate that they're an AST node rather than cluttering up their inheritence hierarchy.

For example:

interface IAstNode {}
class Program : IAstNode, BindingList {}
class BindingList : IAstNode, List<Binding> {}
class Binding : Pair<Variable, LambdaForm> {}
class Quintuple<A,B,C,D> : Pair<A,Pair<B,Pair<C,D>>>
class LambdaForm : Quintuple<VariableList, UpdateFlag, VariableList, Expression> {}
...and so on...

Why do I find this so much more beautiful than the dirty, messy, more verbose field-based approach? I mean, everybody always talks about the is-a thing when preaching OOP... But if a program is-a list of bindings, and a binding is-a blah why not reflect that in the type relationships?

Anyhow, this isn't thought through too much. But it certainly seems clearer. For example, we do a lot of work in the framework to make strings seem like lists of characters... Why fake it? E.g. class String : List<char> { /*string-specific functions*/ }. Surely string is conceptually closer to having a list of characters being its direct supertype than plain old vanilla object. (Although on second thought the realities of performance and such probably limit the extent to which we could do this.) I guess it's the old aggregation versus inheritence argument. Blegh.

But it's really nice that I can program like this if I wish. Being able to compose powerful abstractions through nothing but inheritence and polymorphism is a great feature of and a testament to the CTS.

BTW: How did we all survive w/out generics pre-2.0?

I recently sent this out to an internal audience. I saw no reason not to share it with external folks, too... Although most of it probably won't be of interest, maybe somebody out there will get something useful from it.

Atomicity & Asynchronous Exception Failures

I’m in the process of writing up several articles/whitepapers that I intend to start publishing over the coming weeks.

• Dispose, Finalization & Resource Management Design Guidelines: I’ve been iteratively working on these updates over the past couple months and just submitted the whole thing to our core review group to solicit feedback, comments, and the like. It covers the recent unification work we did around the Dispose pattern in the Framework, along with general guidance on writing correct resource management code. For a bit of history around this, check out here and here. The end result turned out to be a bit longer and larger than I had originally intended, but I think I was able to lay it out in an intuitive and easily consumable way.
• Writing Atomic Abort-Safe Code: A lot of people writing code for the Framework lose a bunch of sleep over writing the most reliable code possible. However, our guidance on how to do this in the face of asynchronous thread aborts hasn’t been clear in the past, especially when writing paired operations (e.g. acquire/release semantics). So a bunch of us got together, discussed it, and decided we need to come up with some clear guidelines. I’m writing up a brief article and following it up with a DG update and some FxCop rule proposals. Priority #1: convince most people that they needn’t worry about these things. Only then will the painful details of abort semantics, AD unloads, CERs, critical finalizers, finallys, and the like be presented.
• Threading Security Best Practices Design Guidelines: During the recent Whidbey security push, we produced a lot of great content around how to write secure multi-threaded code. Unfortunately, for obvious reasons much of this must remain inside MS. But some of the more general guidance is being incorporated into the DG. This includes, for example, avoiding publicly-accessible locks, never accepting ReaderWriterLock LockCookies from untrusted sources, and avoiding message pumping inside a synchronized region. Hopefully this will help users of the Framework to write more robust and secure code, too.
• Concurrency & Parallelism: These topics are more personal research interests of mine, but nonetheless somewhat related to my job as the threading PM. I walk through a number of aspects about concurrency, parallelism (yes there’s a difference), and the nature of each. Specifically with regards to parallelism, I discuss the intrinsic algorithmic properties which are conducive to parallel execution, some theoretical math which demonstrates that, with the right multi-x (where x is core|proc) and task management architectures, the future looks promising. Check out this butterfly sorter. I recently had an interesting conversation with its author, Satnam Singh, and we seem to agree on many things. This particular example was designed and implemented in specialized hardware, but there’s no reason why we can’t write such things generically in software to take advantage of the underlying hardware support. I present some interesting evidence and conclusions to support this assertion.
• Compiling Scheme to IL with Sencha: Again, personal research area. I need to write up some findings based on my compiler work, what I consider to be the unique features of Sencha, and mostly just capture knowledge so I have something to refer back to. I’m thinking more seriously about another compiler effort, and have chatted with the GHC and MSR folks a bit about it. Basically, I intend to create a STG textual format and a corresponding STG-to-IL compiler, based on Simon’s Spineless Tagless G-Machine paper. I believe this could then be used easily as a backend to the GHC compiler. Very ambitious project with a limited user audience, but it seems to have a lot of interesting facets to it. Such software could be used for parallel research on the CLR in the future.