See I’ve also been reflecting on the last few projects I attempted and the core problems faced while working on those projects (why I dropped them).

Most of my effort in my personal projects has been focussed over the last couple of years on learning and understanding new programming languages. The problem is that while learning new languages can be very enlightening and quite fun, I found myself wanting to return to my original interest in software development—that is, game development.

The problem is that, while looking at various project ideas, and even attempting a couple (one of which can be found in an earlier post, although the code has been pulled since), I’m still faced with a number of inefficiencies that scream right towards my language design interests.

For a start, if you wish to provide a sandboxed game code environment then the only real option is to combine two languages using the bridge between them as the sandbox. This isn’t really a problem if your interested in simply creating a game now of course, and you don’t have to use a sandbox unless you want to run downloaded game code, but I don’t feel that these technologies really respect the time restricted resources of a small-team game developers (hobbyists, Open Source, relevant Independent gamedev companies).

Respectively, this is also what killed my Haskell gamedev project. That doesn’t mean I don’t intend to look into Haskell further—just not for gamedev tasks in the near future.

And furthermore, both conventional languages and embedded languages almost always require a restart before new code can be tested. I think that by reducing the turnaround time on new game code (or even engine code), the game programming process could be made significantly more accessible to smaller development teams for both smaller ideas or bigger, possibly open source projects.

So what have I actually been doing then?

I’ve actually been putting together a collection of notes and though experiments designed to push my understanding of Smalltalk and programming language design in general enough to put together a cohesive conceptual design for a decendant of Smalltalk, not to mention brushing up on my understanding of existing Smalltalks and the what the various Smalltalk related communities are working on.

Until recently however, I wasn’t convinced that there was an existing language that suited my somewhat unusual requirements for implementing this Smalltalk (or should that be preferences?) Recently I finally figured it out.

As it turns out, I believe that the best language for the early prototypes is The Java Programming Language!

I realize of course that Java won’t give me the best performance, nor will it be the simplest implementation, but when it comes right down to it, I’m just not familiar enough with another language with the necessary UI capabilities that actually conform to the conventions of the underlying operating system. I should even be able to take advantage of several library bindings before tackling C!

So there you have it, a post almost devoid of any real content, announcing my new programming language and both the interpreter and the design in general are coming along nicely so far, so you can look forward to more interesting details in the near future (like the core principles of the language design or the purpose of the language).

Oh, and one thing before I forget, I’ve named it The Mention Programming Language.

“Smalltalk is not a language — it’s a dynamic object system with the language built in… [sic]

This is, in my opinion, more cautious than it needed to be. Smalltalk really is just a dynamic object system, but beyond that, I would argue that the language is really just a collection of DSLs.

The first, method definitions is kind of the core DSL of Smalltalk. While not necessarily as small as a simple DSL it provides all of the behavioral elements that make Smalltalk code actually do stuff, all of which can be replicated by generating AST objects, programatically.

More obvious however, is the class definition syntax. This quasi-message-send actually causes so many hacks and side effects that suggesting that it resembles any kind of message programmers would be comfortable sending normally is just outrageous! Really it describes the structure of a class and allows us to manage that structure. Oh, we can also file-out that sucker, too!

(The OMeta parser generator can also be used to write methods. The tool support was iffy last time I looked at it though.)

My point is, Smalltalk is really just a collection of DSLs that allow us to effectively program with a pure object system, and it’s this phenomenon that I believe will allow us to dramatically improve both the appeal of the language as well as its usefulness in the future.

— Lorenz

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

Also, this project was killed some time ago. I’ve moved onto other things and when I look into more Haskell programming I will not be resurrecting this project (I have some more practical ideas in mind).

In my last attempt at coding gamedev, Haskell style, I found my true enemy to be my inability to fathom the modeling of high level game objects in basic Haskell records. The problem was pretty simple, I’m either not yet good enough to figure out how to implement high level game objects in Haskell, or the task requires something closer to the Functional Reactive type frameworks. The same Functional Reactive Programming that I still, to this day, don’t really understand.

In theory I should probably just keep reading through my copy Real World Haskell, but I always like to have one gamedev project and one language that I’m working on. This doesn’t necessarily include any reading or minor experiments of course, but it does help to limit how thinly I spread my free time and it’s nice to keep the gamedev and language design cravings in check (plus, it’s kind-of a fun, strange kind of duo, really).

