I propose the following syntax for swapping:

a <=> b;


There, simple eh?

<=> is the “swap operator”, or, as it is known in some circles (the depths of my twisted mind), the “swaperator”. This operator will be overloaded. For example, int <=> int will swap the values of two integers, container <=> container will swap the elements of a container (but not necessarily all the values, if the elements are pointers), or perhaps just the pointers to the containers themselves (see the optimization section below).

What this replaces

Traditionally, swapping is done with a temporary variable as follows:

temp = a;
a = b;
b = temp;


Though there are also a couple of “in place” swapping algorithms that don’t require the extra memory;

The XOR swap:

a = a xor b;
b = a xor b;
a = a xor b;


And the arithmetic swap:

a = a + b;
b = a - b;
a = a - b;


Though the general consensus is to just use the temp swap or library swap() call and let the compiler do with it what it will (illustrated here).

But it doesn’t matter, because we’re replacing all of these, up in here, with one line of code.

What this gains

It’s short. It’s also a lot easier to understand than the alternatives, and a lot harder to mess up. Also, the compiler can do static analysis (and perhaps runtime analysis) to determine the best (most optimized) swapping algorithm to use (see below).

Implementation and Optimization

The compiler can look at the size of the thing being swapped and decide if it wants to do a temp swap, an xor swap to save memory, or simply treat the values being swapped like pointers and swap memory addresses in nearby access contexts.

One problem with certain swap algorithms (such as the xor swap) is that it doesn’t work if a.) the values are pointing to the same address or b.) the values are pointing to addresses that overlap. In IPL, there won’t be support for pointer arithmetic, and variables should be allocated in such a way that they do not overlap in memory. But the first issue of variables pointing at the same address might still come up.

I propose for static analysis to take us as far as it can regarding swapping the same address. For example, anything of the form a <=> a should be treated as a noop and compiled out. If multiple pointers/references point to the same thing, and this can be proven at compile time, then a noop will be recognized:

a = &c;
b = &c;
*a <=> *b; // noop


If it can be proven that the swap will swap two values with distinct addresses but identical values, then the swap can be treated as a noop:

a = "blah";
b = "blah";
a <=> b; //noop, should be compiled out


void doSomeStuff(var a, var b)
{
    ...
    if (a == b)
    {
        a <=> b; // noop, because a must equal b in this context
                 // or this line won't be reached
    }
}


If it can not be proven that the swap is a noop, then a typical swap instruction sequence will be generated by the compiler. For example:

a = waitForUserInput();
b = waitForUserInput();
a <=> b; // a & b could be the same or different, don't know until runtime


generates:

a = waitForUserInput();
b = waitForUserInput();
temp = a;
a = b;
b = temp;


Of course, in simple static contexts, the values don’t actually need to be swapped, even if swapping them is a noop. As can be seen here, it is entirely possible for the compiler to simply do a static register swap from the access context of swapped variables. For example, the following code:

void blah(var a, var b)
{
    Println("BEFORE: a = " + a + ", b = " + b);
    a <=> b;
    Println("AFTER: a = " + a + ", b = " + b);
}


Could easily have the swap line removed completely and the variable accesses themselves swapped statically, to generate the equivalent of the following:

void blah(var a, var b)
{
    Println("BEFORE: a = " + a + ", b = " + b);
    Println("AFTER: a = " + b + ", b = " + a);
}


Summary

In short, a <=> b is less typing, taking only one line of code. The <=> operator is built into the language, so it can be used from any context without having to include some library (like with std::swap). <=> is the only thing you should ever need to use to swap two variables. Forget about the implementation details, forget about clever but non-intuitive tricks with bitwise operators or abelian groups. In the IPL, the compiler will do all the dirty work for you. If all you want is for two variables to exchange values, you can count on <=>.

Addendum

Just before posting this, I did a good old fashioned last-second Google search and found that I am not the first to propose such an operator with such a syntax. If two or more people think it’s a good idea, then it has to be a good idea!

“No way. No—that’s fucking impossible.”

Cyber-crime is real, dawg.

First of all, being a computer programmer by profession, I was shocked to learn that cyber-crime is such a big deal. I live in a city in the United States where gang violence continuously thrives in a spacious, sprawling, low-economy ghetto that everyone turns a blind-eye towards, assuming they can afford to do so. It’s a place where the middle-class and above go to bed at night pretending that people five blocks over aren’t being murdered just because they maybe won the wrong game of basketball or something. I’m adjusted to the concept of crime being all around me.

But not in my work-place. So you probably can’t imagine my surprise to learn that cyber-crime is such a threat. For example, I never knew about ‘drive-by downloads’. As Norton describes them on the contest site:

You’re sitting in front of your computer surfing the Web when all of a sudden, your computer is hit with a threat just because you visited an infected website. Drive-by downloads can catch you off guard, just like crime on the street, if you don’t have t he right protection.

“Just like crime on the street….” Indeed. Like earlier today I clicked on a link to read a tech blog, and a pop-up advertisement came up unexpectedly. Maybe it was downloading something! Until today I never realized how similar experiences like that are to the time I rounded a corner downtown in the car with my ex-girlfriend, to the sight of two police cars, and a number of police officers chasing down two men with their guns drawn. It was like a pop-up ad, but on the streets.

That shit was whack.

What I also didn’t realize is that there must be some sizable intersection between

1. Hard-ass rappin’ gangstas dat know how to drop dat shit fo realz.
2. Security-conscious youth interested in staving off online crimes.

I thought that maybe I fit into that intersection, but then it occured to me that I don’t belong in either of those categories to begin with. So oh well.

I also thought it may be fun to try and compose a rap to send in. But it turns out that rapping is hard. This was a revalation, as I had always thought that the best rappers were those who were ‘eductionally challenged’ and never developed the proper literary skills—such as ‘a vocabulary’—to create any type of poem or verse, let only observe the rules of rhyme and meter. What they do is well beyond my abilities.

But that doesn’t mean I’m not going to try to come up with something. I did just recently buy a laptop with a web-cam, that’s a first for me. And I have a microphone somewhere around here. And it’s a long weekend (got Monday off work). And I’ll probably be drunk at some point… Hmm…

Let’s see where this goes.

Listen, we need to talk. This is getting pretty ridiculous. I know you mean well, but enough is enough. You need to go back on your meds. In case you didn’t know, I don’t enjoy having seizures when I watch you. Similarly, I do not enjoy listening to horrible music with horrible English about how life is a painful flower or something else not even remotely related to the show.

Seriously. Are you drunk? Is it all some big joke? Do you do this because you hate me? Do you even like animes? I don’t think you do. I think you hate them, and you won’t rest until you’ve convinced everyone else that all animes are a bunch of teenage twats running around like morons bitching about how sad everything is while they hunt vampires or some shit. I don’t know what you’re trying to tell me, really.

And for the love of Christ, shut up already! I think it’s great that you found a 22-year-old eunuch to sing for you, but guess what? He sucks. Also, his English is horrible. Not only does it not make sense, it’s a fucking Japanese show! Why is he using English? That’s not how you say that word! That’s not a phrase we use! That’s not even a complete sentence!

Alright, maybe you mean well. I don’t know. Maybe you were abused as a child and that’s why you don’t understand the concept of allusion or plot encapsulation. Maybe all those times you were beaten with a broken garden rake destroyed your ability to understand the difference between good music and the noise that goats make when you skin them alive. Maybe because you missed out on all those therapy sessions, you thought it would be a great idea to completely reinvent yourself every twelve episodes. It’s not your fault you have a massive personality disorder.

Just stop already. OK? Please? Look, you’re not the intro to Samurai Champloo, alright. You’re just not. You’re like a dangerous snake I stumbled upon in the woods, all brightly colored and hissing and trying to bite my fucking eyeball. I don’t want that. I like my eyeballs the way they are: fully functioning and not bursting apart with venom.

I really wish it didn’t have to be this way. Maybe one day you’ll be better and I won’t have to skip past you every time. Maybe you just need to stick with Yoko Kanno. Yeah, just do that. Just play some random music from her and show a title screen. Simple, basic letters. Tone it down, you know? But that’s not going to happen. We both know that. Because you’re a dumb slut.

Anyway, I’m dating your sister, the show. She’s got pacing and content. Sure, sometimes I’m just left standing in the dark, confused about why there’s blood everywhere, but it makes sense in the end, and I’m good with that.

Sincerely, the viewer

Also, I guess I’m closing my statements with semicolons out of habit, but I haven’t thought about whether or not I like that. We’ll keep it up for now.

If player is null, then the entire expression player?.name evaluates safely to null as well, which is then assigned to playerName. No NullPointerException is ever thrown, as long as you use ?. and not .. Why is this a good thing? Because it saves us from having to write:


if (player != null)
{
    playerName = player.name;
}
else
{
    playerName = null;
}


Of course, what if you actually wanted to set playerName to something else, like the empty string? The way this is handled in Groovy (and Java 7 seems to be heading in this direction, although the author of this paper “does not specifically advocate adding these features to the Java programming language”) is to use something called the Elvis operator:

playerName = player.name ?: "";


This appears similar to, but should not be confused with, the traditional ternary operator for simplifying branching logic. The above statement would appear as follows using the ternary operator:

playerName = player.name != null ? player.name : "";


