Archive

Archive for the ‘D Programming Language’ Category

My Article On D Published

November 4th, 2007 No comments

An article I wrote for Sweden’s biggest computer magazine, Datormagazin, was published in the november issue. It’s an introduction to D, and I guess it’s the first time D gets mentioned in Swedish computer press.

Categories: D Programming Language Tags:

D got real closures

November 3rd, 2007 No comments

Thank you Vladimir for bringing this to my attention.

I have reported on this blog that D doesn’t have real closures. My opinion was that it didn’t matter all that much, but many people thought otherwise. Now it seems like D got it after all. The latest release of the experimental 2.0 version announce full closure support.

It would be interesting to know if the implementation is based on the solution that Julio César outlined in his blog reaction. Not that it matters.

Cheers!

Categories: D Programming Language Tags:

I’m back!

October 28th, 2007 No comments

I’m back from my three week vacation!

I had a great time, but as suspected I wasn’t able to stay away from computers. In the warm evenings, just for fun, I started to implement a ray tracer in the D Programming Language.

I have been looking for a suitable project that would give me a chance to get deep into D, and a ray tracer seems to be the perfect fit. D is supposed to be great at floating point programming and now I have the chance to find out on my own.

To make it a little more interesting I have used a more top-down breath-first kind of approach than I normally do. I want to see how that affects a test-driven development technique. As a part of the experiment I keep a detailed development log which I plan to share with you when I reach a certain point. It could be within a week or take several months depending on work load and inspiration level.

So stay tuned. I’ll be back with ray tracing, or other topics that comes across my sphere of interest.

Cheers!

Donkey Patching

September 13th, 2007 4 comments

According to this slide show, the team behind D is thinking of incorporating an interesting addition to the language: The interchangability of a.foo(b) and foo(a, b).

This makes some interesting uses available. For instance, one could do something that looks a bit like monkey patching, adding functionality to library classes.

real round_to(real n, uint d) {
  real b = 10;
  real k = pow(b, d);
  return round(n*k)/k;
}

With the proposed change I could use the round_to function like this:

real a = 9.4334566;
real b = a.round_to(2); // => 9.43

I would also be able to do this:

int next(int a) {
  return a + 1;
}

int b = 3.next; // => 4

And while we’re at it:

void times(int n, void delegate() dg) {
  while(n\-\- > 0) {
    dg();
  }
}

5.times({
  writefln("Look at me. I'm Ruby!");
});

Of course this isn’t really monkey patching. The functions doesn’t actually become a part of the class, and thus cannot use polymorphism or access private members. In all respect this is just syntactic sugar, but I like it. It gives you the illusion of having a dynamic language.

I haven’t seen this particular feature in any other language before. Does it exist elsewhere? Does it have a name? If not, I think Donkey Patching would be a suitable one.

Cheers! 🙂

Categories: D Programming Language, programming Tags:

Should D have real closures?

September 13th, 2007 No comments

It has been a vivid debate following my D doesn’t have real closures post. For most parts it has been a constructive discussion, but what I wanted to see was real examples that would convince me that real closures (those that carry the environment with them) were actually useful for a language that provides other means of object oriented programming.

One reason for my skepticism was an interview with Ruby’s creator Yukihiro Matsumoto, made by Bill Venners. There Mr Matsumoto says this about having the context captured: “it’s not that useful in the daily lives of programmers”. Here is the statement in context:

Bill Venners: OK, but what is the benefit of having the context? The distinction that makes Ruby’s closure a real closure is that it captures the context, the local variables and so on. What benefit do I get from having the context in addition to the code that I don’t get by just being able to pass a chunk of code around as an object?

Yukihiro Matsumoto: Actually, to tell the truth, the first reason is to respect the history of Lisp. Lisp provided real closures, and I wanted to follow that.

Bill Venners: One difference I can see is that data is actually shared between the closure objects and the method. I imagine I could always pass any needed context data into a regular, non-closure, block as parameters, but then the block would just have a copy of the context, not the real thing. It’s not sharing the context. Sharing is what’s going on in a closure that’s different from a plain old function object.

Yukihiro Matsumoto: Yes, and that sharing allows you to do some interesting code demos, but I think it’s not that useful in the daily lives of programmers. It doesn’t matter that much. The plain copy, like it’s done in Java’s inner classes for example, works in most cases. But in Ruby closures, I wanted to respect the Lisp culture.