Since my Haskell game project was essentially killed a while back, that left me with some time to work on a some gamedev projects in Python. The premise was, high level language, good for modeling game objects and apparently a solid library lineup. Solid at least, until I realized that almost all of my games require one simple critical feature. Tools.

The odd reality of any serious game development is that, no matter how clever your game is, you still need the tools, in which all of the content is created and developing those tools is, in my experience, a very hardcore UI intensive process, which given the current state of UI frameworks in Python is well…not good. Actually, perhaps that’s not fair, GTK may have done the trick nicely, but by the time I’d figured out how much UI I felt was really necessary, it seemed like I shouldn’t have to develop yet more UI code for the in-game UI.

Oh… and the Mention programming language is on temporary hiatus due to the heavy usage of untested extensions to the lambda calculus and type theory. While I slowly learn the math skills involved in learning the type theory (not that there aren’t other benefits to be had from learning mathematics properly anyway), I figure its going to take me at least a year to get it fully on track again.

Moving On…

So now there I was… back in Haskell… the Mention language stalled… and no game development project in sight… So I came up with an idea. What if I put some of the ideas I had floating around, and put them all together as a game, a language, and something to keep me working through Haskell. I would be developing a game engine designed specifically to beat the crap out of Haskell’s concurrency—and my CPU too, I suppose—while I also designed a high level game object language to implement the actual, high level game stuff.

It wasn’t actually until I’d been working on the language for a couple of weeks, when I realized what I was actually trying to implement, however. This link should probably actually be old news to anyone interested in gamedev, but here it is anyway: Tim Sweeney’s POPL 2006 talk “The Next Mainstream Programming Language: A Game Developer’s Perspective” (PPT Slides, Scribd Slides, I couldn’t find the video of the talk again.)

In the talk, he covers quite a few of the practical qualities that a modern commercial game contain in lines of code, complexity, and so on, but the point that stuck with me the most was the section on Concurrency. I swear, it literally screams “HASKELL!,” and not just because Haskell is mentioned later on, either. What I didn’t realize at the time, was that I’d end up trying to pull off a solution to Sweeney’s challenge, rather than simply using Python or Ruby and keeping the games… non-concurrent (or semi-concurrent).

There is actually a little section on why he doesn’t like Haskell at the very end of the slides. I’d just like to point out (for those who don’t realize this) that they’re all mostly irrelevant concerns since they’re all solvable in about five-seconds-flat by anyone who has more than two months of experience with Haskell, or aren’t significant problems anyway (laziness is not a performance hog, and targeting GHC optimizations isn’t impossible, et cetera). Honestly, I actually think it’ll probably be the two months of experience that causes the most problems (i.e. the unpopularity), but that may not be as much of an issue either, as better learning materials emerge.

Three Languages, for a Good Computer Game

So I’ve mentioned Haskell, and alluded to a scripting language, and of course we also have our shader language. To start with, I’d like to point out that the shader language is only partially bound to the game language, and even then it’s an indirect link, courtesy of the abstraction layer that typically accompanies the rendering code—that’s engine side—thus, the shader language may either be a separate language project, or (as I’ll be using) a prepackaged solution like GLSL. Regardless, at the moment only the engine and the scripting language are important.

This brings us to the title of the post then, a game scripting language, and it’s a strange one too. The problem is actually not as simple as just dropping in any kind of scripting language. No, the engine is intended to push Haskell’s concurrency potential to the limit (even on tomorrow’s hardware), but for this to happen, the scripting language must not become a bottleneck in the process. Sounds simple, right… but what happens when you build a game that scales big, really big even—beyond Supreme Commander big—and now it’s the scripting language that’s trying to handle unreasonable amounts of data (in addition to the engine). I don’t want to force game programmers to rewrite high level game code back in Haskell, simple to make it fast enough, that’s the entire purpose of the scripting language.

The solution then is the same as in the engine, make it massively concurrent, just like that Tim Sweeney talk was implying. But, a presumably object-oriented language, with extreme concurrency can only really mean one thing—it has to be semi-functional, and support either the process-oriented approach (Erlang), or the same Software Transaction Memory as Haskell below it—I chose the latter.

From Smalltalk, To Software Transactional Memory

Given the requirement for a Software Transactional Memory, it might seem obvious to simply write a variant of OCaml or Lua, but my experience with Smalltalk demanded otherwise. I believe that the best design pattern for implementing games is the prototype pattern. There are only really a few languages that make this pattern the global design pattern for the language, and in my opinion, JavaScript isn’t really the language of choice for writing semi-functional code in.

