questions on nullability

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

questions on nullability

Burak Emir
Hi there,

The "Nullability" proposal reads
http://developer.mozilla.org/es4/proposals/nullability.html

zzz
Classes can be defined to be non-nullable by default via a special
declaration syntax:

class C! { ... }

This annotation does not imply anything about subclasses of C; they are
still nullable by default unless declared non-nullable.
zzz

This triggers some questions.
a) can I write

var c: C = new C // (1), or
var c: C! = new C // (2)

or are both equivalent (3)? IMHO explicit is better than implicit.

b) assuming only (3) is allowed (it doesn't really matter here),
consider the subclass mess:

class D extends C! {} // subclass can still be nullable
var c: C
var d: D = null
...
c = d

As I understand the proposal, this should not be allowed, because C does
not include null, but D does?

c) (unrelated to above) how can one turn a value of type A into a value
of type A! in order to guide the typechecker? a cast? a preceding
if(a!=null)?

cheers,
Burak

--
Burak Emir

http://lamp.epfl.ch/~emir


Reply | Threaded
Open this post in threaded view
|

Re: questions on nullability

Lars T Hansen
Burak Emir writes:
 > The "Nullability" proposal reads
 > http://developer.mozilla.org/es4/proposals/nullability.html
 >
 > zzz
 > Classes can be defined to be non-nullable by default via a special
 > declaration syntax:
 >
 > class C! { ... }
 >
 > This annotation does not imply anything about subclasses of C; they are
 > still nullable by default unless declared non-nullable.
 > zzz
 >
 > This triggers some questions.
 > a) can I write
 >
 > var c: C = new C // (1), or
 > var c: C! = new C // (2)
 > or are both equivalent (3)?

They are equivalent because the name C used in a type annotation
context means the same as C!, ie, null is not included.

 > IMHO explicit is better than implicit.

The entire reason that the class definition can be annotated is to
make it easier for the programmer not to have to worry about null when
using classes for which a null value does not make sense.  The
canonical example is "Complex": this is usually viewed as a "value
type", ie, it does not normally make sense to have Complex values that
can be null.  You'd want to write

  var c : Complex

not

  var c : Complex!

everywhere.

 > b) assuming only (3) is allowed (it doesn't really matter here),
 > consider the subclass mess:
 >
 > class D extends C! {} // subclass can still be nullable
 > var c: C
 > var d: D = null
 > ...
 > c = d
 >
 > As I understand the proposal, this should not be allowed, because C does
 > not include null, but D does?

I don't think the language on that has been written yet.  In the
standard language the assignment is unproblematic; there will be a
run-time check that d is not null, and an error will be thrown if it
is.  In the strict language I might be inclined to require a cast but
this has not been discussed, IIRC.  The list of strict errors does not
mention this case at this time.

 > c) (unrelated to above) how can one turn a value of type A into a value
 > of type A! in order to guide the typechecker? a cast? a preceding
 > if(a!=null)?

No control flow information should be used in the type checking, so it
would have to be a cast, eg,

  c = cast C(d)

--lars


Reply | Threaded
Open this post in threaded view
|

Re: questions on nullability

Lars T Hansen
(redacted) writes:
 > [hidden email] writes:
 > > The entire reason that the class definition can be annotated is to
 > > make it easier for the programmer not to have to worry about null when
 > > using classes for which a null value does not make sense.  The
 > > canonical example is "Complex": this is usually viewed as a "value
 > > type", ie, it does not normally make sense to have Complex values that
 > > can be null.
 >
 > Isn't there then an argument for adding a syntax to provide a default value
 > in place of null, much as int or Number are defaulted to 0?

That would not prevent you from later assigning null to a variable of
that type, though, or pass null to a function taking that type.

The intent of the non-nullability proposal is to be able to add
annotations to the program that guarantee that that sort of thing will
not happen, and that null-pointer exceptions won't be thrown.  It goes
beyond creating sensible non-null default values.

There has been rather a lot of discussion about whether default values
could be provided for non-nullable variables; the discussion page for
the proposal records some.  In practice default values are fraught
with issues, not the least because you'll want default values to have
"value semantics": to be either read-only or copy-on-write.

--lars

(CC'ing the discussion list even though I received the reply
privately; it's of general interest.  Sender's name redacted.)

 > Just a stab at
 > the syntax here but, to use your Complex example:
 >
 > public class Complex extends Object = new Complex (0,0) {
 >      //
 > }
 >
 >
 > public class Complex
 >     extends Object
 >     default new Complex(0,0)
 > {
 >      //
 > }
 >
 > This would be far more useful than simply banning null. I would expect the
 > statement defining the default value could be made up from any static
 > methods or compile-time constants.


Reply | Threaded
Open this post in threaded view
|

Re: questions on nullability

