Supervisor: David Watt
Java is a statically-typed OO language. This means that type checks are performed at compile-time, in an attempt to ensure that object code can never fail with a type error. Any code that might fail with a type error will be rejected by the compiler.
Actually, a downcast such as:
Object o
= ...; String s;
...
s = (String)o;
might fail at run-time, and arguably that is a type error.
Static typing sometimes forces us to write clumsy code, e.g.:
Object o = "abc";
String s;
...
s = (String)o;
If the downcast were omitted in this code, the assignment would be rejected as a compile-time type error, although it would not fail at run-time.
Now consider instance method calls, e.g.:
Object o = "abc"; int i;
...
i = ((String)o).length();
Again, if the downcast were omitted in this code, the method call would be rejected as a compile-time type error, although it would not fail at run-time.
Worse still, suppose that not only String but also some other class, say Cord, independently defines a length() method. Now we must write the clumsy code:
Object o = "abc"; int i;
...
if (o instanceof String) i = ((String)o).length();
else if (o instanceof
Cord) i = ((Cord)o).length();
to avoid a compile-time type error.
A flexibly-typed language would have weaker type rules than a statically-typed language. The compiler would reject only code that must fail with a type error. If the code might fail with a type error, the compiler would merely issue a warning (and generate a run-time type check). For example, the assignment "s = o" would get away with a warning, as would the method call "l = o.length()". The advantages of flexible typing would be to make program code more concise and flexible.
The aim of this project is to implement and evaluate a flexibly-typed OO language. One possible approach would be to obtain an existing Java compiler and modify it to implement a flexibly-typed Java dialect. Another possible approach would be to design and implement a small flexibly-typed OO language from scratch.