Today I read a blog post from Julio César who’s arguing for incorporating real closures in D. He’s providing real examples and his case feels strong. Also, he points to an alternative way of implementing it that doesn’t look too complicated.

Categories: D Programming Language, programming Tags:

D doesn’t have real closures

September 11th, 2007 12 comments

Note: This article was written before D got full closure support.

Delegates are something that gives me mixed feelings. While I used to embrace them in Delphi and Object Pascal, I now find them difficult to get used to in C#. I guess that is because they introduce a little of the functional programming paradigm into an otherwise object oriented environment.

Don’t get me wrong, I do find delegates powerful and I use them whenever I see fit. It’s just that they bug me, like a badly-pitched note in an otherwise perfect chord. In that respect I am much more fond of the inner classes of Java.

The D Programming Language, my favorite pet at the moment, has support for both delegates and inner classes, thus providing the best of both worlds. And since D is a multi paradigm language with support for functional programming, its delegates are justified.

The semantics of D delegates are somewhat different from that of C#. For instance, C# delegates may bind to both static and non-static methods, while D may bind to non-static methods only. But on the other hand, D delegates may also bind to inner functions, which makes them look a lot like closures.

bool retry(int times, bool delegate() dg)
{
  int tries = 0;
  while (tries++ < times) {
    if(dg())
      return true;
  }
  return false;
}

// Example usage
retry(3, {
  writefln("Password: ");
  char[] buf = readln();
  return (buf == "secretn");
});

In order to be a real closure a delegate is required to keep variables that are bound from the surrounding environment alive, even if the program has left their scope. For example, consider the following program.

int delegate() countdown(int from)
{
  int current = from;
  int countdown_helper() {
    return current\-\-;
  }

  return &countdown_helper;
}

int delegate() dg = countdown(10);
dg(); // should return 10;
dg(); // should return 9;
dg(); // should return 8;

The countdown function returns a delegate that refers to the inner function countdown_helper. Counter_helper binds the variable current from it’s parent by returning its value and decreasing it by one.

So, if D’s delegates were real closures the first invocation of the delegate in the above example should return 10, the second 9, followed by 8, 7, and so on. But in reality they produce bogus values like 4202601 or 4202588. The reason is this: D doesn’t implement real closures. The variable current is invalid because the program is no longer executing the countdown function when countdown_helper is invoked via the delegate.

So D doesn’t have real closures, is that a big deal? No! In my opinion real closures are not important for languages that are not pure functional. The creators of D shouldn’t waste their resources on this feature since it brings little value but lots of implementation complexity. The energy is better spent on features like multicast delegates. Those would bring value in the form of convenience, and I hope future versions of D will incorporate them.

Complete versions of the code samples in this post can be found here and here.

Is the Contract Programming of D broken?

August 29th, 2007 No comments

In my previous post I mentioned that I wasn’t sure of how the D Contract Programming feature works in an override scenario. Wekempf inspired me to delve deeper into the matter. Here is what I found.

Contract Programming states that preconditions may be weakened by a deriving class, but never hardened. For postconditions the reverse is true: they may be hardened but never weakened.

The D Programming Language specification states:

“If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied.”

In my experience this isn’t the case. Consider the following code:

class A {
  void f(int a)
  in { assert(a > 0); }
  out {}
  body {}
}

class B: A {
  void f(int a)
  in { assert(a > 1); }
  out {}
  body {}
}

Method B.f overrides the corresponding method in A. If B.f is invoked with an argument of 1, the in-clause of B.f should fail and A.f succeed. According to the specification only one of the two needs to be satisfied. Let’s see if that’s true.

A o = new B;
o.f(1);

The program halts with a contract failure in B.f. The preconditions of the base class is never even checked.

What happens if I add a call to the base class method?

class B: A {
  void f(int a)
  in { assert(a > 1); }
  out {}
  body { super.f(a);}
}

It turns out that the super-call triggers the in-clause of the base class A (and only that one). It seems like the semantics differs from the statement in the specification. The current behavior opens up for abuse of the general principles of Contract Programming by allowing preconditions to be hardened and postconditions to be loosened.

I don’t care all that much though. To me it seems difficult to have the language enforce those rules anyway, at least while keeping the contracts flexible. And, the current behavior is what I’d expect if I wasn’t aware of the Design by Contract principles.

Update: It turned out that this feature is currently not implemented in the DMD compiler.

Contract Programming in D

August 27th, 2007 4 comments

