The rewrite will solve lots of problems and reduce dependencies on other software: I’m getting rid of Gtk and won’t require Libxml at enduser’s machines anymore. SDL is a new dependency, though.

The output quality doesn’t come close to what I got with Cairo, at least not with the naive approach I tried. Maybe I did something wrong. I know it can be solved because Qt, Amanith and various other libraries can render pretty SVG graphics using OpenGL. Maybe they use fragment shaders or some other technique that’s too advanced for someone who started with OpenGL just a few days ago. I’ll get there eventually, but right now I plan to use Cairo to render textures that I can map to rectangles with OpenGL. That should give me both quality and speed, at the cost of texture memory.

The partial rewrite means I won’t have a prototype to show at the end of the summer as I had hoped, but once it’s done I should have a much better foundation and be able to work faster than before. Working with the new code base is already more fun, which may be enough to increase my output after the rewrite, since it could mean I end up putting more hours into the project.

TinyClos is a minimal implementation in Scheme of Common Lisp’s object system CLOS. CLOS is different in many ways from the object systems of C++ and Java that most of us are familiar with. Two big differences are multiple dispatch and open classes.

Before I explain what multiple dispatch is I must explain what dispatch refers to. When you make a function call in any language, the compiler or language runtime must figure out which function the call refers to. This is called binding the function to an implementation. In some languages binding always occurs at compile time, in others always at runtime, and in still others sometimes at runtime and sometimes at compile time.

Some languages, such as C++, allow you to declare many functions with the same name as long as they have different parameter lists. Not only the name of the function but also the number of arguments and their types are used when binding. This is called overloading in C++ terminology. However, overloading is a compile-time mechanism, and as such only looks at the static types of the arguments. If you want to bind the call based on the run-time type of an object you have to make the function virtual.

However, virtual functions in C++ (and most other mainstream languages) only take the run-time type of the first parameter into account–the “this” pointer. This is called single dispatch, because it dispatches the call based on a single argument. As you can probably guess by now, multiple dispatch is when the run-time types of multiple arguments is used for binding. In other words, multiple dispatch is like overloading but with run-time types.

This is immensely useful in some situations, because you can decide what to do based on combinations of types, without having to sprinkle your code with instance-of tests or resorting to ugly work-arounds like the visitor pattern. For instance, to express that anti-aircraft units can attack air units but not tanks or other units types, I just specify a method can-fire-at? for the type combination (AirDefenseUnit, AirUnit) and another one for (AirDefenseUnit, Unit). The method with the most specific matching argument list will be selected, at run time.

Here’s another simple example in the syntax Bjarne Stroustrup wants for C++ (not included in the coming update of the standard):

bool canShareHex(virtual Unit u1, virtual Unit u2) {
  return true;
}
bool canShareHex(virtual GroundUnit u1, virtual GroundUnit u2) {
  return false;
}
bool canShareHex(virtual AirUnit u1, virtual AirUnit u2) {
  return false;
}
bool canShareHex(virtual SeaUnit u1, virtual SeaUnit u2) {
  return false;
}

In other words, GroundUnits can share hex with all units but other GroundUnits. This example also demonstrates the other feature I wanted to write about: open class extensions. As you can see above, the methods were not part of a class but added separately. This too is very useful, because you can’t always anticipate what people may want to do with your classes, and sometimes it’s impractical to cram everything into one class.

For example, let’s say you are writing a compiler and define classes for different kinds of expressions, like addition and multiplication and so on, reflecting the tree structure of arithmetic expressions. Since the set of operations (optimizations) you may want to perform on the tree is open ended, you wouldn’t want to make them all methods of the tree classes. It would be much cleaner to define each optimization separately, while still dispatching on the actual run-time type(s) of the tree nodes.

With Scheme, I could just download TinyClos and start using these features. They can be compiled efficiently too, though I’m not sure they are in Chicken. Knowing that it can be solved should the need arise is reassuring, though.

Further reading:

• An efficient implementation of open multimethods for C++: www.research.att.com/~bs/multimethods.pdf
• Multijava, a version of Java extended with multiple dispatch: ftp://ftp.cs.iastate.edu/pub/techreports/TR04-01/TR.pdf

Scheme is not like other languages. In a way, Scheme is not really one language, but a foundation for defining other languages. The semantics of Scheme were designed to enable programmers to devise their own control structures and the syntax was minimized to make it easy to parse, modify and layer your own syntax on top of. The language as a whole left so many other things unspecified that you must build your own environment on top of it unless you’re working on a small project.

One example of the power Scheme gives its users is unlimited continuations. A continuation is a point in the execution of a program which has been lifted up to the language layer, where it can be passed around or saved in variables, letting you execute it again later should you want to. That was pretty abstract so I’ll give you an example:

As you may know, functions in C programs push their return address on a stack before they are invoked. When a function returns, it pops the return address from the top of the stack and jumps to that address, which is where the call came from. The return address is the continuation of the caller (I’m simplifying here), but it doesn’t exist as a first-class entitiy in the C language, so we cannot see it or refer to it. In Scheme you can. Moreover, you can call a continuation as many times as you wish, and you can ask for the current continuation at any point, not just at call sites.

This is not terribly useful in day-to-day coding, but it is essential if you want to make your own language. Using continuations, you can implement exception-handling mechanisms like try-catch without resorting to low-level hackery (and things like loops with complicated exit logic and light-weight threads, too).

What all this comes down to is that Scheme is a very good environment for language experimentation, which has resulted in a lot of people hacking on these kinds of things. Consequently, you can go to the web page of your Scheme environment and download language extensions others have written that add or alter fundamental parts of the language; They may for instance add object-oriented constructs and run-time dispatch. Mainstream languages are much less malleable.

In summary, I think the ability to download language extensions and, so to speak, assemble my own language from pieces written by others has been a huge advantage. That, and the ability to make changes to the program as it’s running has been more than enough to justify the hassle.

I’m not sure exactly what the scenario will be, but something like an attack on Denmark with Sweden getting drawn in. The south of Sweden was pretty much undefended (we had prepared for the war between the Soviet Union and Finland to spread to the north of Sweden, not for war with Germany), but the Swedish navy could probably have helped the Danes a bit.

I haven’t done much programming this weekend, but I experimented some more with the Antlr parser generator. I can now recognize field access expressions like foo.bar.baz and transform them into (slot-ref (slot-ref foo ‘bar) ‘baz). I detest having to type all that garbage just to access some fields, so anything that can rid me of that is welcome even if it means writing a preprocessor. More about that later. I’ll need to work more on it before I have something that can be used.

The lines and dots in the fields are all vector data.. Maybe I should use bitmap textures for these things instead? I’m completely inexperienced with vector graphics design work, so I don’t know how people usually handle this kind of stuff.

I also added shadows underneath the tanks, to place them more firmly onto the ground.

In short, this change makes animation a requirement, and not just a feature that would be nice to have. I probably won’t take care of that right now, though.

To make this work I need to decouple the request for an action from actually performing the action, so that other units get a chance to intercept. When the user tries to attack an enemy unit, I now send an attack request to an arbiter object running in another (lightweight) thread. The arbiter asks enemy units nearby if they want to counter the action, and schedules the resulting actions. The schedule is then executed and the results broadcasted to everyone who can see them.

These changes not only enable automatic reactions; They also bring me closer to having networked play and fog of war (the inability to see all the enemy’s units).

Actually, I started thinking about similar problems months earlier when I was writing new code that gradually became much more complicated than I had expected. Why did I end up in a morass of special cases and conditions?

Both problems involved updating the state of several different data structures that had to be kept synchronized. The basic problem was that changes to the data were spread out over many different functions and that early changes could invalidate later changes or affect the control flow in an undesired way by changing the outcome of a conditional branch.

When I was working on the first problem I was writing new code and had free hands when it came to design. After realizing I would have to scrap my first design to make further progress, I decided I would partition the problem into two distinct parts: One would figure out which changes needed to be made and encode them in a class called a ChangeSet; The other would apply the changes. The idea was that it would be easier to debug and understand the algorithm if you could print out the ChangeSet and check invariants before it was applied. This worked well and simplified the code enough that I was able to make progress again.

The other problem had another important ingredient: randomness. The iteration order of several central datastructures (such as sets) is random in our system (a side effect of our generational garbage collector’s decisions) and caused the (very large) algorithm to update the data structures in a different order from one run to another. Most of the time everything worked fine, but every now and then things failed with random symptoms.

It has slowly dawned on me that these two problems were essentially the same: Many changes had to be made to many different data structures, and those very changes could cause the algorithm to trip itself up.

My solution to the first problem (using a ChangeSet) worked well not only because it made following the changes easier, but also because it concentrated all state changes to one phase, letting the first part of the algorithm discover what needed to be done in a temporarily immutable world. I think there is an important and general principle here: Changes to mutable state should be confined to as few points in both space and time as possible. This goes for any language with mutable state. Object-oriented principles do not seem to cover this problem, since hiding the state inside a class does not make the state go away; It is just changed via a method instead.

An interesting parallel is that the solution I described above is similar to what database systems do with transactions, and databases are specialized on managing mutable state in unpredictable environments.