In Defense Of “Name : Type”

A big (really *the* big) syntactic departure that Gosu took from Java is around type declarations. In Java, you have the time-honored c-style of declaration: type, followed by name:

  public String aMethod(String aParameter) {
    String theString = "The String " + aParameter;
    return theString;

In Gosu, you have the name first, followed by a colon, then the type:

  function aMethod(aParameter : String ) : String {
    var theString : String = "The String " + aParameter
    return theString

(Note that you would typically omit the local variable’s type in Gosu and let type inference do its thing.)

This syntax comes down to us from Pascal and is the standard in ECMAScript, which is the language Scott originally based Gosu on.

Now, this is just syntax. Not really a big deal, right?

Turns out, in practice, this actually is kind of a big deal to people. Let me quote Stephen Colebourne:

@Carson, thanks for writing about Gosu. The feature literal element looks good, and fits my view of how such things should work with # for the meta level. Unfortunately, Gosu declares variables as name : type, which makes it rather unappealing to me. Fix that, and I might take a real look at the language…

Despite the fact that Gosu has everything that Stephen wants with respect to properties, he won’t take a real look at the language because of the syntax around types. So this obviously is a big deal to Stephen, and I can’t say I blame him: as Oscar Wilde said, only a very shallow person does not judge by appearances.

So, while admitting that it will look a little strange the first time to Java developers, let me try to give a small defense of the Gosu type syntax.

First off, I think that the Gosu syntax reads more naturally once you get used to it. Taking the example method above, reading it left to right in Java gives:

“Returning a String, the method ‘aMethod’ takes a String called ‘aParameter'”

In Gosu you have:

“The function ‘aMethod’ takes ‘aParameter’ of type String and returns a String”

I believe that most english speakers would find the latter a more natural way to explain the method. This is subjective of course, but, hey, we are talking about syntax here.

A less subjective advantage of Gosu’s syntax becomes apparent when you look at generic methods.

Consider this example:

   <T> T aGenericMethod(T aParameter) {
    return aParameter;

Note that in Java the generic type variable must be declared first, off in space, so that it can precede the return type of the method, which could (but need not) contain a reference to the type variable.

In Gosu, this is expressed much more naturally:

   function aGenericMethod<T>(aParameter : T) : T {
    return aParameter

Because the return type of the method comes at the end, the type variable can nestle comfortably after the name of the function. As a bonus, this is much closer to the syntax of generic classes, with the type variable following the name, rather than preceding it.

This has ramifications at the call site, as well. In Java, you must prefix the function call with a type if you want to give an explicit parameterization:

  anObject.<String>aGenericMethod( "Yay generics!" );

In Gosu, again, you use a more natural syntax:

  anObject.aGenericMethod<String>( "Yay generics!" )

Note how similar this is to the syntax used for class parameterization (e.g. ArrayList<String>).

As an interesting corner case, in Java you simply can’t invoke a parameterized generic method without a preceding expression:

  <String>aGenericMethod( "Yikes" );

will not compile, whereas this will:

  this.<String>aGenericMethod( "Hmmm" );

Gosu, on the other hand, has no such restriction, since the method parameterization comes comfortably after the method name:

  aGenericMethod<String>( "It just works" );

Now, these are admittedly fairly small advantages. But, nonetheless, they are advantages. I hope that outlining them will convince some of you who are skeptical about the “name : Type” syntax to look more deeply at Gosu: it is a very nice language with some interesting features. (Not the least, the Open Type System, which Scott wrote about here.)

7 Comments on “In Defense Of “Name : Type””

  1. Jesse Wilson says:

    As a Java developer whose company (relatively) recently started investing in the Guidewire platform (the complete suite at that), these posts concerning Gosu have been a wonderful look into the underlying language.

    I’ve become a big fan of the language and most of the departures from Java (and the like) that the Gosu language has taken. This particular one has to be one of my favorites.

    Now if I could only use Gosu in more places.

  2. soren says:

    Here’s Rob Pike on the subject

    And Herb Sutter thinks D should have gone to the left to right syntax… and that he’d like C++ to go that way in the future. (first 10 minutes of this)

    • Carson Gross says:

      Thanks for the links. “name : Type” sure seems to be the syntax that is winning out in the new generation of languages.

      I’m surprised Go makes some of the syntax optional. I don’t much like optional syntax: I’d prefer that there is one way to do it in the name of consistency.

  3. Stephen Colebourne says:

    Thanks for writing up your thoughts. I’m afraid the generics argument doesn’t win me over. The code

    T aGenericMethod(T aParameter)

    should in my world be

    T aGenericMethod(T aParameter)

    My example above is perfectly complete in terms of available information, but not used because we tend to write parser-led languages.

    To be clear, I could probably get used to Name:Type in parameters (even though I dislike it). But I just cannot get used to Method(Params) : ReturnType. Having the return type after the method declaration is crazily unreadable to me.

  4. Stephen Colebourne says:

    Grrr, it ate the braces. The two example were:

    [T] T aGenericMethod(T aParameter)

    T aGenericMethod[T](T aParameter)

    • Carson Gross says:

      Well, I tried my best.

      I should know better than to try to convince an englishman to use another language, eh? 😉

    • Hannes Petri, Sweden says:

      I haven’t used Gosu in practice yet, so I don’t know for sure, but I imagine this is less of a problem in Gosu’s case as its type system allows for extensive documentation generation. As Gosu doesn’t use header files, you probably won’t be skimming through raw code for methods, but rather generated documents, in which the return type may be laid out arbitrarily (preferably to the left of the method name.)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s