What I’ve done then is to start from a basic Smalltalk messaging syntax (that’s about the only real syntax in Smalltalk anyway) and then extend it to a full, text only syntax, removing all of the class and inheritance features and lastly, removing the main source of side effects, mutable variables. The result is a semi-functional object-oriented programming language, exclusively applying Software Transactional Memory for mutable object state, and making heavy use of prototypes and delegation.

There’s actually quite a lot, going into the design of Fire, oh yeah, that’s the name of this little programming language, and it would be quite pointless to go into great detail, at the end of an already lengthy post. What I can promise however, is a complete language specification, for those who are interested in the precise definition of the language and core libraries. And for everyone else, I should be following up this post later with essays covering some of the challenges faced in the unusual design requirements of The Fire Programming Language.

Anyway, that’s basically the status update, or the plan at least. The Fire Programming Language does actually have a complete syntax already too, and the first draft of said syntax chapter in the spec is also almost complete. Any question or reservations about the project are more than welcome, either in the comments or by email, and lastly… This is a long term project, one which I suspect may take anywhere up to year or more, before it hits a 1.0. What I do expect though, is some alphas and betas ready within 6 months or so and I’ll be setting up some git (public) repositories over the next couple of months for anyone who wants to muck about with it or give feedback (and the spec will slowly appear on a pages section of this blog).

– Lorenz

Well, the good news is that a wiki has been setup for increased public communication about the project.

You can check it out over at…linky

–Lorenz

The final nail in this case, goes out to the Transcript window, now defunct for god knows why. I actually considered attempting to find a fix for it, or even fixing it myself, and then I realized the obvious. I don’t like Squeak. Its always flakey, or broken, or difficult, or anything but genuinely useful!

I’m sure there are plenty of things it does well if you’re interested in Seaside, but I’m not.

Then I considered the last language I was working on (a concept Lisp that was intended to integrate newer Object-Oriented ideas like Traits). The interesting thing about Lisp is that it handles the Virtual Machine work like there’s no tomorrow. Its also simpler and console based, and you can generate lambdas without even really thinking twice. Hugely important if you want to quickly prototype some high level stuff, that also needs to run reasonably efficiently (not stuff that’s directly part of the language, but rather the VM’s implementation itself).

So, I’ve decided to finally get around to learning the thinking mans Lisp, Scheme. Scheme may not be massively different from other Lisps (i.e. Common Lisp), but it does tend to do things in a somewhat more straightforward fashion. The biggest example I can think of is that it is a Lisp-1 language, which means that there is only one namespace. This is a big plus in my book, for languages that do not provide separate syntaxes for selectors and variables. Mention of course has two namespaces, due to the selector syntax involved in sending messages. On the other hand, selectors in Mention and Smalltalks in general do not always correspond to the same function object.

If all goes well, I should get started writing actual code within a couple of weeks, with a reasonable understanding of Scheme. Since I already know a reasonable amount of Common Lisp I don’t believe it will take too long to learn, but you never really know with close cousins in the languages world.

I would also like to take the time to note that I’ll be developing a reworking of the OMeta parsing architecture for PLT-Scheme (or some other dialect if I swap away from PLT, but that seems unlikely). This parser framework is called MMeta, as I’ve probably mentioned (no pun intended) before, and will serve as the basis for the compiler and parser used throughout the Mention implementation and within the implementation. The PLT-Scheme variation of the actual parsing code (and the S-Expression support), will be referred to as MMeta-L (for Lisp).

– Lorenz

The final version of the language was meant to be based on a concept of method inlining. Basically, since most memory accesses are more or less constant events within a message, and even when they’re not, most of the code could be inlined further down the message stack, we could rather than using conventions or making the language very memory neutral/high level, we can instead allow programmers to directly manipulate their objects.

Of course this doesn’t really help us now (the current prototype is based on Squeak, which lacks the effective memory model to warrant using raw memory layouts yet), but even if we did implement this approach, we would still require a more generalized object layer on top of it. For this reason I believe that implementing a more restricted object model is in order.

To start with, I believe the basic object structure will be needed (Objects must be defined by the external system), and from there I will attempt to describe the general structure of the language using the Multi-Method equivalent of delegation (traits). This will include all of the necessary interfaces required to make the language self sufficient post bootstrap (except the Virtual Machine itself which will be rewritten in C or Haskell until the language can compile itself).

