The philosophy of Nothing

Reinier Zwitserloot reinier at zwitserloot.com
Sun Nov 29 13:50:27 PST 2009


What neal meant was, anytime the compiler must reason about elements by way
of that elements' type, it can reason with safety that any element of type
'Nothing' must clearly be a subtype of everything, and can thus be an
acceptable thing in place of any other type.

In practice, of course, there are no instances of Nothing. it's a compiler
crutch* which helps mark off boundaries where there is nothing but the
compiler doesn't know about it.

Here's a simple hypothetical example:

public ? doSomething() {
    while (true);
}

There's no point in writing a return statement in this method. It would be
dead code. I could make it return 'void', but my intention is to use this
somewhere as a pluggable 'do nothing, forever, except suck down CPU cycles'
closure, so being able to fill the return type with something would be
useful. What type should it return?

"Nothing", of course.

A bit more useful: What does this method return?

public ? doSomething() {
    throw new RuntimeException();
}


This is where Nothing shines: By having a Nothing type, we can tell the
compiler that, well, literally, _nothing_ will be returned. When I call
doSomething() from other code, all java has is the signature of this method.
It doesn't know that the method will never return normally and always exit
with a RuntimeException. By making the return type of doSomething()
"Nothing", we let the compiler know that:

Q something = doSomething();

is always legal, regardless of Q. It makes doSomething more generic (as in:
more generally usable. If doSomething returned "Object", for example, I
could NOT pass it into a List<String>'s add method!

Going even further:

List<? extends Number> list;

list.add(methodCall());

What kind of return type would be legal here for methodCall()? There's no
current type that works; Lists of the form ? extends X cannot be added to.
But if methodCall never actually returns, then - this would be 'safe' in
that the add method never even fires. Nothing lets us tell the type system
that all will be well, in a type safe manner.

Also, as there can be no instances of Nothing, if you declare that your
method returns Nothing, then the compiler will flag an error on every return
statement in it. You are FORCED to actually never return from this thing,
so, basically, loop endlessly, or throw something.

Pragmatically speaking, java isn't functional and doesn't always NEED to
return something. We have void. Thus, 'throw' is a statement and not an
expression (because if it was, surely the type of a throw expression would
be Nothing), System.exit() returns void, etcetera. Hence why java doesn't
have a Nothing right now. Languages like haskell and scala have had it since
day 1. With generics, java is moving a bit closer to that world.

Type-wise, it might help to clearly define what a return type means. It does
NOT mean:

"This method returns a value that is a T".

What it actually means is:

"This method will not return something which is not a T."

That's because not returning at all (not halting) is always an option. The
halting problem says that no type system in the world can verify that you
actually return something (that you halt). Well, not in turing complete
languages, which java certainly is. Thus, all it can verify is that you NOT
return something which is NOT a T.

Finally, on the semantics of the word "Nothing" - it's just a word. It was
chosen because of precedent; Scala uses it. If you want to know WHY Nothing
was chosen, ask Martin Odersky. Or, look at the pragmatic usage, as in the
examples I've used here. "Nothing" seems to work out kinda nice:

public Nothing throwMe(RuntimeException t) {
    throw t;
}


What does that method return? Answer: Nothing - it never returns (normally).


*) Perhaps crutch is the wrong word. Give me some leeway while I explain
this :)

--Reinier Zwitserloot



On Sun, Nov 29, 2009 at 10:06 PM, Paul Benedict <pbenedict at apache.org>wrote:

> Neal, can clarify this:
>
> > There are no elements of the type Nothing. Therefore all of the elements
> > of the type Nothing are elements of the type T, for every T.
>
> The first statement says there are no elements, but the second says
> there are elements.
>
> Paul
>
> On Sun, Nov 29, 2009 at 2:57 PM, Neal Gafter <neal at gafter.com> wrote:
> > On Sun, Nov 29, 2009 at 12:33 PM, Paul Benedict <pbenedict at apache.org>
> > wrote:
> >>
> >> Yes, I do have it flipped around. Thank you. I shouldn't enjoy making
> >> big blunders in public so much. :-)
> >>
> >> So let me ask the opposite:
> >> How can nothing be a type of something?
> >
> > A type T is a subtype of a type S iff all of the elements of the type T
> are
> > elements of the type S.
> >
> > For example, String is a subtype of Object because all of the elements of
> > the type String are elements of the type Object.
> >
> > There are no elements of the type Nothing.  Therefore all of the elements
> of
> > the type Nothing are elements of the type T, for every T.  Therefore
> Nothing
> > is a subtype of the type T, for every T.
> >
> > Cheers,
> > Neal
> >
>
>



More information about the coin-dev mailing list