When I wrote the first post about types in neptune I ran out of steam before I was completely finished. In this post I’ll finish by describing two features I only mentioned briefly in the first post, the void type and protocol literals.
Checks
But first: as Isaac points out, I’ve spent a lot of time explaining what the type system doesn’t do and doesn’t require, and very little explaining what it actually does do for you. I guess I didn’t think to write about it because the checks that are performed are pretty simple and conventional. Here’s a summary of the checks performed by the compiler.
- If you call a method m and the type system knows that the receiver has a type that doesn’t define the method m, the checker will issue a warning:
protocol Runnable {
run();
}
Runnable action = ...;
action.runn(); // warning: undefined method Runnable.runn()
- If the type checker knows the signature of a method and you pass it an argument with an incompatible type, a warning will be issued:
int gcd(int a, int b) { ... }
gcd("foo", "bar"); // warning: incompatible types
I’ll return to what “incompatible” means in a second.
- If a value is assigned to a variable of type T, a warning is issued if the type of that value is not a subtype of T:
int x = "4"; // warning: incompatible assignment
- When returning a value from a method with return type T, the returned value must be a subtype of T.
int foo() {
return "bar"; // warning: incompatible return type
}
As a special case of this rule which I’ll return to later, returning a value from a void method is illegal, and not returning a value from a non-void method is illegal.
- Finally, the compiler checks that methods override each other properly. An overriding method is allowed to return a subtype of the overridden method (return type covariance) and it is allowed to take arguments that are supertypes of the arguments of the overridden method (argument contravariance):
class SuperClass {
Object foo(int x) { ... }
}
class SubClass: SuperClass {
Object foo(String x) { ... } // incompatible override
int foo(Object x) { ... } // legal
}
There may be more checks that I’ve forgotten but at least these are the most important ones. All but one of these checks use the subtype relation between two types which is simple in neptune: The type X is a subtype of Y they are equal, if Y is a class that extends X, directly or indirectly, or if Y implements the protocol of X, again directly or indirectly. It’s a simple version of the nominal typing relation of many other object-oriented languages, including Java and C#, except that it is more general because one class can be a subtype another class without having that class as a superclass.
Besides these checks, the compiler also issues warnings if it thinks a class has not been properly implemented: if non-abstract classes have abstract methods, if a class doesn’t provide all the methods required by the traits it uses, if it declares that a method overrides another but it doesn’t, etc. However, all those things could be checked even if there was no static type system.
I hope that clarifies what the type system will do for you, and then move on to describing the two last features of the type system.
Void
In most languages, methods that don’t return a meaningful value are treated differently than other methods. In the C language family, such functions and methods are declared as if they did return a value of type void, but the void type is special and magical; what it really means is that the function don’t return a value at all. In particular, there is no value of type void and you can’t declare a variable of that type:
void do_nothing() { }
void my_void = do_nothing(); // illegal
Void methods and functions in the C languages are fundamentally different from functions and methods that return values and the type system keeps track of whether or not you’re allowed to use the result of a call. In neptune we can’t do that because you are free to call a method even if the type system knows nothing whatsoever about it. So we couldn’t use the C model, at least not directly.
In smalltalk, on the other hand, there is no such thing as a method that doesn’t return a value. You are free to not explicitly return a value from a method, but in that case the method returns self. I don’t consider that to be a particularly good design and long before we considered switching from smalltalk to another language we experimented with changing this in OSVM. The problem is that many methods really aren’t intended to return a meaningful value but return self by default. Then someone accidentally uses this value and then later when the method is changed, under the assumption that no one is using the return value, the program breaks somewhere completely unexpected. The problem is that the intention of the method isn’t clear because sometimes methods really do intend to return self but you can’t tell if this is the case since the return isn’t written explicitly. Personally, I used the convention that if I wanted a method to return a value I would always explicitly return it, even self. If I didn’t want the method to return a meaningful value, I would return nil.
In neptune, we wanted a combo solution: all methods should return a value but we also wanted to avoid the problems from smalltalk and we wanted the code to look like C. The solution was to make void into a real type and introduce a void value. All methods that don’t explicitly return a value automatically return the void value, and a return statement without an explicit value also returns the void value. The void value itself is a full, real object just like null:
void get_void_value() {
return;
}
var void_value = get_void_value();
System.out.println(void_value.to_string()); // prints "void"
This model gives you almost the same behavior as C, Java and co. but for different reasons. If you declare that a method returns void the type system will warn you if you return a value of another type, since the returned value is not a subtype of void. If a method is declared to return something other than void but don’t return a value, the type check fails because a method that doesn’t explicitly return is made to return the void value which is not a subtype of the return type. Finally, if the void value ever turns up as the value of a variable or somewhere else where you don’t expect it you’ll know that there is a problem.
This model does give a little more flexibility, some of it is probably useless (but you never know) and some of it is slightly useful. First of all, since void is a regular type you can declare variables of type void. I don’t know why you would do that but you can. Secondly, it is legal to explicitly return a value from a void method if that value is the void value. That might not sound useful but it can be since it means that you can call another method and return in the same statement:
void add(var obj) {
if (delegate) return target.add(obj);
...
}
In java, you can’t call a void method and return in the same statement so you would have to write
void add(Object obj) {
if (delegate) {
target.add(obj);
return;
}
...
}
It’s a small thing but it does give greater uniformity. By the way, I believe you can actually do the same thing in C++.
Of course, having a dynamic representation of the “nothing” value is not a new thing, many languages have that. My experience with it, at least in the context of this kind of language, is that it works very well in practice and better than any of the alternatives I’ve tried.
Protocol literals
The last thing is sort of an oddball. Sometimes it can be practical to represent a type as a run-time value. For instance, in our unit test framework we have a method that asserts that running a particular piece of code throws a particular exception
assert_throws(IOException.protocol, fun -> file.open());
The expression IOException.protocol gives you an object that represents the protocol IOException. A protocol object can be used for exactly one thing: to test whether other objects implement the protocol it represents:
Protocol p = String.protocol;
var x = "Beige";
if (p.is_supported_by(x)) ...
That may not sound very exciting but it can be useful in combination with other abstractions that are built on protocol objects, for instance exception handling. In a post a long time ago I mentioned that in neptune, an exception handler such as this:
try {
...
} catch (e: IOException) {
...
}
is expanded into this:
fun {
...
}.try_catch(
new Vector { IOException.protocol },
fun (Exception e) {
...
}
)
Exception handling is based on the try_catch method which uses a list of protocol literals to decide whether or not it catches a particular exception. The fact that you can call this method directly means that you can make exception handlers that are not statically bound to a particular exception type but where it can be determined dynamically which exceptions to catch. This is how assert_throws is implemented:
void assert_throws(Protocol type, fun f) {
fun {
f();
fail_not_thrown(type);
}.try_catch(new Vector { type }, fun {
// Ignore exceptions of the right type
});
}
It’s not something you use often but on those rare occasions where you do use it it’s really handy.
