Monthly Archives: March 2006

Argh, this whole “neptune looks like C#” thing is self-perpetuating. After we first noticed the similarities between the languages I looked into C# a bit more, and having that at the back of my head as we’re discussing the language only paves the way for new C#-like constructs and so the hideous circle continues.

Example. And this is where smalltalk programmers should look away or at least read the disclaimer before continuing. The example is about synchronization and locking. In java, all objects can be used as monitors and you usually guard a critical section by synchronizing on some object:

final Object lock = ...;
synchronized (lock) {
  // critical section
}

That’s pretty readable even though it’s somewhat warped that all objects can be used as monitors. But that’s beside the point. In smalltalk it’s even neater since you can use blocks and so don’t need a special synchronized statement, you can just call a method on a Monitor or Mutex:

mutex acquireDuring: [
  // critical section
].

In neptune, being derived from smalltalk, we also have blocks (they’re called functions) and until recently we used the exact same technique as smalltalk for synchronization:

Mutex mutex = ...;
mutex.acquire_during(fun {
  // critical section
});

Yeah I know, it doesn’t look very good. It’s exactly the same as in smalltalk except that method calls are written as mutex.acquire_during(...) and that the block syntax has changed into fun { ... }.

It turns out that you use acquire_during all over the place so we really want a more concise syntax. The idea is to add a special purpose syntax for acquiring a resource, for instance a mutex or a file, in a particular scope that makes sure the resource is released properly. It’s an old idea we’ve had floating around but it never really got anywhere because we couldn’t find the right syntax.

This afternoon we ended up discussing this problem again and it seems like we finally have a strawman: the using statement:

Mutex mutex = ...;
using (mutex) {
  // critical section
}

C# programmers will find this very familiar — C# has a construct with a very similar purpose and a very similar syntax. It is important, though, to point out that we haven’t taken the whole construct from C#, only the name of the keyword. But that’s a pretty important part of the construct.

As with all out shorthands, the using statement is just syntactic sugar for a simpler construct, in this case a method call:

mutex.using(fun {
  // critical section
});

Any object is free to implement the using operator so it’s a much more general construct than synchronized in Java. A using statement can also define variables, for instance when acquiring a resource produces a result:

File my_file = ...;
using (InputStream stream : my_file) {
  // read file
}

Will this be a popular statement? I think that probably depends on how we use it in the libraries. But that goes for most of the language constructs, if we don’t use them in the libraries they probably won’t be used by others either. We’ll see.

Disclaimer: I cannot be held responsible for any discomfort felt by smalltalkers while reading this post. To a smalltalk programmer the following probably seems like utter insanity since smalltalk already has a great solution to the problem in this example, and the people who are designing this language are all smalltalk programmers. I’m trying to find the courage to write a post about why we’re moving away from smalltalk and I’m not quite there yet.

