Accepting null means tightly marrying the memory layout and types together. You can no longer examine types while ignoring how they’re layouted in the memory.
Huh? Nullable doesn’t say anything about memory. I have no idea what Python None looks like.
Python’s None is a globally defined constant. Nullable and Maybe are sum types. You’re right that these ideas are distanced from how they’re layouted into memory.
However I’m not sure what to do here because I think the thought still applies somehow to this. Should we have an easy way to convert any type into type+{null} in the first place?
I think he was referring to his conception of it as stated in this opening: “Not too long ago I used to think of null as an useful feature that can be directly derived from the pointer arithmetic on a computer.”
I believe null values are essential. Consider the following Java class, for which null is prohibited:
class Weird {
Weird x;
}
What would the value of x be, if it were not null? Clearly, it must be an inhabitant. Thus, every reference type has also null as inhabitant, to allow these cyclic definitions.
Suppose, you get rid of null and instead declare a particular global variable that is the “default” instance. Then, consider this:
How do you construct such a default value, if the constructor takes an instance as reference? That would only be possible if you consider object references for which constructors are not completed. That might give you an even bigger mess than null.
In any case, dealing with cyclic structures is not easy. If not null, there must be other trade-offs to be made, such as uninitialized objects.
I very well understand what you mean. However, if you introduce null for this reason then you cannot use your types to prove that you have completely instantiated structures that behave properly.
Though in Java you already have other features that ensure types do not have the meaning they should hold. This was the reason why I advised to not bother if the language already has null in it.
Oh, in Java you can observe fields that haven’t been assigned yet (even final fields!). Weird! Given that, maybe null is essential in Java.
Some languages don’t really have constructors in the Java sense. To create an instance, you have to supply an initial value for each field before you get back a reference to the new instance. This means you never have uninitialized fields, but it also means creating cycles is more difficult. (That can be nice though: you can look at a type and immediately know there are no cycles.)
If you wanted to design a language without null, but with Java-style constructors, maybe you could add more restrictions. For example, maybe the constructor has to call super and initialize every field before it’s allowed to refer to this.
Huh? Nullable doesn’t say anything about memory. I have no idea what Python None looks like.
Python’s None is a globally defined constant. Nullable and Maybe are sum types. You’re right that these ideas are distanced from how they’re layouted into memory.
However I’m not sure what to do here because I think the thought still applies somehow to this. Should we have an easy way to convert any
typeintotype+{null}in the first place?I think he was referring to his conception of it as stated in this opening: “Not too long ago I used to think of null as an useful feature that can be directly derived from the pointer arithmetic on a computer.”
I believe null values are essential. Consider the following Java class, for which null is prohibited:
class Weird { Weird x; }
What would the value of x be, if it were not null? Clearly, it must be an inhabitant. Thus, every reference type has also null as inhabitant, to allow these cyclic definitions.
Suppose, you get rid of null and instead declare a particular global variable that is the “default” instance. Then, consider this:
class Weird2 { Weird2(Weird2 x) {} } default Weird2 = ???
How do you construct such a default value, if the constructor takes an instance as reference? That would only be possible if you consider object references for which constructors are not completed. That might give you an even bigger mess than null.
In any case, dealing with cyclic structures is not easy. If not null, there must be other trade-offs to be made, such as uninitialized objects.
I very well understand what you mean. However, if you introduce null for this reason then you cannot use your types to prove that you have completely instantiated structures that behave properly.
Though in Java you already have other features that ensure types do not have the meaning they should hold. This was the reason why I advised to not bother if the language already has null in it.
Or requiring all object definitions have default values for things
Oh, in Java you can observe fields that haven’t been assigned yet (even final fields!). Weird! Given that, maybe null is essential in Java.
Some languages don’t really have constructors in the Java sense. To create an instance, you have to supply an initial value for each field before you get back a reference to the new instance. This means you never have uninitialized fields, but it also means creating cycles is more difficult. (That can be nice though: you can look at a type and immediately know there are no cycles.)
If you wanted to design a language without null, but with Java-style constructors, maybe you could add more restrictions. For example, maybe the constructor has to call super and initialize every field before it’s allowed to refer to
this.