If you are a defensive programmer like me, you make heavy use of assertions to guard assumption you make in your code. For example, a method for adding an order item to an order object could look something like this:

class Order
{
  private List orders;

  int addItem(OrderItem item)
  {
    assert(assigned(item));
    item.order = this;
    assert(assigned(items));
    items.add(item);
    assert(items.count > 0);
    return items.count;
  }
}

This style of programming adds some clutter to the code, but makes the program more robust and reliable over time.

The D Programming Language have built in support for contract programming and I have been curios to see if that can be an alternative to my defensive programming style. At first look it seems to be a close match. Both techniques allow you to make safe assumptions in business logic code. The difference is where you put your defensive code.

In contract programming, or Design by Contract as it was originally called, there are the concepts of pre- and postconditions, conditions that are expected to be met on the entrance to and on the exit from methods. Additionally you have the concept of class invariants, which asserts a certain state before and after (but not during) a method call.

So, a transformed contract programming version of my defensive style example above could look something like this:

class Order
{
  private List orders;

  invariant { assert(assigned(items); }

  int addItem(OrderItem item)
  in { assert(assigned(item)); }
  out {assert(items.count > 0);}
  body
  {
    item.order = this;
    items.add(item);
    return items.count;
  }
}

This may not seem like less clutter but it does two important things: First it separates the defensive code from the business logic. Pre- and postconditions are neatly placed in in- and out-blocks, while business logic dwells in the body-block.
Secondly, general assertions that may need to be checked in every method of the object (like checking that the orders list in the above example is assigned), are handled in in place: the invariant block. Nice and DRY.

It seems like I could use Contract Programming for the same purposes as the normal defensive programming technique, but there are a couple of issues that keep me from taking the step:

  1. I’m not sure how preconditions and postconditions are affected in an override scenario. The language specification says that preconditions are OR’ed together, meaning that if one precondition passes the others are ignored. My own tests show a different behavior, but I need to take a closer look to be sure.
  2. Contract Programming and Normal Defensive programming are conceptually two very different things: Contract Programming, like the name suggests, are taking place in between the programming interfaces of objects, while the assertion defensive style is more general. You can say that Contract Programming defends the Program Design against abuse, while the defensive programming style defends the implementation against unexpected events.
  3. Contract Programming moves the defensive code away from the code that benefits from its protection. This could become a maintaining problem.

I currently feel that Contract Programming should be used only in the context for which it was created: big projects with many developers, where a massive (not agile) design phase precedes an equally massive phase of implementation. But, I’ll probably use class invariants to DRY up my general asserts where applicable.

Is D:s floating point handling too advanced?

August 23rd, 2007 3 comments

The floating point support in the D Programming Language is more advanced than that of standard C and C++. I’m not sure I like every aspect of it though. The thing I’m having problem with is how D handles the special value NAN (Not A Value).

For instance, a simple comparison will always return false if one or both of it’s operands are uninitialized (having the value of NAN). This produces the following unintuitive behavior:

if (real.nan != real.nan)
{
  writefln("It's strange, but you'll always see this text!");
}

I can see the reason why they chose the always-fail-if-NAN semantics for the other comparison operators, but not for equal-to and not-equal-to. In this case I think they went too far in their strive for consistency.

The consequence of the D floating point semantics is this: If you want to assert that a float value is initialized, for example in an invariant block, this won’t work:

class SomeClass {
  real someFieldVar;