Peter Hall-2
(redacted) writes:
> [hidden email] writes:
> > The entire reason that the class definition can be annotated is to
> > make it easier for the programmer not to have to worry about null when
> > using classes for which a null value does not make sense.  The
> > canonical example is "Complex": this is usually viewed as a "value
> > type", ie, it does not normally make sense to have Complex values that
> > can be null.
>
> Isn't there then an argument for adding a syntax to provide a default value
> in place of null, much as int or Number are defaulted to 0?

That would not prevent you from later assigning null to a variable of
that type, though, or pass null to a function taking that type.


It would if null was automatically converted to this default value, as happens with int.
 

The intent of the non-nullability proposal is to be able to add
annotations to the program that guarantee that that sort of thing will
not happen, and that null-pointer exceptions won't be thrown.  It goes
beyond creating sensible non-null default values.


Yes, I wasn't suggesting  default values as a direct replacement to non-nullable annotations. But, I think default values is much better solution to the specific Complex example. In fact, I think default values would tackle most of the reasons why you'd want to annotate a class declaration as non-nullable.

However, you introduce other problems when performing explicit coercions between types and the non-nullable version. In these situations, if you end up pushing the resolution to run-time, yielding coercion errors (and possibly null-pointer exceptions if "as" operator is used) non-nullability hasn't really achieved it's objective..


There has been rather a lot of discussion about whether default values
could be provided for non-nullable variables; the discussion page for
the proposal records some.  In practice default values are fraught
with issues, not the least because you'll want default values to have
"value semantics": to be either read-only or copy-on-write.

Ok. I missed that. I'll check out the discussion pages.


--lars

(CC'ing the discussion list even though I received the reply
privately; it's of general interest.  Sender's name redacted.)


oops.  most of the lists I subscribe to have reply-to as the list itself.


> Just a stab at
> the syntax here but, to use your Complex example:
>
> public class Complex extends Object = new Complex (0,0) {
>      //
> }
>
>
> public class Complex
>     extends Object
>     default new Complex(0,0)
> {
>      //
> }
>
> This would be far more useful than simply banning null. I would expect the
> statement defining the default value could be made up from any static
> methods or compile-time constants.

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

Reply | Threaded
Open this post in threaded view
|

Re: questions on nullability

P T Withington-3
In reply to this post by Burak Emir
> From: Lars T Hansen <[hidden email]>
> Date: 15 June 2006 05:26:57 EDT
[...]
> The entire reason that the class definition can be annotated is to
> make it easier for the programmer not to have to worry about null when
> using classes for which a null value does not make sense.

Hi Lars,

Just curious why the default is to permit null.  Seems to me that it  
is more common for it _not_ to make sense for a type to include the  
null value.  Is it just that that would be too great a departure from  
Javascript 1?

[Just getting up to speed on this project, great to see you on it!]

P T Withington

OpenLazslo.ORG                       <http://www.openlaszlo.org>
mailto:[hidden email]      skype:ptwithy     aim:[hidden email]












Reply | Threaded
Open this post in threaded view
|

Re: questions on nullability

Lars T Hansen
On Thu, 15 Jun 2006 21:31:58 +0200, P T Withington <[hidden email]> wrote:

>> From: Lars T Hansen <[hidden email]>
>> Date: 15 June 2006 05:26:57 EDT
> [...]
>> The entire reason that the class definition can be annotated is to
>> make it easier for the programmer not to have to worry about null when
>> using classes for which a null value does not make sense.
>
> Hi Lars,
>
> Just curious why the default is to permit null.  Seems to me that it
> is more common for it _not_ to make sense for a type to include the
> null value.  Is it just that that would be too great a departure from
> Javascript 1?
>
> [Just getting up to speed on this project, great to see you on it!]

Hi Tucker,

backwards compatibility is probably constraining us here, though classes
are new in 4th Edition so it's possible that non-nullable could be the
default for class instances.  In practice I suspect it may be confusing,
and I also suspect that most object structures are recursive in some way
and will want nullable types.  But I don't recall it being discussed.

--lars

Reply | Threaded
Open this post in threaded view
|

RE: questions on nullability

Jeff Dyer
Lars T Hansen wrote:

> But I don't recall it being discussed.

It was discussed briefly. Two reasons mentioned were compatibility with
existing implementations (e.g. AS3) and expectations of users familiar
with mainstream object oriented languages.

Jd

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Lars T Hansen
Sent: Thursday, June 15, 2006 2:05 PM
To: P T Withington
Cc: [hidden email]
Subject: Re: questions on nullability

On Thu, 15 Jun 2006 21:31:58 +0200, P T Withington <[hidden email]>
wrote:

>> From: Lars T Hansen <[hidden email]>
>> Date: 15 June 2006 05:26:57 EDT
> [...]
>> The entire reason that the class definition can be annotated is to
>> make it easier for the programmer not to have to worry about null
when

>> using classes for which a null value does not make sense.
>
> Hi Lars,
>
> Just curious why the default is to permit null.  Seems to me that it
> is more common for it _not_ to make sense for a type to include the
> null value.  Is it just that that would be too great a departure from
> Javascript 1?
>
> [Just getting up to speed on this project, great to see you on it!]

