A Lexical Mistake

This project is no longer in development.

Of all the programming languages I’m proficient in, not even Haskell is so curiously fun and exciting (in my mind) as the Smalltalk programming language. See the idea behind Smalltalk is deceptively simple, you have objects, which you send messages to. Those messages are handled by methods and finally, both messages and objects may maintain and carry references to other objects. This may just sound like any other object-oriented programming language, but all of this happens at run-time, including the creation of those methods, objects and classes!

Given my affinity for computer games, it’s not surprising then, that I’ve been eyeing off the usage of some dialect of Smalltalk for programming computer games. Even the performance of Smalltalk is competitive compared to many other high level programming languages. Since most high level game code is easier to program with the increased flexibility scripting/dynamic languages provide Smalltalk has always seemed to me, to be a very attractive counterpart to a C/C++ engine.

The same principle could also be applied to the Lua programming language, which is extraordinarily popular in game development right now, which is more or less designed to be attached to an engine written in the standard engine languages, C and C++.

As I pointed out in my last post, originally I only intended to create a game engine in Haskell, which could then help when developing games or frameworks dealing with the high level game code. But to make this easier I decided to put the conventional game development wisdom to good use, and add to the mix a scripting language instead. Also relevant are Haskell’s concurrency capabilities which, I believe, are drawing the most attention from more mainstream game developers.

A Counterpart To Haskell

It might be interesting to note that, in the early design of Fire, the language wasn’t actually going to be based on Smalltalk or any language specifically, rather, I was working out some of the design points to help in taking advantage of Haskell’s concurrency and functional programming capabilities. Eventually I came up with a basic features list along the lines of object-oriented, semi-functional, highly concurrent and prototype based (class-less).

While collecting my thoughts and trying to understand which kinds of syntax would be appropriate I noticed that regardless of which syntax I used, the language would have to almost completely separate the concept of mutable state from the objects themselves, allowing only the use of transaction variables. While I could technically have gone with almost any syntax from there, it’s a pretty sure thing that regardless of the syntax used, Fire was going to be a somewhat unfamiliar thing to work with. This is where Smalltalk syntax lends itself, not being difficult to adapt and extend, while also known for being easy to learn and unusually expressive.

There were some issues to deal with however. To start with, Smalltalk syntax isn’t technically a full language syntax, but only provides the syntax for method definitions. By proxy, the construction of objects and message sends is achieved, with a fair bit of help from the development environment (UI). It also helps to point out that image based languages are notoriously difficult to bootstrap, while many game developers these days use text based VCS anyway, it was obvious I would first have to invent the missing syntax.

After (admittedly) more than a few attempts, and the larger part of a notebook full of musings and hypothetical example code, I finally had a complete syntax and at least most of the basic semantics in mind. The resulting syntax now includes a module level notation, an object literal notation, there is a simplified notation for creating lists and everything else is a consequence of sending messages, as expected.

Difficulties

There are some issues in combining any object-oriented language with functional programming or concurrency. To make things simpler, and because Fire is designed for game development anyway, I’ve kept the basic semantics imperative, or more succinctly the language still has the conventional IO semantics of Smalltalk. The main differences, at this point, are the lack of mutable variables within the language itself (beyond TVars) and the extensive use of threads (asynchronous messages).