  invariant {
    assert(someFieldVar != real.nan) {...}
  }

}

Neither will this:

assert(someFieldVar);

As a side note, if the value of someFieldVar is zero, the above expression would evaluate to false! This is why I never use non-boolean expressions where true or false are expected. I think that should be prohibited by the language.

Anyway, you have two options when checking for an uninitialized value. Neither is – in my humble opinion – particularly beautiful.

First, you could use one of the new NAN-aware binary operators that D introduces, like !<>=, !<, !>=, or !<>. These new operators just give me a headache, they don’t come naturally and I can’t seem to learn them. Here’s the best way I found to check for the uninitialized value using the new floating point operators:

assert(0 !<>= value);

That operator returns true if one or both operands are uninitialized. I don’t feel comfortable with that solution. It’s not obvious what the code does. In that sense, the only remaining alternative is better: using the std.math.isnan function.

import std.math;
:
assert(isnan(someFieldVar));

This is okay, but it feels a little clumsy and backwards using a function. It would have been much better if Walter Bright had used the more intuitive semantics for the normal equality operator. So that I didn’t have to depend upon the std.math namespace, and could write:

assert(someFieldVar != real.nan);

or even better, added a property to the floating point value:

assert(someFieldVar.isnan);
Categories: D Programming Language, programming Tags:

Agile low level programming in D

August 21st, 2007 2 comments

Agile software development techniques have long been utopia for low level system developers. The C programming language has been the most reasonable choice for implementing hardware near applications and drivers; But C was not designed with agility in mind. Hence methods like test driven development has been a pain to implement using C.

Now an alternative exists: The D Programming Language is designed to combine the low level programming abilities and performance of languages like C and C++, with the productivity features of modern languages.

You could describe D as C with features like object oriented programming, exception handling, garbage collection and design by contract. Cool agile features indeed, but D has another one that I instantly fell in love with: built in support for unit testing.

In D you can declare unittest blocks.

unittest {
  assert(sometest, "sometest failed");
}

The unittest construct makes it very easy to practice test-driven development. For instance, lets say we want to create a new type for three dimensional vectors. In order to be test-driven we need to start with the test:

unittest {
  Vector3 v;
}

We compile the program using the -unittest switch.

dmd -unittest test.d

Of course we get a compiler error, Vector3 is still undefined. Lets define it.

struct Vector3 {
}

This time the program compiles. Back to the unittest. Now let’s try a simple assignment.

unittest {
  Vector3 v = Vector3(1.0, 2.0, 3.0);
}

This, again, produces a compile time error. Vector3 doesn’t have the x, y and z fields, so we implement them.

struct Vector3 {
  real x, y, z;
}

The code passes compilation. Next step: implement vector addition. We start with the test.

unittest {
  Vector3 v1 = Vector3(1, 2, 3);
  Vector3 v2 = Vector3(3, 2, 1);
  Vector3 vr = v1 + v2;
}

As we expect, the code doesn’t compile. We need to overload the + operator.

struct Vector3 {
  real x, y, z;

  // Overload + operator
  Vector3 opAdd(Vector3 a)
  {
    return Vector3(0, 0, 0);
  }
}

Now the program compiles, but we don’t know if the add operator produces the right result (which it doesn’t with the current code). To check the result we can use assert.

unittest {
  Vector3 v1 = Vector3(1, 2, 3);
  Vector3 v2 = Vector3(3, 2, 1);
  Vector3 vr = v1 + v2;

  assert(vr.x == 4);
  assert(vr.y == 4);
  assert(vr.z == 4);
}

We compile, and it compiles without error. To run the unittest code we simply run the program. Unittest code is executed after program initialization, but before the main function. If a unittest fails the program terminates prematurely. Our program terminates (as expected) with an AssertError. Lets correct the add operator.

struct Vector3 {
  real x, y, z;

  Vector3 opAdd(Vector3 a)
  {
    return Vector3(x + a.x, y + a.y, z + a.z);
  }
}

It compiles and runs without errors. Great!

As you can see, test-driven development is a very smooth and simple process in D. There is no need for a separate framework, just compile and run your application. Also, the test code dwells close to the production code, which makes it easier to maintain and keep up-to-date. In fact, you can put unittest blocks anywhere in your code, even within the piece of code you are testing.

struct Vector3 {
  real x, y, z;

  // unittest blocks are allowed
  // within structs.
  unittest { ... }
}

Any type of code is allowed within a unittest block. This means that you can declare functions to do repetitive tasks.

unittest {
  function assertEqual(Vector3 a, Vector3 b)
  {
    assert(a.x == b.x);
    assert(a.y == b.y);
    assert(a.z == b.z);
  }

  Vector3 v1 = Vector3(1, 2, 3);
  Vector3 v2 = Vector3(3, 2, 1);

  assertEqual(v1 + v2, Vector3(4, 4, 4));
  assertEqual(v1 - v2, Vector3(2, 0, -2));
}

The test code is only included in the executable if it is compiled with the unittest flag, so there’s no need for a separate test project or conditional compilation. This is a very clean solution, highly suitable for a traditional language that compiles directly to machine code. Although I’m a big fan of testing framworks such as JUnit, I find it much easier to work with the built in unit testing features of D. Of course you don’t have advanced features like mock object support, but I guess that will be offered soon with some kind of unittest-based framework add-on.

If you have doubts about the foundation of the D Programming Language, you should be relieved to hear that it’s been designed by Walter Bright, who have spent almost a lifetime constructing C and C++ compilers.

You’ll find the complete code within my code sample pages.