There will also be several objects that need to be constructed right from the word go, which includes, roughly, Integers, Floats, Strings, Symbols, Lists/Arrays, Dictionaries, Classes, Traits, and the base level behavioral interfaces that apply to all objects. These objects will be provided from Squeak directly, or will be implemented on a Generic object Squeak class, which can provide all of the necessary behaviour to bootstrap language level objects.

One last point I’d like to make. The behavioral interfaces do not actually apply to Mention objects specifically, but rather describe how the programming environment reacts to objects in general. Any object may be added to the Mention system simply by defining the fundamental interfaces required (essentially just some relative typing information for the dispatch engine), and then it can be used anywhere in Mention that actual Mention objects can be! In-fact, this goes so far in the language that there will very likely be components that do not even encode type information into objects for the sake of performance (no object headers or garbage collection). This is possible if the interfaces do not require any dispatching at runtime (otherwise the lack of type information interfaces will cause compilation errors!).

Anyway, hopefully I’ll have the prototype more or less working soon and you’ll be able to check it out for yourself, though it won’t do very much at the moment;)

– Lorenz

As you might have guessed I’m mainly writing this out of mere frustration, that even the dumbed down, simplified variation of Mention that I’m attempting to bootstrap is going, well, slowly. Very slowly.

So far I’ve come to the conclusion that there may even be some general rules of thumb, which to the enlightened few, might not actually seem all that obvious. Firstly, the current attempt to bootstrap Mention is utilizing the Squeak programming language/tool-chain, in the hopes that it would help to speed up the development process. It didn’t. Actually, I’m even wondering if its actually slowing me down… Which brings me to the obvious question. Why?

The most useful languages that spring to mind after asking this question, probably actually come from the Lisp family, along the lines of some dialect of Scheme + a parsing language to complete the picture. But what would make a language like Lisp, outgun its successors like Smalltalk or perhaps even python. Well, actually, I think python might even work, but Smalltalk has issues… Namespace issues.

The issues with Smalltalk I’m referring to are the conventions surrounding the naming of global variables, or at least the lack-there-of. Many scripting languages and most Lisps, allow the programmer to assign to any old variable name, and its simply there, for the entire world to see. But of course, when you have to think in objects, you can’t expect to have globals. After all, good Object-Oriented software should be based on the interaction of object, and not glorified globals, singletons, or otherwise. Although you could be mistaken for thinking that the Application object is actually a global, but of course its not. Why, well I’m not sure really, its just not.

I’d rather not go on any further with this, but the point is simple. We know that software systems evolve, and don’t simply get designed and then implemented. And we know that software is not actually re-used until at least some refactoring has been performed (generally more than some). So why can’t we just use our globals while we understand the problem we’re working on, and if they do the job we can just keep them, and if they really are flakey code smells bend on silicon armageddon then we can simply refactor them once we understand how the problem breaks down into the individual problem level (application, subsystem, et cetera) objects.

– Lorenz (feeling slightly better ;)

What makes the language interesting however, is that is does this kind of strict typing from within a pure functional syntax (one that is very close to the mathematical lambda notation), and quite literally everything except the bindings themselves are first class values (objects really), and they all have types, which are themselves of some type and all can be fully reasoned with using the full capabilities of the syntax.

What all this means is that unlike Scheme (Lisp), instead of allowing objects of any type as values, all values and expressions must be the the correct type in any given piece of code (or they must be inferred transitively from their surrounding/contained code). Any mismatches are not allowed by the languages semantics and will cause compilation (or interpretation) errors.

This brings me to the point of this post, is a strictly typed language actually less or more capable than a weakly typed language. Also, if this is the case, does is it make the language better, or are other considerations more important (i.e. architectural concerns)?

I find this discussion interesting since it quite effectively contrasts the type system I designed, for Mention. While Mention’s type-system is effectively not just weakly typed but in many cases not checked at all, it allows arbitrary objects to be used in most situations, as long as they conform to the interfaces requested (in the type annotations or implicitly like Smalltalk).

Already I’m finding that I miss the more flexible type system when I find the only error messages cryptic type incompatibilities (what do you mean the type ‘a -> [a] -> a’ isn’t compatible with ‘Num a’… Hell where is that number anyway?). It is slowly getting easier as I understand the impressive type reasoning capabilities of the language, not to mention the ominous Monad magic (think C++ templates on steroids… although probably very much easier to use effectively)

Presumably as I continue to work with both Haskell, Smalltalk (Squeak), and Mention I can come form a better opinion on the effects of strong vs. weak type systems (in languages with first class function and type objects). Oh… and they are right… Haskell does seem to be a language well worth the effort to learn effectively.

– Lorenz