Lambda the Ultimate

Integer! iCannotBeNull;

Then again, what would be the difference between "Integer!" and "int"? And between "Integer" and "int?"?.

Indeed, the entire Nullable Type concept in C# 2.0 arises due to there being "special" data types (int, etc.). Ironically, those types in C# were designed to be an improvement on Java by removing the int vs. Integer dichotomy. But instead of making them true objects, they became "part-time" objects.

As part-time objects, variables of that type can never be null, hence the need for a similar *object* to have a "null-like" value in its domain.

Sigh. Complexity on top of complexity to solve problems due to complexity.

There is a much cleaner way of implementing pointers:

- For every type t, the type ^t represents "the type of pointers to elements of type t". These include only the actual pointers which can be safely dereferenced.

- For every type t, the type ?t represents "either an element of t or the special 'null' value".

- Then ?^t is the equivalant of "pointers that may be null". Define a shortcut syntax for this: *t = ?^t, and there! You have backwards compatibility and a more sensible type theory.

Unfortunately, C# confuses pointers and objects and mutability issues in so many other ways that such implementing this orthogonality is probably not worthwhile.

We put the nulls last, which is the opposite than a C programmer would expect. The domain in question was implementing the Z39.50 IR protocol, which actually neglects to say what missing values mean when sorting. (The Z39.50 protocol neglects to mention a lot of things.) Our reasoning was that if you sort on a datanase field it's because you find that field interesting, and records with that field missing are comparatively uninteresting, hence they should go last.

Like all DSLs, analysing the domain is often the only way to solve these issues.

That's how we did it as well, IIRC.

XmlElement.GetAttribute() returns an empty string if you specify an attibute that doesn't exist; XmlReader.GetAttribute() returns null.

Of course, string is already a class (not a struct), and therefore nullable.

Apparently the former behavior is specified by the DOM: http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-666EE0F9

And then Element.getAttributeNode() returns null for non-existant attributes. (I guess the DOM wants to be compatible with languages with non-nullable strings?)

Everything you say is right on target.

Pseudonym: When you sort values into order, where do the null values come? We put the nulls last

This is really a bogus question, which stems from the belief that everything in the world is linearly orderable in a unique way (which is patently wrong) or, less dogmatically, from the limitations of languages which can only comforably support one way to order values of a type. (The latter includes Haskell, BTW.)

The truth is, there are many ways to order things. If I add an element to an ordered set, and I want to produce another ordered set, then there are many ways to do it, and putting the element at the beginning or end are only two possibilities, and in some applications one, both or neither will be the right choice.

Therefore, the only sensible, general-purpose way to regard an order is not as a property intrinsic to a set, but rather as a structure one places upon a set.

Of course, someone will say, "But hey, the natural numbers are intrinsically ordered, aren't they?" The answer is, Yes, if you regard them as an object of the category of linearly ordered sets (sets paired with a linear order), but: No, if you regard them as an object of the category of sets, because then the order comes from the arrow structure of the category, not the object structure.