Lambda the Ultimate

inactiveTopic Nullable Types
started 5/29/2004; 3:42:07 AM - last post 6/3/2004; 11:21:16 AM
Ehud Lamm - Nullable Types  blueArrow
5/29/2004; 3:42:07 AM (reads: 12708, responses: 9)
Nullable Types
A discussion of nullable types is sweeping through the C# blogosphere.

This is a nice, fairly self-contained, language design exercise.

Should languages provide such a feature, and if they do, how should nullable types behave (e.g., does null==null ?).

A DSL I worked on that was used for data analysis had two special values represeting missing and erroneous data. Builtin functions each had to decide how to handle these special values. It was quite useful in practice.

Posted to general by Ehud Lamm on 5/29/04; 3:42:35 AM

Andris Birkmanis - Re: Nullable Types  blueArrow
5/29/2004; 7:03:00 AM (reads: 568, responses: 0)
So now the unboxed types got the option to include null in their domain, as boxed types could do all the time. What about making them equal, and provide an option for the boxed ones to exclude null? Like:

Integer! iCannotBeNull;

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

Patrick Logan - Re: Nullable Types  blueArrow
5/29/2004; 6:26:42 PM (reads: 499, responses: 0)
What about making them equal...

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.

Dave Herman - Re: Nullable Types  blueArrow
5/29/2004; 8:06:12 PM (reads: 491, responses: 0)
FWIW, I recall that Nice has something relevant.

Tim Sweeney - Re: Nullable Types  blueArrow
5/31/2004; 6:15:22 PM (reads: 331, responses: 1)
The existance of the "null pointer" is a language design mistake dating back three decades. Instead of keeping the notions of "pointers to elements of type t" and "type t extended with an additional 'null' value" separate, C combined the two orthogonal notions into a single type constructor: pointers that might be 'null'. C++ confused things further by defining references in a way that makes it look like they can't be null, though they actually can be!

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.

Pseudonym - Re: Nullable Types  blueArrow
5/31/2004; 8:12:55 PM (reads: 320, responses: 1)
Oddly enough, this is an issue that I had to deal with at work this week. The question there was: When you sort values into order, where do the null values come?

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.

Ehud Lamm - Re: Nullable Types  blueArrow
5/31/2004; 11:00:32 PM (reads: 314, responses: 0)
We put the nulls last

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

Adam Vandenberg - Re: Nullable Types  blueArrow
6/2/2004; 1:12:17 PM (reads: 201, responses: 0)
.NET has a few different APIs for processing XML.

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:

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

Dan Shappir - Re: Nullable Types  blueArrow
6/3/2004; 2:32:41 AM (reads: 182, responses: 0)
I was going to respond to Tim's post but Luke Hutteman pretty much summarized all I had to say.

Frank Atanassow - Re: Nullable Types  blueArrow
6/3/2004; 11:21:16 AM (reads: 169, responses: 0)
Tim: [everything]

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.