Which is just a little more verbose. I’m not sure if I would like to see the ternary operator in IPL, so I will defer my opinion on that for the time being.

One final safety operator defined in the above Java paper is the safe indexing operator ?[]. After all, if a null instance can have its member variables attempt to be accessed, a null container can have its elements attempt to be accessed too. I would recommend using this in IPL if ?. and ?: are going to be adopted.

As mentioned in the comments here, things can get messy with long chains of dereferencing:

final String aMember = g?.members?[0]?.name ?: "nobody";


There are several interesting proposals for how to simplify the above line of code, which looks like it was hit with one of the Riddler’s frag grenades. Well, if ? now represents null safety, why not create a new assignment operator, ?=, that makes the entirety of the right side implicitly null safe. Then the above line of code would become:

final String aMember ?= g.members[0].name ?: "nobody";


I’m not sure I like the question mark symbol used for this sort of thing, but I also don’t know of what the “ideal” symbol is off the top of my head.

The point of all of these shorthands isn’t to encourage people to ignore null checks, it’s to minimize the typing they have to do to handle them. Also, if a null value should be considered an exception, then simply use the traditional . or [] operators.

As always, feedback is welcome in the comments. In fact, I will be traumatized if there is no feedback, so get to it!

Unlike Eureka Seven, you learn very quickly in Ergo Proxy that the Earth is totally fucked. Presumabably by some apocolptyic, poor decision by man-kind. Is it worth watching the series to figure out those wrongs and how one might right them? Let me tell you…

The Focus

Ergo Proxy resolves primarily around the interactions between three characters:

1. Vincet Law, a young man trying to overcome his status as an immigrant.
2. Re-l Mayar, a young woman who is the grand-daughter of a city leader.
3. Pino, a child girl who is a robot.

And then there are a number of imporant, ancillary characters. The cast is fleshed out well enough that you can begin to care about the other characters even if they only appear once every three or four episodes.

And that is very crucial, because Ergo Proxy is very much a character-driven anime. While there are some action scenes, and some cool battles, the majority of your interest in the show will depend on your ability to be interested in the main characters and their personal developments. Many anime forego the volley of visceral action in favor of a more character-oriented show, drawing you in by tempting you with what may become of the personas involved. For Ergo Proxy, this is somewhat of an odd choice, only because the backdrop for the show feels very fertile for an all-out action anime. Like I said, Ergo Proxy has it’s fights—even the first episode is not without a little tussle—but it’s interesting that the action always feels like a second class citizen to the character development. A desolate Earth where humanity struggles against extinction by barracading themselves in domed-cities, where the power hungry chosen few dictate the lives of the masses, where segregation exists between citizens and immigrants, humans and robots, this social bureau and that bureau—you could derive constant action from all of that.

Ergo Proxy does not do this.

The focus is primarily on the characters. To such an extent that there is one episode consistening entirely of just dialog between the three main characters mentioned above. Nothing significant happens. It is a true credit to Ergo Proxy that…

1. It can even get away with such an episode to begin with.
2. That it’s actually one of my favorites, because the character dynamics are so entertaining.

The Gist

It’s hard to talk about the plot of Ergo Proxy without spoiling things, and I don’t intend to do so. I think Dai Satou is a great writer, and he wrote a great tale in Ergo Proxy, one with complicated and intricate threads that make it difficult for me to dance around the plot in a general sense. But I’ll try to tango over the first episode anyways.

Basically a large chunk of humanity is living within the beautiful, dome-covered metropolis of Romdeau (maybe misspelled). It is a city where every person has their role to play in ensuring that society continues on, because outside of the dome is a shitty waste-land; how the planet got that way is never exactly explained, but you get enough hints to understand that it probably involved some dumb-ass scientists fucking shit up for everyone. For the people in Romdeau, however, the outside doesn’t matter. It may as well not even exist, because their lives are great in general. So long as everyone follows the rules and behaves as a ‘model citizen’ (as is often chanted in the background), then life is full of rainbows and sunshine.

The city of Romdeau is run by the man Donovon Mayar and some nude Greek statues who can talk—seriously. His grand-daughter, Re-l Mayar, works with her ‘autoreiv’ (i.e. robot) companion Iggy as part of a department that, among other things, deals with infected autoreivs. Ergo Proxy begins with Re-l tracking down an autoreiv who has been infected with the ‘cogito virus’, a virus by which the autoreivs lose their subservience and grow a soul. This brings her into contact with Vincent Law, a man working in a lower-rung department who is trying to get his shit together so that he can drop his immigrant status and become a full-fledged citizen of Romdeau; because until then, everyone can, and does, shit all over the guy. During the first episode, Vincent goes over to the home of the Chief Security Bureau to check one of their autoreivs for the cogito virus; that autoreiv is Pino, the little girl I mentioned earlier. While some robots in the city are laborers, some exist simply to provide companionship. Pino falls into this latter case, because the city strictly controls natural child-birth, and so Pino is given to the family as a daughter.

