XML Generics
Designing a programming language is like inventing a metaphor for thought. Most of the time you struggle to find just the right metaphor, hoping the one you eventually choose will be the best at communicating the idea it is meant to represent. So you can imagine the process of language design leaves a lot of dead ideas on the floor as it refines itself toward the ultimate goal of intuitive expression. This can happen for many reasons, but often it turns out to be just that some representations are better than others due to the way they evoke immediate recognition, understanding and emotional attachment. Often the best representations have nothing to do with logic or consistency. Sometimes they are just better.
That's why we got so much immediate flak internally when we first introduced XML Generics. It was hard to understand the logic in them, but the emotional draw was undeniable. They just seemed to be the right thing. It's not that we did not care to hear the feedback from others, it was just that we knew going in that those closest to us were too tainted/attached to the current design. Developers and most other logically minded folk have a difficult time detaching from what they know, stepping back and taking in the bigger picture. And believe me the design for XML generics was going to be a big change, one that would be very difficult to understand without a deep appreciation for where we were going with the language.
Likewise, it was anticipated that many in the blogging community would have a similar reaction, so we decided early on that we would need to reach out to the community directly, explain our approach, and gather what feedback we could before launching into a full scale marketing push on the unification of XML and Generics.
Some of the more touchy-feely readers out there might start to see it already. The intuitive leap needed to bridge the two ideas together is one that must be made emotionally not logically. On the surface, the two might seem to have nothing to do with each other, but if you dig deeper you soon realize that the two are fundamentally linked, both concepts actually compliments of one another.
To bring the rest of you up to speed, let’s first take a look at generics, a new feature in C# 2.0 that allows you to define parameterized types. A generic type is defined using the syntax below. The name ‘T’ refers to the type that parameterizes Foo. Generic types can have one or more parameters that are substituted on use with actual types.
public class Foo<T> { … }
When you refer to a generic type, you do so in a similar way, replacing the parameter with the type you would like to use instead, such as in the variable declaration below.
Foo<int> x;
As anyone can clearly see generic types have a striking resemblance to XML. Both represent parameterized data. Both are descriptive and declarative.
<Foo x=”…” />
We realized intuitively that a greater generalization could exist that tied the two together. Since this is a quality we strive for when designing the language we knew we were on to something if we just could find the right metaphor to bring the two together in the syntax.
And that’s when it hit me. The solution was right there, obvious all along. As it turns out, it was the reason that the whole thing was intuitive in the first place. It was the brackets, the angle-brackets. They were the key. So you can understand how the syntax had to change, to evolve, to make the two into one.
Foo<int x = “…” />
It was beautiful.
That’s why I’m so annoyed that it got dropped for something better. I mean really, do you think pure genius like this grows on trees?
But I digress
Matt
This post rated: AH - Attempt at Humor
Comments
- Anonymous
July 23, 2005
.. So where are you going with it?
My interpretation of the syntax is not unlike what I understand C++ Templates already have, with templated values (as opposed to templated types) in the definition of a class. - Anonymous
July 24, 2005
Microsoft's Matt Warren gives us a glimpse into the design process of C# 3.0 in a post titled XML Generics... - Anonymous
July 24, 2005
The comment has been removed - Anonymous
July 24, 2005
Mabye my slight of hand was too quick. XML syntax, generics syntax, merge them together: xml generics. It's supposed to be inane. - Anonymous
July 24, 2005
I for one found it pretty funny ;-) - Anonymous
July 24, 2005
The comment has been removed - Anonymous
July 24, 2005
I suppose you could merge them together and get syntax sytnax. - Anonymous
July 24, 2005
Syntax Syntax? Sure, now we're talking. Unfortunately, we cannot use ideas from outside sources no matter how promising they are. Blame legal. - Anonymous
July 24, 2005
I'm not sure how useful NTuples would be, or how you could actually use them. Sure, if they really were all just n fields of the same type you could have an indexer access them. But tuples in general have fields of diferrent types and you can't readily define that even with value based templates. I've thought about solving this problem before (no joke) and have proposed using type-generating macros (or something like it) to define rules about how parameterized types are actually defined. This would be something quite different than an incremental step for the language however. Good topic for a research paper. - Anonymous
July 24, 2005
If the value parameterization were limited to primitive types, and if one could define compile-time type operations using primitive operations on the value parameters, then one could define:
List<T, (int) u> Append(List<T, (int) n> list1, List<T, (int) m> list2) where u = n+m
.. which gives us compile-time array bounds safety.
There could also be applications in scientific computation, where it could be used for compile-time units verification (a unit can be expressed as an n-row, 2-column matrix of scalars and exponents, 1 row per axis [length, charge, time, etc]).
I suppose something like XC# could perform something to the effect, using attributes. It's certainly feasible to create a units library in the current CLR, but even in 2.0 you aren't able to express the idea that a type's identity is dependent on the value of a parameter. So in neither case do you have the deep type identification that putting it in the CLR would.
There's another area of compile-time checking that isn't quite there yet, and that would be domain/range checks on functions. That would have to be able to trace through a function to determine, given a range of inputs, what the output could potentially be (eg, RealSin(Real) -> [-1, +1]; RealArcSin([-1, +1]) -> [-pi/2, +pi/2]; RealArcSin(2) -> compile error. Of course, some sets are a little more complex, like the set resulting from a comb function...
Time to aim MSR at the problem, perhaps? I imagine it could build off of the Spec# work. - Anonymous
July 25, 2005
It seems that the critical piece of NTuples that's missing is the inherent recursion?
For example
NTuple<float, 2>
{
built on NTuple <float, 2> Technology
} - Anonymous
July 26, 2005
I have been using the new features in .Net version 2, including generics, but I can not not any more info on XML generics.
What do you mean "got dropped for something better"? Is this in .Net 2 or 3?
Can you clarify? This sounds very intriquing, but please provide more info and examples. - Anonymous
July 26, 2005
If you thought that some smell of XML in C-omega was amazing, believe me that's nothing. Major XML and .NET integration stories are still ahead of us. Something big is cooking inside the house. Look at these news.... - Anonymous
July 26, 2005
If you thought that some smell of XML in C-omega was amazing, believe me that's nothing. Major XML and .NET integration stories are still ahead of us. Something big is cooking inside the house. Look at these news.... - Anonymous
July 26, 2005
The comment has been removed