To make working with transaction variables easier, Fire does provides properties, implemented as objects responding to a ‘get’/’set:’ property protocol, and a property method syntax which maps a method pair (’var’/'var:’) to another object implementing the property protocol. Any object could theoretically be used here including IORef based objects, but that would generally risk concurrency issues and would probably be a bad idea. This is of course, alongside the usual method definition syntax, and a syntax for creating simply immutable variables, which is syntactic sugar for unary methods.

For those who have worked with Smalltalk, it’s immediately obvious that the main strength of the design has actually been lost however. That it, the main strength of Smalltalk has always been, at some level, the development environment itself. For those not familiar, the built in development tools allow any object, class or method to be reworked at any point while a program is running, even in the debugger. When developing an application, this level of flexibility is essential to the velocity a Smalltalk programmer can work at.

Such a development environment is probably going to be the most difficult thing to replicate in Fire, since both the UI frameworks as well as the tools themselves must be created from scratch. The VM will also likely require a way to allow programmers to ignore the immutability restrictions.

Luckily I do have something along the lines of a plan. What I believe will do the trick here is a simple dual mode VM, allowing (through the reflection layer) the modification of objects, while the finished games will use a release mode, preventing objects from being accidently scrambled. This solves both the development environment concerns, while keeping the language concurrency safe and hopefully simpler to integrate into the Haskell based engine. As as for the UI, I’ll get to that in a later post…

Clearly there’s a lot of stuff going on here, but for now, most of the work will focus on simply getting the spec written and the VM functioning. After then I can start moving only some of the details like the engine itself, and the libraries on either side of the language bridge. Actually, there’s the language bridge too, for that matter.

The purpose of this post is really just to give some idea of the reasoning behind a couple of the high level design choices used in Fire. There are plenty of other topics to consider yet, just at the language level, for example, prototypes systems are even more convention based than Smalltalk since the entire class system is replaced simply by methods for cloning and modifying the definition of objects. In any case, I think it should be interesting to see Smalltalk finally being applied to some serious game development, especially paired up to Haskell as well.

– Lorenz

Ok, by now we all know that Object Oriented programming is likely to go the way of Erlang, or at least inherit an Actor model of language level concurrency.

In fact, I’ve even got an object system that I’m planning to implement just to find out how well this style of concurrency works in an Object Oriented programming language. The design of the language is even more post-Self/Slate than Newspeak (although I believe that this language will just complement the Smalltalk family of languages in all honesty).

Well then, Haskell…Haskell is actually very interesting, in this case by being one of the very few to push the limits of locking methods for concurrency rather than using the larger granularity involved in processes and message passing (not by much, but its still something).

The problem is that its impossible to write locking code by hand that doesn’t have at least one race condition hiding away in the corner. Not the ones you’ve already tested for, but the ones that would cause transactions to restart…like multiple threads locking a few items and then deadlocking…or even just managing the code required to restart deadlocks…yeah…lol…

Haskell provides a novel approach (its actually pretty old now, but it’s really only just starting to catch on, outside of Haskell anyway)… Software Transactional Memory.

STM is sometimes used in other areas of computing (OODBs, et ceteral), but the real gem here is that the Haskell type system nicely compartmentalized the side effects involved into a clever transaction form, within our imperative outer program. This makes working with transactions very much like the database stuff, only we’re only working with individual variables, so no complex table lookups.

Anyway, enough of my rambling, check it out:
Programming in the Age of Concurrency Software Transactional Memory

And if you haven’t already, remember to look at Erlang too…after all concurrency isn’t going away, and there are only two ways to get it right!

– Lorenz

I’ve been mulling over my old game development hobby for a little while now, and after messing around with Python a little I noticed that once again, there seems to be very little in the way of promising concurrent game object level languages floating around. At least languages that I’m aware of.

What I’m talking about exactly is game languages which allow the game objects themselves to participate in concurrent programming practices, without using intricate and complex locking sequences, or losing the right to talk directly to engine/library level services like physics or high-level game state (moving between the level and a menu for example).

Instead, almost all game level languages at the moment seem to be evangelizing the importance of being script level uncompiled beasts that require little to no real programming experience before becoming a productive member of the game code team!?

Of course I’m not saying that this is an inherently bad practice with the current level of technology floating around, but I do have to wonder whether this is still relevant for small team game development in the near multi-core parallelism future. Perhaps too far, but I think also relevant is the much slower pace of Open Source Game Development, which realistically speaking needs technology almost 3 years ahead of its time just to break even on an initial 1.0 release!

My question is actual reasonably simple despite the cynical tone up to this point… Can we realistically design a new object oriented DSL that contains the necessary concurrency techniques to allow programmers to write reliable and correct concurrent game code. This actually goes beyond just the engine code for which we’ve always been able to reasonably easily move to a more sophisticated language like Haskell but more towards the game specific stuff, which we cannot afford to bog down in complicated syntax and general side effect hostility.

I actually believe this is possible, and I’ve already begun planning the first steps towards writing some basic engine code that will underpin the project but I’m definitely more interested in seeing how effectively I can pin down the STM concurrency model into an object oriented syntax.

Ok… what about the language stuff…

I’ve actually been looking for a good excuse to both learn Haskell more fully (I’ve really only coded trivial examples in it so far), as well as properly exercise the Parsec combinator parser and finally, and perhaps most of all, design a new object model and object oriented programming language using that model.

The last, ironically may have to be restrained a little, but a concurrent perhaps slightly more conventional object oriented language may not be so bad. The point is that the project will involve a fairly comprehensive object oriented programming language, and one that is not only fully concurrency enabled but also tailored to game development tasks.

This is probably a good place to point out, that the conventional object oriented language I’m talking about here doesn’t include either C++, Java, Ruby or even the CLOS, but rather I’m talking specifically about the Smalltalk family of languages here. Its the work done on Smalltalk/Squeak, Self, Slate and more recently Newspeak that I find the most interesting, and the dialect I develop will likely incorporate many of the simpler innovations in the object systems they use.

The most critical issue that I’m aware of is the complexity added by the multi-dimensional objects used by most OO languages these days (including Smalltalk in this case). Rather than allowing the object state to exist in two (or more) dimensions I’ll be limiting them to a single flattened dimension similarly to record types, and the programmer will need to use either delegation/cooperation or composition in order to accomplish tasks in a reusable fashion. If you didn’t follow the dimension of state thing I’m actually just talking about Inheritance (another dimension might be Aspects, et cetera).

While I don’t want to go to much further into the syntax I would like to note that my intentions for this, apparently built in, concurrency will probably be in the form of an asynchronous send, paired with transaction support (which will actually be the only way to guarantee that data is written correctly). The asynchronous send, by definition, allows the receive to process it in a different thread… but since my little language is probably going to be more or less interpreted or at least green threaded, I’m pretty sure that I can just replace the async send operation as a plain old spawn operation.

The async message send in this case should provide a convenient way of signaling between game objects, and paired with the transactions (noting that very few Erlang processes don’t actively apply transactional semantics as well), I should have an effective way of implementing fully concurrent game code.

Well then… hopefully I don’t get killed between all of these projects and we’ll see something interesting come out of this stuff. Until then…

– Lorenz