That is how the first episode introduces the three main characters, and maybe covers the first half. After that, shit hits the fan, and the status is elevated to on.

Closing Thoughts

I found the character designs to be very interesting, from an artistic perspective. Things like Re-l Mayar’s signature heavy eye shadow, and the facial voids of the autoreivs give Ergo Proxy a curious face. The show does a great job in portraying a lot emotion through facial expressions, achieved through a combination of said design and camera angles—Ergo Proxy knows how to do a great close-up shot, let me put it that way.

I only saw the show in Japanese, and the voice acting was great. In particular for Pino, whose child-like curiosity and naivety really comes across in a sincere way; despite being a robot, she never speaks like one, and the voice actress did an amazing job capturing a real innocence in her voice. The same praises can be sung for most of the actors and actresses, who display a wide variety of emotion in their performances, and thankfully are even given the chance to due so via the show’s structure. Had Ergo Proxy been filled with more one-dimensional characters, there would be next to nothing to say of the voice acting. Instead the show well fleshes out a small cast, and in doing so allows for some great performances.

There is a sound-track to the show, but to be honest I barely noticed it. I never remember the music of Ergo Proxy being an important element, or being key to some particular revelation or suspenseful moment. It certainly never hurt, but there was no moment where I ever thought to myself that a scene would have been better served by this or that music. Although I have to say, there is something about the opening song that I really love, ‘Kiri’ by Monoral. I could play that on loop for quite a while.

If you want a sci-fi, post-apolyptic show with fantastic characters and a plot with tantalizing mysteries, then you will enjoy Ergo Proxy. You’ll need some patience as you wait for explanations as to what’s going on—Dai Satou seems to always do that—but you will be well-rewarded. The show has its great moments of action here and there, and some genuinely cool fight scenes, but the camera is always on the characters and what they are thinking and feeling. If you don’t love the main characters, you’re just not going to enjoy Ergo Proxy that much, simply said.

I thoroughly enjoyed Ergo Proxy and would recommend it to any anime fan.

In this article, I want to talk about a keyword that extends the functionality and flexibility of moments in a simple manner. It is the “when” keyword, and it has the following syntax:

when moment-specifier
{
    moment-safe instructions
}

Notice that “when” is a block construct: it is followed by a brace-enclosed list of instructions, similar to if, for, and while blocks in many other languages. I want to take this time to say that I am following conventional syntax for simplicity’s sake, but I am more interested in the semantics. Still, if you have any thoughts on the ideal syntax for anything I bring up, feel free to mention it in the comments.

What “when” does is extend an existing moment with new instructions. This is super powerful as it allows you to edit logic distantly. This is also super dangerous as it allows you to edit logic distantly.

The component of this construct that needs the most explaining is that strange yet powerful moment-specifier. A moment specifier is a means of telling the compiler which moment this when construct is referring to. If you recall from the last article, the syntax for a moment is this:

moment <label> {
    moment-safe instructions
}


The “label” in this syntax is optional, but it is necessary if you wish to access this moment from a when block somewhere else in code. The label of a moment can be used as the moment-specifier of a when statement.

Here is an example of how this would be used. Let’s say you have a first person shooter (yes, all of my examples will probably be game related), and in this shooter you want to have your enemies “wake up” when the player fires a shot. By “wake up”, I mean simply become aware of the player and start path finding toward them.

It might look something like this:

// in player.ipl
class Player
{
    moment shoot
    {
        projectileManager.spawnProjectile(position + muzzleOffset, heading);
        soundManager.playSound(gunshotSound);
    }
}



// in enemy.ipl
class Enemy
{
    when Player.shoot
    {
        alert = true;
        targetPlayer = the Player;
    }
}


Okay, I’ve taken some liberties and shown an IPL feature that I haven’t written about yet. For now, let’s just assume that “the Player” just works, and by works I mean it resolves to the instance of Player upon which the shoot moment is occuring. I think it would be interesting to see the definite article used in a programming language as a cleaner way of accessing singleton instances, as well as accessing instances of non-singleton classes in non-ambiguous contexts (such as inside an iterator loop). But that can wait until a future article.

The things we should focus on here are the shoot moment declared in player.ipl, and the when block in enemy.ipl that allows the enemy to respond to the player shooting. What this illustrates is that the way the game behaves when the player shoots is split up into separate locations. How would we accomplish this in a language without moments? There are a few ways I can think of:

1.) Tell the enemy to wake up from inside the player class’s shoot() method. This is bad as it requires the player class to be responsible for all enemies in the game.

2.) Check to see if the player has just shot from the enemy’s update() method every frame. This transfers the responsibility of enemy alertness from the player to the enemy itself, where it should be, but it has its own problems. There needs to be a variable stored somewhere called “playerJustShot” or something, probably in the player class, and this variable needs to be set to true when the player shoots and false after some period of time. “Some period of time” requires creating timer logic. You could just set it to false on the next frame of the player’s update method, but you need to make sure the order of things is correct (remember what I said last time about how painful order is to keep track of in update logic?). For example, if the player shoot occurs and sets playerJustShot to true, then the player update occurs and sets it to false, and then the enemies’ update logic occured, then enemies would never become alert because they would never check that variable in the slice of time that it could possibly be set to true. Finally, if there are multiple players in the game (coop), then each enemy needs access to every player to check this variable.

3.) Use a message dispatch system. Inside the player’s shoot() method, call messageManager.sendMessage(hShootMessage);. Inside the enemy’s handleMessages(Message m) method, check to see if this message is received and respond accordingly. The player is not responsible for knowing how this message will be used, they are just responsible for broadcasting it. And the enemy is not responsible for knowing what caused this message to be sent to them, they are just responsible for reacting to it. This is a good solution in that it decouples the player from the enemy, but the syntax is bloated (hShootMessage, and all other messages, must be initialized at some point) and the message calling has a runtime overhead.

In fact, you can think of the when construct as a message system built into the language, one that requires less typing and provides compile-time (more optimized) message resolution. when allows us to fully decouple player and enemy logic from each other at type-time, but to couple them back together at compile time. This is great because it keeps the logic clean and easy to reason about for humans composing the system, yet brings things together for cache optimization and such when the game is built. I imagine that at compile time, the above moment would actually be treated as if it was a method call that looked like:

void whenPlayerShoot(Player thePlayer, List allEnemiesInTheGame)
{
    projectileManager.spawnProjectile(thePlayer.position + thePlayer.muzzleOffset, thePlayer.heading);
    soundManager.playSound(thePlayer.gunshotSound);
    for each enemy in allEnemiesInTheGame
    {
        enemy.alert = true;
        enemy.targetPlayer = thePlayer;
    }
}


It is easily seen that this produces the results of a message-handling system (decoupling of related events) without the overhead of having to call messageManager.sendMessage() or messageListener.handleMessages() at runtime.

So far so good, but I haven’t explained what it is that causes the moment Player.shoot to even occur. Moments are like methods in that they aren’t going to call themselves. But also, like methods, they can be called:

// in player.ipl
class Player
{
    void update()
    {
        if (inputManager.shootKeyJustPressed())
        {
            shoot();
        }
    }
    moment shoot
    {
        projectileManager.spawnProjectile(position + muzzleOffset, heading);
        soundManager.playSound(gunshotSound);
    }
}


or chained:

// in player.ipl
class Player
{
    when inputManager.shootKeyPressed
    {
        shoot();
    }
    moment shoot
    {
        projectileManager.spawnProjectile(position + muzzleOffset, heading);
        soundManager.playSound(gunshotSound);
    }
}


or chained with smaller syntax:

// in player.ipl
class Player
{
    moment shoot
    {
        projectileManager.spawnProjectile(position + muzzleOffset, heading);
        soundManager.playSound(gunshotSound);
    } when inputManager.shootKeyPressed
}


or used with all sorts of logical constraints:

// in player.ipl
class Player
{
    ammo = 100;
    moment shoot
    {
        projectileManager.spawnProjectile(position + muzzleOffset, heading);
        soundManager.playSound(gunshotSound);
        ammo--;
    } when inputManager.shootKeyPressed && ammo+ //ammo+ is the same thing as "ammo > 0"
}


and I mean all sorts of logical constraints:

// in player.ipl
class Player
{
    ammo = 100;
    moment shoot
    {
        projectileManager.spawnProjectile(position + muzzleOffset, heading);
        soundManager.playSound(gunshotSound);
        ammo--;
    } when (inputManager.shootKeyPressed || scriptedShootOccurs) && (ammo+ || gameManager.cheatModeEnabled) && !gameManager.paused
}


which could make your moment declaration verbose, except that you can encapsulate moment-controlling logic just like any other logic:

// in player.ipl
class Player
{
    ammo = 100;
    moment shoot
    {
        projectileManager.spawnProjectile(position + muzzleOffset, heading);
        soundManager.playSound(gunshotSound);
        ammo--;
    } when shootInput && canShoot() && !gameManager.paused

    bool canShoot()
    {
        return ammo+ || gameManager.cheatModeEnabled;
    }
}


