Hi,

I'm getting more and more intrigued by the way Delight [1] and F# [2] handle nullable types: using the type-system to check for "nullness" the way it does for constness*. I haven't used either one of those two languages, but since having read about both systems, I can't help keeping a tag in my mind for each variable; "this one can be null", "this one can't be null"...

* Is there anybody with experience using this concept of nullness in F# or Delight?

* Are there any other languages with this concept?

* I personally think it would be nice for D too. Your opinions?

L.

PS. I have the feeling this also can be generalized, like the green-code-red-code system. It's like a compile-time tagging of variables, with some added syntactic sugar (the ?-token).

[1] http://delight.sourceforge.net/null.html
[2] http://research.microsoft.com/fsharp/manual/import-interop.aspx#Nullness 

Lionello Lunesu Wrote:

> * Are there any other languages with this concept?

C# does. Nullable types have a question mark after them. eg:-

int? num = null;

http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx

samabeau wrote:
> Lionello Lunesu Wrote:
>  
>> * Are there any other languages with this concept?
> 
> C# does. Nullable types have a question mark after them.
> eg:-
> 
> int? num = null;
> 
> http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx
> 

In C#, that "?" basically wraps (boxes?) a value type into a reference type.

Once you have an object reference (either an instanced class or such a wrapped value type) you still must check for null everywhere you use it. And in some situations you just know it's never null and you would like to use that information.

At the moment, the way you can tell that an object is never null is by
(1) using an assertion;
(2) mentioning it in a comment;
(3) using some hungarian-like naming scheme;

None of which have any value at compile-time. In fact, if you think those 3 alternatives are good enough, you could drop all the compile-time type checking.

And what happens nowadays when none of those 3 is present? You check for null, whether the check makes sense or not. If I'd only get a penny for every if-null check I've encountered...

Letting the type system track whether a reference is null or not should result in more readable code. No more wondering "What if x is null? Where's it checked?" and no more "let's check for null, just in case."

L.

Lionello Lunesu wrote:
> samabeau wrote:
>> Lionello Lunesu Wrote:
>>  
>>> * Are there any other languages with this concept?
>>
>> C# does. Nullable types have a question mark after them.
>> eg:-
>>
>> int? num = null;
>>
>> http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx
>>
> 
> In C#, that "?" basically wraps (boxes?) a value type into a reference type.
> 
> Once you have an object reference (either an instanced class or such a wrapped value type) you still must check for null everywhere you use it. And in some situations you just know it's never null and you would like to use that information.
> 
> At the moment, the way you can tell that an object is never null is by
> (1) using an assertion;
> (2) mentioning it in a comment;
> (3) using some hungarian-like naming scheme;
> 
> None of which have any value at compile-time. In fact, if you think those 3 alternatives are good enough, you could drop all the compile-time type checking.
> 
> And what happens nowadays when none of those 3 is present? You check for null, whether the check makes sense or not. If I'd only get a penny for every if-null check I've encountered...
> 
> Letting the type system track whether a reference is null or not should result in more readable code. No more wondering "What if x is null? Where's it checked?" and no more "let's check for null, just in case."
> 

In Objective-C you can call methods on null(nil in Obj-C) objects. The call is silently ignored. So no more crashes or NPEs.

The problem with this is that if you call a method on a null object and try to use the return value as an initializer for a local variable, it will be set to 0 for numbers, nil for objects, and so on. This can lead to hard to find bugs.

I'm not an expert Objective-C programmer, not even close, so I cannot say if this system is preferable to crashing the whole application.

O.

"Lionello Lunesu" <lionello@lunesu.remove.com> wrote in message news:gdhd0f$g3v$1@digitalmars.com...
<snip>
> [1] http://delight.sourceforge.net/null.html

It seems that Delight had the same idea as Nice.  Which was first?

I see C# is a bit different - primitive types have nullable variants, but classes are always nullable.

Is there any language where you can have multiple levels of nullness? Something like Type?? which could represent, along with a Type object or lack thereof, a lack of any (Type object or lack thereof).  If that makes sense.  (It could be done with pointers in C/C++/D, but that adds levels of indirection and requires the programmer to allocate little bits of memory to deal with them.)