Hi Tucker,

backwards compatibility is probably constraining us here, though classes
are new in 4th Edition so it's possible that non-nullable could be the
default for class instances.  In practice I suspect it may be confusing,
and I also suspect that most object structures are recursive in some way
and will want nullable types.  But I don't recall it being discussed.

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss


Reply | Threaded
Open this post in threaded view
|

Re: questions on nullability

Dave Herman-2
>> But I don't recall it being discussed.
>
> It was discussed briefly. Two reasons mentioned were compatibility with
> existing implementations (e.g. AS3) and expectations of users familiar
> with mainstream object oriented languages.

A synopsis of some of the discussion is in the wiki at:

     http://developer.mozilla.org/es4/discussion/nullability.html

under "Defaults".

Dave

Reply | Threaded
Open this post in threaded view
|

Re: questions on nullability

Peter Hall-2
In reply to this post by Peter Hall-2
At the risk of being tangential, is there any value in generalising the nullability concept into a pseudo type, which may be defined as the union of some set of types, with a further set of types removed?

Re-using the + and - operators, it could be something like:

function add(a:(Number+Complex-Null), b:(Number+Complex-Null)):Complex{
  if(a is Number){
     a = new Complex(a, 0);
  }
  return a.add(b);
}

or

const ComplexOrReal = (Number+Complex-Null);
function add(a:ComplexOrReal, b:ComplexOrReal):Complex{
  if(a is Number){
     a = new Complex(a, 0);
  }
  return a.add(b);
}

Most examples that I could think of could also be accomplished with method overloading. But it seems like a feature that might be simpler to implement than overloading. Method return types would probably have to be disallowed from using one of these types though.

Peter


On 6/15/06, Peter Hall <[hidden email]> wrote:
(redacted) writes:
> [hidden email] writes:
> > The entire reason that the class definition can be annotated is to
> > make it easier for the programmer not to have to worry about null when
> > using classes for which a null value does not make sense.  The
> > canonical example is "Complex": this is usually viewed as a "value
> > type", ie, it does not normally make sense to have Complex values that
> > can be null.
>
> Isn't there then an argument for adding a syntax to provide a default value
> in place of null, much as int or Number are defaulted to 0?

That would not prevent you from later assigning null to a variable of
that type, though, or pass null to a function taking that type.



Reply | Threaded
Open this post in threaded view
|

Re: questions on nullability

Nicolas Cannasse
> At the risk of being tangential, is there any value in generalising the
> nullability concept into a pseudo type, which may be defined as the
> union of some set of types, with a further set of types removed?
>
> Re-using the + and - operators, it could be something like:
>
> function add(a:(Number+Complex-Null), b:(Number+Complex-Null)):Complex{
>   if(a is Number){
>      a = new Complex(a, 0);
>   }
>   return a.add(b);
> }

As far as I know, "null" is a value, not a type.

Nicolas

Reply | Threaded
Open this post in threaded view
|

Re: questions on nullability

Peter Hall-2
It is (see http://developer.mozilla.org/es4/spec/chapter_6_types.html), but I don't know if the type Null (as opposed to value null) is addressable. It isn't in AS3. Since the Null type has only one member, there are currently no occasions where you would need it.

Peter


On 6/16/06, Nicolas Cannasse <[hidden email]> wrote:
> At the risk of being tangential, is there any value in generalising the

> nullability concept into a pseudo type, which may be defined as the
> union of some set of types, with a further set of types removed?
>
> Re-using the + and - operators, it could be something like:
>
> function add(a:(Number+Complex-Null), b:(Number+Complex-Null)):Complex{
>   if(a is Number){
>      a = new Complex(a, 0);
>   }
>   return a.add(b);
> }

As far as I know, "null" is a value, not a type.

Nicolas

Reply | Threaded
Open this post in threaded view
|

Re: questions on nullability

Nicolas Cannasse
> It is (see http://developer.mozilla.org/es4/spec/chapter_6_types.html),
> but I don't know if the type Null (as opposed to value null) is
> addressable. It isn't in AS3. Since the Null type has only one member,
> there are currently no occasions where you would need it.
>
> Peter

The docs say "A type is a set of values" so I guess they're talking
about runtime types there. Types at compilation have a different
meaning. In particular, nullity should be threated more like a
constraint than a separate type since it can be toggled.

ML-style languages for instance encode nullity by using an "option type".

type option<T> = Null | Value : T

Null is option<*>
Value(0) is option<Int>
Value("") is option<String>

In order to extract the value from an option, you have to check it
first, for example by using pattern matching :

var x = Value(0);
match x {
Null -> // handle null
Value(n) -> // n is the Number
}

With this kind of technics, it's waranty that there will *never* be any
kind of null pointer exception.

Traditionaly OO language are using "null" a lot more, in particular
because they don't enforce variable initialization upon declaration. So
it's more often that we see null or not-null contraints in OO.

There are more infos there :
http://developer.mozilla.org/es4/proposals/nullability.html

Nicolas