Okay, I’m moving pretty fast. I think there are a lot of neat things you can do with moment logic and the when keyword that let you organize your code base however you want. And I think IDEs can be set up to do a read only display of all instructions related to a single moment at the press of a button so you can look at them side-by-side to fix the problem of scattering that moments can bring to the table.

Just to clarify for anyone who has not read this series in its entirety, IPL is not a real language (yet), I am just brain-storming and free writing some ideas that I’ve had over the years. As such, feel free to make suggestions to improve things (like Ren’s suggestion of not requiring the “numeric” keyword, which you will notice is lacking from the “ammo” declaration in the above examples). Really, I think there’s a lot more to be said about moments, which I might put into future articles. In the meantime, I hope this is enough to get the general idea out there simmering in peoples’ brains.

You’ll also see me sometimes quickly switching between Marisa and Alice. This is not by accident. By doing this you get the effect of having Alice’s beam stay active and Marisa’s bullets—the so-called ‘Malice Cannon’. It’s a very useful trick getting through the game with that team, as you can use it to beat some bosses very, very quickly.

Anyways, enjoy the 11MB video.

What is a moment?

A moment is an atomic unit of time. If two things happen in the same moment, then neither thing happens before or after the other.

This is a very useful semantic tool in the day-to-day thinking of the human mind, but it is surprisingly lacking in the domain of programming.

In this context, a “moment” is a set of instructions in which order does not matter. That is, in a moment:

a = 10;
b = a;


has precisely the same result as:

b = a;
a = 10;


Unlike the norm in sequential programming paradigms, that a statement comes before or after another statement in a moment is irrelevant. After the above moment (either version) is executed, the result will be that both a and b have a value of 10.

The problems this will solve

The problem that inspired me to start looking into this tool is the initialization phase of game logic. In complicated games with dozens of systems, it is incredibly common to find bugs that occur because one system does not get initialized until after another system that depends on it already being initialized. What this costs the programmer (and this is especially costly if you are new to the project) is search time: when adding initialization logic to the program, you must search through the existing initialization logic for the right “time” to add your logic. Even though conceptually, there is no “time” passing in the game yet — it hasn’t even started!

This search time grows as the code base does, as there is more to sort through. And this problem doesn’t just happen during initialization; it can happen every frame. Games generally have an update loop, where things that happen every frame get calculated. Player input will be processed, physics calculations will be applied, the characters and objects in the world will be moved around, and the game state will be rendered (among other things). If these things do not happen in the correct order, bugs will occur. For example, the camera needs to be pushed outside of static meshes, or when it comes time to render the world you will see the insides of your geometry. This means the camera’s collision resolution must happen before the render phase uses the camera position and orientation to render the scene. Another example is if the player character has something attached to them, like a weapon in their hand. If this weapon is updating its position every frame to keep it lined up with the player’s hand, then this update must happen after the player has moved, otherwise the weapon will lag behind the player and seem to be floating in space, always one frame behind where it should be.

This is because in sequential logic,

player->position += player->velocity;
weapon->position = player->position + offset;
...
render();


is remarkabley different from

weapon->position = player->position + offset;
player->position += player->velocity;
...
render();


In the first code snippet, the player gets moved properly (leaving the weapon behind), then the weapon gets moved back into the player’s hand, then the game is rendered and all is well. In the second snippet, the weapon gets moved to the player’s hand first (where it should have been last frame), then the player gets moved to wherever they want to be, leaving the weapon behind, and then the game state is rendered, with the weapon constantly trailing behind where it should be. This is trivial to spot and fix in the above example, because all the code is treated as if it is in the same place, but in a real game such update logic would be scattered in many different files, and in order to understand the order of operations you will have to trace the call tree spread through all of these files.

“Scattering”, a term made popular by the Aspect Oriented Programming movement, is when a programming concern gets separated into several locations among several source files. This is considered bad, as it requires programmers modifying the system to have to search in many places to make sure the logic still holds after their modification. If I may be so liberal as to consider “updating the game” as a single high level concern, then the update loop is likely the most scattered concern I consistently see in game code. Every game object needs its own update method, and every system does too. There are countless ways the order of updating can go wrong, and they aren’t always intuitive or easy to spot even when looking at the bug.

The solution

Imagine if, upon creating a new updateable object for your game, you didn’t have to spend the time figuring out where in the sequence of steps the call to your update method should go. What if you could just write it, and the compiler could figure out precisely when it needs to get called.

The paradigm I am proposing will solve the issue of human error messing up sequential logic. It does this by treating such a scenario as “update” as not a sequence of events, but as a “moment”; just like how I argue we think of it. Of course, the computer can still execute its low level instructions sequentially, this is just a paradigm to remove some of the clutter from the high level domain in which the programmer is working.

