Dashboard > Mantra > ... > Types > Type annotations
  Mantra Log In | Sign Up   View a printable version of the current page.  
  Type annotations
Added by Terence Parr, last edited by Terence Parr on Nov 03, 2007  (view change)
Labels: 
(None)

Mantra is not a statically typed language like Java, though you'll see types specified in the code. These types are annotations kind of like "executable documentation". For example how many times have you done this in other dynamically typed languages like Ruby and Python:

# a is an int and f returns a list with ...
f(a):
	...

Mantra integrates such informal type information into the code like a statically typed language, but that information does not affect the validity of the statements in Mantra methods in any way. Mantra uses dynamic typing. "string s = 34;" compiles fine in mantra. The type information can be used to generate pre-and post-conditions that validate incoming and outgoing objects, relieving the programmer of that burden. The type information can also be used for optimization. See my parrt:Mantra coming along (speed test vs Python) blog post about Mantra speed.

To read code and to use code, you the programmer must know the type of every expression and variable. That is simply what programming is about. Dynamically typed languages feel easier to program in simply because you're not having to convince the compiler all the time that you know what you're doing. Most of the time you do not have a type issue and a pedantic compiler is unnecessarily painful.

There are two situations in statically typed languages where you must specify a type: at declaration sites and expressions where the compiler thinks you might be making a type of mistake (the compiler wants a typecasts before it shuts up). Is very easy at the declaration site to specify the type and extremely useful from a readability point of view. I don't think many people would argue with the value of the following declarations:

class User {
      string name;
      int id;
      list jobs;

      assign(job j) {...}
}

The types are fast and easy to specify and dramatically improve the readability of the code. Field id could just as easily be a string instead of an integer; without type information you have to compute the type by looking at the method bodies. I argue that declarations are not a burden and are very useful.

The hassle with statically typed languages appears when the compiler thinks you might be making a mistake. The most obvious case was the use of collections before generics in Java:

// must typecast; get() returns an object
String name = (String)names.get(0);

You must still declare type information for local variables, but again that information is only used for optimization and readability. For the price of documenting your code better, mantra gives you a faster program.

Naturally a "lint"-like program could use the type information to warn you about possible type issues in your code. Editors can use the type information to provide an accurate list of the available methods for a particular variable. Doing so now in Ruby and Python is very difficult and often not possible.

As for as language design is concerned, type annotations disambiguate local variable definitions from field references. Given the following assignment,

a = 0;

it's not clear whether the programmer intends that to be a new local variable or a field. Python and Ruby solve this by forcing the programmer to use special notation to access fields versus locals. If a is a field of the surrounding class, Python requires self.a and Ruby requires @a. I suppose in Mantra you could do this.a everywhere as some people like to do in Java. Thanks to the type annotation, a declaration of a local is obvious both to the reader and to the compiler:

class {
    int a;
    foo() {
        a = 3;	   // access the field
	int b = 4; // declare a new local
    }
}

The other issue I take with Ruby and Python is that they do not specifically and obviously declare the fields of each class. Instead, the constructor simply performs assignments to initialize these instance variables. From a readability point of view, I much prefer seeing a nice list of type fields at the top of my class. I do not want to look into all of the constructors to figure out the superset of all fields created by these constructors.

Dynamic typing is supposed to reduce work, but it often causes more work when you have to mentally compute a lot of type information--information that is obvious in statically typed programs. Mantra's type annotations provide the readability (and much of the speed) of a statically typed language with the programming ease of a dynamically typed language.

Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.1 Build:#806 May 06, 2007) - Bug/feature request - Contact Administrators