> [2] http://research.microsoft.com/fsharp/manual/import-interop.aspx#Nullness

This might take a bit of studying to make sense of....

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

On Mon, Oct 20, 2008 at 3:34 AM, Lionello Lunesu <lionello@lunesu.remove.com> wrote:
> Hi,
>
> I'm getting more and more intrigued by the way Delight [1] and F# [2] handle nullable types: using the type-system to check for "nullness" the way it does for constness*. I haven't used either one of those two languages, but since having read about both systems, I can't help keeping a tag in my mind for each variable; "this one can be null", "this one can't be null"...
>
> * Is there anybody with experience using this concept of nullness in F# or Delight?
>
> * Are there any other languages with this concept?
>
> * I personally think it would be nice for D too. Your opinions?

I just read up on Delight for the first time last night, and I didn't know it was more than just a syntactic wrapper around D.  The maybe types sound like something I'd really like to try out.

Stewart Gordon:
> It seems that Delight had the same idea as Nice.  Which was first?

Nice was first, of course.


> Is there any language where you can have multiple levels of nullness?

Cyclone has a quite refined (and it looks over-engineered) view of nullable pointers and the like. Boxes similar to nullable types are used often in Haskell, see the Maybe monad, etc.

Bye,
bearophile

Not true. It wraps the value type in a struct with a boolean field expressing whether it is null or not.

http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx

- Bent

"Lionello Lunesu" <lio@lunesu.remove.com> skrev i meddelelsen news:gdhs01$1jnp$1@digitalmars.com...
> samabeau wrote:
>> Lionello Lunesu Wrote:
>>
>>> * Are there any other languages with this concept?
>>
>> C# does. Nullable types have a question mark after them.
>> eg:-
>>
>> int? num = null;
>>
>> http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx
>>
>
> In C#, that "?" basically wraps (boxes?) a value type into a reference type.
>
> Once you have an object reference (either an instanced class or such a wrapped value type) you still must check for null everywhere you use it. And in some situations you just know it's never null and you would like to use that information.
>
> At the moment, the way you can tell that an object is never null is by
> (1) using an assertion;
> (2) mentioning it in a comment;
> (3) using some hungarian-like naming scheme;
>
> None of which have any value at compile-time. In fact, if you think those 3 alternatives are good enough, you could drop all the compile-time type checking.
>
> And what happens nowadays when none of those 3 is present? You check for null, whether the check makes sense or not. If I'd only get a penny for every if-null check I've encountered...
>
> Letting the type system track whether a reference is null or not should result in more readable code. No more wondering "What if x is null? Where's it checked?" and no more "let's check for null, just in case."
>
> L. 

Far more interesting that nullability of value types is non-nullability of reference types. The potential extinction of null-pointer exceptions. Spec# solves it, whether C# will solve it as well will be interesting to follow.

- Bent


"Lionello Lunesu" <lionello@lunesu.remove.com> skrev i meddelelsen news:gdhd0f$g3v$1@digitalmars.com...
> Hi,
>
> I'm getting more and more intrigued by the way Delight [1] and F# [2] handle nullable types: using the type-system to check for "nullness" the way it does for constness*. I haven't used either one of those two languages, but since having read about both systems, I can't help keeping a tag in my mind for each variable; "this one can be null", "this one can't be null"...
>
> * Is there anybody with experience using this concept of nullness in F# or Delight?
>
> * Are there any other languages with this concept?
>
> * I personally think it would be nice for D too. Your opinions?
>
> L.
>
> PS. I have the feeling this also can be generalized, like the green-code-red-code system. It's like a compile-time tagging of variables, with some added syntactic sugar (the ?-token).
>
> [1] http://delight.sourceforge.net/null.html
> [2] http://research.microsoft.com/fsharp/manual/import-interop.aspx#Nullness 

Bent Rasmussen wrote:
> Not true. It wraps the value type in a struct with a boolean field expressing whether it is null or not.
> 
> http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx

Indeed. Thanks for pointing that out.

So C#'s 'foo?' syntax has even less to do with this compile-time nullness checking.

L.