Formally speaking, if a “sequence” is a set of ordered instructions, then a “moment” is a set of unordered  instructions. In this context, “unordered” means that the instructions can appear in any order in the source code and still produce the same executable (and runtime behavior). Of course, order of execution is still important (for correctness and cache optimizations). The key here is to improve human productivity by giving the responsibility of ordering to the compiler.

How does the compiler do this? Let’s consider our previous example (the wrong version):

weapon->position = player->position + offset;
player->position += player->velocity;
...
render();


The first step is to tag each instruction based on what it modifers, and what it depends on.

weapon->position = player->position + offset;

The next step is to sort the instructions such that no instruction that depends on a variable appears before an instruction that modifies that variable. In this example, the instruction that modifies player->position will be moved to occur before the instruction that modifies weapon-position. This seems like a trivial accomplishment with just a few lines of code, but the kinds of bugs that this can move to compile time can be hard to track down at runtime. Also, I see no reason why dependency analysis can’t be done from one method to another — for example, if the render() call above modifies player->position, but also depends on weapon->position, which itself depends on player->position, then we have a dependency loop. This dependency loop is not obvious to a human reading this section of code since part of it lies in the encapsulated call to render() (which may very well be in a compiled library), but the compiler can quickly identify this and point it out. In this manner, moments can take away some of the hassle of scattering.

As long as there are no dependency loops, and as long as no variable gets assigned twice in the same moment, then this method should work flawlessly. I believe that dependency loops (such as a = b; b = a;) and multiple assignments (a = 5; a = 10;) inside of a moment should be treated as compile time errors. Dependency loops are bad because they leave no unquestionably ideal ordering for the compiler to work with, and multiple assignments are bad because no variable can have multiple values in the same moment (what would this mean?).

The syntax I propose for this feature is:

moment <label> {
    moment-safe instructions
}


This consists of the moment keyword and a set of moment-safe (dependently-safe, and singly assigned) instructions wrapped in a standard brace block. The label is optional. In the uses this article scrutinizes, there is no need to label a moment. However, I have some ideas with moments that I will discuss in future articles where referring to a moment from a distance point in code will occur, at which point labeling moments becomes a necessity. It can also be useful to label moments for programmer readability.

Regarding AOP

My experience with Aspect Oriented Programming is only academic, and limited to AspectJ. And very limited at that. I know very little about AOP, or even AspectJ. As such, I welcome an expert insight into the matter.

AOP attempts to solve similar problems to Moments, namely by making code easier to manage with regards to the natural difficulties that arise from scattering and tangling. From what I understand, aspects tackle the issue of scattering by allowing a programmer to add what would be a copy-paste job spread throughout the code base to a single location, and aspects also tackle the issue of tangling by allowing a programmer to separate concerns (such as logging) from the actual method call to keep the method clean. However, they do not remove the responsibility of sequential reasoning from the programmer’s already busy mind. AspectJ has three kinds of advice: before, after, and around. “Before” advice gets executed before the join point it is assigned to, while “after” advice gets executed after the join point. Neither of these escape sequential reasoning. The third type of advice is “around”, which is similar to method overriding in OOP in that it can either replace or augment the join point’s code. Even if you choose to augment the join point, you must specify when the original join point gets called (via the proceed() call). Moments, on the other hand, have no “when” to answer to — or, more accurately, moments have precisely one “when”, for they are temporally atomic. Anything happening at the same moment neither happens before nor after anything else in that moment.

I believe that there is a lot to be taken from AOP though. I have some AOP-like thoughts on modifying moments from distance places in code, but that topic should be an article of its own.

Summary

To summarize:

Moments are sets of instructions where order does not need to be specified by the programmer. Moments must be dependently safe: there can be no dependency cycles among the statements. Moments must also limit assignments to one per variable per moment: a variable can not equal two or more different values at the same moment. Any violations of these rules will be caught at compile time.

Moments make life easier for the programmer by deferring the determination of instruction order to the compiler for a well-defined set of instructions. On top of freeing up programmer brain cycles to focus on the problem at a higher level, this can have other benefits as an IDE could be made that sorts statements in a moment based on the programmer’s desire, independent of the original order the statements were added.

Please note that moments are a proposed language feature, not a ubiquitous necessity. It is perfectly fine to have sequential logic in the code that does not fall into a moment, just like it is perfectly fine to have procedural libraries in an OOP language, or vanilla Java in AspectJ.

On this night I didn’t do very well at the game, so it left me frustrated. And now I just feel like ranting about random topics.

Strike Witches

Lately I went on an anime streak. Some sudden impulse within compelled me to collect as much random anime as I could, and then sit motionlessly before my screen watching the imagery go by. Some of it was awesome, some of it mediocre, and some of it I couldn’t stand one entire episode.