Ted Neward compares a handful of different languages (Java, C#, VB, Scala and Ruby) with respect to how much code it takes to express a simple person concept:

A Person has a first name, a last name, and a spouse. Persons always have a first and last name, but may not have a spouse. Persons know how to say hi, by introducing themselves and their spouse.

Of course, I couldn’t help but compare it with neptune which (sigh of relief) compares favorably:

class Person {

  readable String first_name, last_name;
  readable Person spouse;

  Person(String -> first_name, String -> last_name,
    Person -> spouse = null);

  String to_string() {
    if (spouse==null) return "Hi, my name is ${first_name} ${last_name}";
    else return "Hi, my name is ${first_name} ${last_name}"
      ", and this is my spouse ${spouse.first_name} ${spouse.last_name}";
  }

}

Personally, I think that is more readable than both scala and ruby but of course I’m biased. Here’s a short run through of what’s going on in this code.

The modifier readable means that the field is given a read accessor. So instead of writing

readable String first_name;

you would get the exact same result if you wrote

String first_name;

String accessor first_name {
  return first_name;
}

In the Person class above, unlike C, C++ and Java, spouse.first_name does not just read the field first_name in spouse directly but calls the read accessor called first_name. In neptune, hidden or no modifier defines a field but doesn’t create accessors, readable gives it a read accessor, writable gives it a write accessor and visible gives it both ¹.

The Person “method” is the constructor. The arrow notation means “assign this argument directly into the specified field” and the = null specifies a default value for a parameter (as in C++). The constructor above could be written alternatively as the following, which is completely equivalent but, I think, a lot less clear:

Person(String _first_name, String _last_name, Person _spouse) {
  first_name = _first_name;
  last_name = _last_name;
  spouse = _spouse;
}

Person(String _first_name, String _last_name) {
  this(_first_name, _last_name, null);
}

If you want to go completely nuts you can even expand the constructors into two static new operators and an instance initializer. And once you’ve done that it’s pretty easy to see that basic neptune is almost just smalltalk with a warped syntax. But I digress…

By the way, if you’re not into the whole type thing you’re free to leave out the types

class Person {

  readable var first_name, last_name, spouse;

  Person(-> first_name, -> last_name, -> spouse = null);

  to_string() {
    if (spouse==null) return "Hi, my name is ${first_name} ${last_name}";
    else return "Hi, my name is ${first_name} ${last_name}"
      ", and this is my spouse ${spouse.first_name} ${spouse.last_name};
  }

}

[1]: Why didn’t we use public and private instead of visible and hidden? Well, our modifiers mean something different from Java or C++’s do in almost all positions where they occur. We thought that it was important to avoid misleading people by emphasizing the similarities, which I think we would have if we had used public and private, and instead emphasize the differences by choosing completely different keywords.

Pretty early on in the development of the neptune language we noticed that if you want syntax coloring when editing neptune source in editors that didn’t know about the language, a syntax coloring mode for C# is usually the closest approximation. That may not be a coincidence: I don’t actually know C# very well, I don’t think anyone in our group do, but for some reason neptune has drifted in C#’s direction.

Amazingly, the C# also seems to be drifting towards neptune: the new C# 3.0 spec describes the new constructs in C# 3.0 and a few of them are very similar to constructs in neptune.

One new construct in C# 3.0 is implicitly typed local variables. For instance, you can write

var i = 5;
var s = "Hello";

and the compiler will infer the variable types for you from the initializer and understand the code above as if you had written

int i = 5;
string s = "Hello";

In neptune you can also declare variables without specifying the type, using the exact same syntax:

var i = 5;
var s = "Hello";

In neptune, however, the type is not inferred but left undefined — neptune has optional typing and you are always free to leave out the types. So where this is illegal in C#:

var x = 5;
x = "Hello";

since x is inferred to be an integer, it is perfectly legal in neptune. You are also free to leave out the initializer in neptune, since we don’t need it to infer the type as they do in C#. So the constructs are a little different when you look closely but still pretty similar.

Another new construct in C# 3.0 is collection initializers. You can now write

new List<int> { 1, 2, 3, 4, 5 }

which gives creates a new list containing the five specified numbers. In neptune you can do exactly the same (except that we don’t have generic types) and, again, with exactly the same syntax:

new Vector { 1, 2, 3, 4, 5 }

Not only do the two constructs have the same syntax, the coding convention used in the spec is the exact same as I use in my code: a space after the class name, before the first element and after the last.

There is a subtle difference in what the code means in C# and neptune, but it makes almost no difference in how the constructs works, only how efficiently it can be implemented. In C# the expression above is implemented by adding the elements to the list:

List<int> list = new List();
list.Add(1);
list.Add(2);
list.Add(3);
list.Add(4);
list.Add(5);

In neptune collections have a special collection constructor and the elements are given to the collection constructor in a special “primitive” collection:

var raw_elements = #{1, 2, 3, 4, 5} // "magic" primitive collection
Vector.new{}(raw_elements)

Our model has the advantage that we can optimize the allocation of the primitive collections which can often be pre-allocated and, if necessary, placed in ROM on small devices. It also means that collections are given all the elements at once and are hence free to implement new{} in smart ways. In C#, new List<int> { 1, 2, ..., 1000 } must be implemented using 1000 .Adds, whereas new Vector { 1, 2, ..., 1000 } in neptune can be implemented extremely efficiently no matter how many elements are added. (How? By using the primitive collection as a backing store and using copy-on-write if the vector is modified. And you can be much smarter than that if performance is an issue).

Unlike C#, this syntax can also be used to initialize mappings in neptune:

new TreeMap { 1 -> "one", 2 -> "two" }

On the other hand, C# allows this syntax to be used to initialize arbitrary objects:

new Point { X = 12, Y = 16 }

Considering that we knew nothing of these constructs in C# and the C# people of course didn’t know what we were doing (the spec came out before we even started working on neptune) it’s interesting how alike they are. I’m optimistic take it as a sign that maybe we’ve hit a design that will feel natural for people used to C-like languages.

For the technically minded, Ted Neward writes about the gory details of the new C# features. For an overview of all the new features a good place to look is the Code Post.