Strike Witches falls into that last category.

I keep seeing that show pop up on torrent sites that I frequent, which leads me to believe that someone actually enjoys that show. Strike Witches is completely fucking retarded. Here’s what I remember from the first episode:

1. Aliens attack Earth with seriously awesome technology. Somehow the planet isn’t completely enslaved.

2. We develop technology to fight back against them. (Original plot so far—don’t you agree?)

3. That technology turns out to be leg attachments that give a person the ability to fly at incredible speeds.

4. The military, after developing this cool technology, hands it over to girls who have to be somewhere between the ages of eight and fourteen. Because who the fuck knows why.

5. Oh and some of the girls know magic.

6. And one of them has a fox’s tail, did I mention that?

I simply couldn’t tolerate the furry-mecha-lolita combination that is the heart of Strike Witches. Oh and then there was this guy here, who helped created those mechanical legs:

I wanted to point out this image from the first episode because I realized something important when I first saw it: any anime character you ever see in a sepia flash-back is dead. I didn’t even watch all of the first episode, but I can tell you right now that guy is dead. That’s just the standard. And I never realized it until watching Strike Witches.

I suggest you stay away from Strike Witches at all costs. And if you actually enjoy it, I would love to hear why, so please e-mail me and let me know how it’s even tolerable to you.

The Phone Book

I am tired of coming home and finding a fucking phone book left in front of my door. I don’t know how frequently this happens, but just from where I am sitting in my living room, I can see five phone books. They have accumulated in less than a year.

The phone book is ‘The Yellow Pages’, put out by AT&T. The most recent one tossed before my abode was the ‘Companion’. In other words, a smaller, more compact phone book. It is meant to serve as an abridged reference to the more bulky, primary phone book. Or at least that was my interpretation. Flipping through it gives you the impression that it’s just a collection of advertisements; maybe there aren’t any phone numbers to begin with.

So today a co-worker was telling me how he got a three-hundred dollar ticket for throwing a cigarette out of his car. But the mother-fuckers at AT&T can dump the Oxford English Phone Book in front of my home as often as they want, and that’s some how legal? I view their product as garbage, and therefore they are littering. If I were to turn right back around and throw the phone book in front of their offices, I would get fined for littering. To me that’s just horse-shit. How does AT&T have the right to arbitrarily burden me with disposing of paper waste? When I’m done with a box of pizza, I don’t go back to Papa John’s and throw the fucking box before them and demand that they dispose of it for me. But phone books are special—you can’t litter if the object you dismiss is a phone book.

Just try it. Next time you’re riding down the interstate at seventy-five miles per hour, throw a phone book out your car window. When the police officers arrive at the scene of the accident, just tell them AT&T did the same to you. (Note that this advice is probably bad and should not be followed, but deep-down I hope you do.)

Medicine

Man I hate taking medicine. First of all, I can’t swallow pills. No matter how tiny. I just have a hard time doing it. It was great when I was a child because my mother knew she would have to hide the medicine inside of something to trick me into digesting it. Which meant I would get a surprise tasty treat, like pancakes with strawberry toppings—and hydrocodine. “Hey I feel kinda funny…”

I sometimes get severe pain in the left temple of my head. I’ve been taking medicine for that pain for quite a while, but naturally my body built up a tolerance, to where I was having to take more than I really should to ease the pain. So recently my doctor bumped me up a notch to some new drug. He warned me it may make me feel tired, that I shouldn’t take it and drive, all that typical drivel you hear and see on the labels of pill bottles.

Holy shit was he not joking.

My temple was starting to hurt, so I took one of the pills, and some ten minutes later I was in fucking Hallucination Land. I thought that

1. I broke my keyboard into many pieces.

2. I went out to dinner with two friends.

3. I played Dance Dance Revolution.

Absolutely none of those things happened. In reality I was rolling around in my bed, flipping out. My head certainly didn’t hurt at all, but it is a very jarring experience to genuinely believe you did something that didn’t actually happen. I’m sure every one of you gets that little bit of doubt sometimes when you wake up, about whether that dream was real or not. Then you smack your alarm button and by then you realize you’re in the real world and away from the shackles of your mental fantasy. That was not the case for me. I don’t know how much time passed, but it was enough for me to think a lot of shit took place.

So that’s just super fun. I’m worried I’m going to have to take the medicine one day, and then when I come to I’ll be standing above a few dead bodies in a hotel six-hundred miles away from where I live, with only a note lying nearby that says, “The Phoenix flies at dawn”, written in my own hand-writting.

Speaking of which—medicine, not the Phoenix—time for me to take my nightly dose and hit the hay, as they say.