The game follows your career, starting at your first internship in undergrad, in media theory.  You spend years in university, and whenever you try to get an internship or co-op you end up at a large media corporation with a remarkable resemblance to Fox News.

You parkour your way through a wide-open world to get the random stuff your boss wants.  As the game goes on, you acquire skills like waving a press pass, stealing vehicles, causing a spectacle, hand-to-hand combat, and even short-range teleportation.  Your ultimate goal… TO TAKE OVER THE COMPANY!!!!

Jump rooftops, misdirect crowds, infiltrate secret locations, ride subway cars on the roofs… and become the one, the only, THE ULTIMATE GOPHER!  And at last the CEO of a major media corporation.

On the other hand, does it have any kind of OpenGL support? Vector graphics as used in Escher are much easier to convert into OpenGL than 2D framebuffer operations.

EDIT: Cairo looks much better and supports the rendering model I’d like natively. However, it appears to have limited support for OpenGL, but let’s see what’s what.

In fact, one should render to a surface yielding another surface (this time with the actual backing bitmap or page changed, duh). This makes the type of the render method render: (window,surface) -> surface. Yay. That actually makes the whole conception of how it works to place windows much easier. The owner window has some spot it wants to render the child window into represented by a clipping path and a transformation matrix. It can take the surface it was given to render into and apply those to get a new surface value that it passes to the child window. Child window renders to mutate the surface and returns it. Wallah!

So, operators with surfaces for rendering things…

subsurface: (surface,matrix,clip) -> surface
render: (picture,surface) -> surface

Well what do those look like in syntactic terms? I already have a “compose” operator that puts paths and pictures on top of one another.

x -> y means x rendered on top of y, or y rendered followed by x. I can easily just add the capability to take a surface as the second operand and do rendering that way. Oh, and x -> y where both x and y are surfaces blits x onto y.

x:(y,z) means to yield the surface x subject to the transformation matrix z and the clipping path y. Looks good enough.

Add a library function for inverting a matrix. Actually, for a two-dimensional world would a quaternion (3 floats), a scaling vector (2 floats), and a translation vector (2 floats) be less floats than a 3×3 matrix? Well yes, but then I can’t compose operations by matrix multiplication. Well I do have first-class functions, so what the hell do I need composition by matrix multiplication for? Oh, right, speed. It’s faster to compose 2 functions into a new function, but slower to actually apply the composed function than to vector*matrix multiply. Well, actually the matrix approach gets cheaper with the number of operations composed.

Anyway, my standard library ought to include functions for making rotation matrices, scaling matrices, translation matrices, and inverting matrices. This will help in dispatching input events that specify a point inwindow: just check clipping paths for a sub-window it falls in and then multiply the input by the inverse of the transformation matrix for that sub-window.

Base it on the Actor model. Every window is an Actor in the software, though messages must arrive in the order sent. Sending a message looks and acts like a function call (ie: it can expect a result and works synchronously) by default, but an option will exist to send an asynchronous message. In order to make this still behave like a function call, the result of an asynchronous message send is set to a future of the result. Attempting to evaluate the future waits for the reply message containing the result to arrive and returns that result when it does. All messages consist of a name and parameters, and the ability to send them to any other window is statically-typed.

Each “frame” it receives messages as events, which are handled using event-handling constructs. A special message message called render must have a handler that returns renderable data for putting on screen, and this message will go to the window every single frame. Each event handler is basically a function/procedure, and in each such function a window can also choose to send messages (including the one triggering the event) to either its master or to any window to which it has a valid reference. A window’s “master” is simply an abstract source and destination for messages (implementations can include IPC or sockets), every window must have a master.

Base the rendering primitives on Postcript, PDF, and/or Quartz, but with the addition of a picture subtype called a surface that represents a fully-drawn picture in memory and can be attached via texture coordinates to a path to texture it. Add various sorts of 2D video processing or post-processing techniques as functions from pictures to pictures. Remember to include geometrical functions for creating and transforming the points in a path. Possibly add pixels or point particles as a type of picture so as to support effects that make liberal use of putpixel()-type ideas.

Garbage-collect memory, even though most allocations should be static or assigned to the state variables of a window.

Data types: real numbers, natural numbers, points, matrices, arrays/lists, structures, unicode strings, paths, pictures (including surfaces), windows. Composite data type and modular unit: window. Should there be first-class functions? Local type inference? Representing messages as functions/lambdas would certainly be useful.

Let windows be defined like classes, including with generics — they have instance variables that serve as their internal state and methods corresponding (by name) to the messages they can handle. Window types require a constructor which takes not only an implicit this parameter but an implicit owner or master parameter referring to the message destination that runs the real computation to which this window interfaces. Windows types can also inherit from a parent type. One window type in a program must be called Main, and this window type is the one that the runtime system creates an instance of as the root window.

Every window theoretically runs in a separate lightweight process (ie: shared nothing), but the actual management of concurrency is left up to the runtime. Every method is by default synchronized and locks a mutex guarding all the internal state of the window on entry, releasing it on exit. As an optimization technique, methods that don’t access any of the internal state of the window may run without locking.

A window can access its own instance variables and those of any instance variable whose type is window. Every window has an implicit owner instance variable of the special type socket (or similar name with the same meaning).

Implementation details: do the I/O with SDL and OpenGL where available. For speed, don’t interpret programs in this language, JIT compile them using LLVM.

This owes its ideas about windows and messaging to Smalltalk, its rendering ideas to Functional Postscript, and its concurrency ideas to Erlang.

Need to keep nitty-gritty details more secretive to have material left over for senior thesis/Capstone project .

Ah, but I’ve come to realize that they do, in fact, come from a source: vampires. If they actually existed, what better way to lure in victims who won’t fight than to portray themselves as the ultimate in forbidden lovers? Convince millions of dumb tween girls and budding tween BDSM guys that they can find the ultimate good time for their pure, virginal selves with an undead, creature-of-the-night abomination against God, and the kids will line up to die horribly! Only selling heroin to addicts gets easier than this!

So I don’t care if they work according to “Let the Right One In” rules, traditional “Nosferatu”/”Dracula” rules, “Carpe Jugulum” rules, or “Buffy the Vampire Slayer” rules. They all must die, or at the very least we must reduce the threat of annoying wannabe vampires to our species.

I have the answer! Vampire romances work by portraying the unholy as forbidden lovers whose very presence can bring about a blissful serenity and whose touch can ignite the blood. See, those descriptions sound good and I’ve just lifted them from other sources! Of course, the emphasis here lays on forbidden: even the dumbest tweens tend to moderate themselves in the unhealthy pleasures that come commonly and mundanely. Try to find a large, nationwide clique of rebellious little moron who, for example, get high by overdosing on caffeine or through erotic autoasphixiation (seriously, only Fox News thinks real numbers of people do that).

Thus, by releasing a major motion picture in which every teenage girl gets given to a vampire at her sixteenth birthday for the satiation of her perverse sexual lust and his sheer, predatory thirst for blood only to find him treating her with contempt and screwing other women in nightclub bathrooms, we can finally convince tween girls that vampires suck and all must die. Honestly, I think once that happens the young boys will follow, as most guys just don’t have rape fantasies.

Presto chango, vampire fad problem solved and possible threat to large segments of the human race (let’s call it “blood-terrorism” to get government defense funding) averted!

In other news, I’ve begun experimenting to see if I can build a Naive Bayesian Classifier that will, by content alone, tell the difference between a reliable news report and some bull that someone just made up on the internet.

And people want Israel to make peace with this: an organization that will not even obey its own leader if he gives that most heinous, sinful, and harum (Arabic for “forbidden”) of orders, to stop firing. It really does appear that people don’t understand the Palestinian situation. The Palestinian situation is that if a Palestinian of importance tries to moderate his approach or even simply cease violent action temporarily for strategic purposes, he risks disobedience at least and murder at worst. Even back in 1967, Palestinians told Israel that they could not accept a state in the contiguous, then-unsettled West Bank and Gaza Strip because Yaser Arafat would kill them. Thus, violence has become the Palestinian disease, a overriding all other approaches to life for its own sake.

This is why Jews and Israelis tell a joke about ceasefires. We know that when the UN or someone else presses us into a ceasefire with our foes, it means that we cease, and they fire.

Well not me, nosiree!  Instead of completely destroying programmers’ ability to statically allocate lexical variables of object type (which includes closures, in theory, since in theory closures and objects are equivalent), I’m just going to make it illegal to perform covariant assignments or returns.  Deca will still allow assignment from an alias to a subclass to an alias to a superclass, however, and it will also maintain the ability to pass arguments to functions by reference.  Combined, these will allow programmers to create and allocate static lexical variables of object or closure type and pass them freely into any function that accepts the correct superclass or function type, while still requiring programmers to use dynamic allocation or aliases to global, anonymous variables to pass objects and closures of dynamic type up the call chain.

To rationalize this design decision, sometimes a systems-programming language should expose the ugly guts of variable storage, right?

Well no.  Because I want to add first-class functions to this language.  Therein lies the rub, because any function passed around as a first-class value could, and often does, have a closure environment of some sort with it.  However, the signature of the function, which would normally be its whole and entire type in a functional language (Function of x, y, and z returning an a and carrying a closure pointer that may be null…), cannot possibly be its whole type in Deca, because Deca has to run without (language-supplied) garbage collection and therefore the size of every single data object passed into or out of a function must be known in such a way that the compiler can theoretically (that is, before optimizations like passing arguments in registers) allocate that object on the stack.  As I’ll explain below, this is a problem.

So far I’ve been using the idea from D (as in Digital Mars’ D) for compiling closure expressions: create an anonymous class to contain the variables the compiler infers as closed-over by the function definition, with a “call” or “operator()” method that (other than its closure-object argument, which the compiler automatically passes like a “this” pointer despite Deca being a multiple-dispatch language) has an identical signature to the function as the programmer defined it.  Calling an instance of such a class (ie: “f()” where f is of a function type) calls the correct (as determined by runtime dispatch) “operator()” method with the given arguments and the implicit instance of the closure-object.  To make all this more than mere syntactic sugar for anonymous classes, all “closure classes” are direct subtypes (meaning no closure class is a child of another closure class) of an abstract supertype (with no closed-over variables at all) that simply represents an old-fashioned, C-style function pointer with no closures involved.

By now you probably see the problem yourself.  If I have to define the type of an argument to or return value from a function and I define it as a function type, how much space should the compiler allocate on the stack to pass or return such an “object”?

For arguments I can simply use pass-by-reference, of course.  The compiler allocates space for a pointer, does its type-checking and uses old-fashioned RTTI to determine what the function actually got at runtime.  But I anticipate that programmers (not in the least myself) will actually want to pass a function by value at some point.  Actually, even old C has variadic functions that determine at compile-time how much memory is needed on the stack for their arguments, but I’m sketching this part out to show how much harder the hard case is in contrast.

What about return values of function types?  Or more generally, what happens when I declare a function as returning an instance of a certain class and then attempt to actually return an instance of one of its subclasses?  How do I avoid resorting to pointer semantics here?  C++ seems to handle it somehow (see the attached C++ source file to test the language’s behavior), so I guess I should start by disassembling my C++ binary.  If anyone has an idea that doesn’t involve disassembling a binary file originally written in the Shub-Niggurath of programming languages (I didn’t wear my Magen David when I did it, so my soul may or may not remain in my body), please feel free to leave it in a comment so I can steal it!

Happy hacking to all!  Here’s the source of the program I wrote to see how C++ handles this stuff.  It compiles under Linux with g++, and uses weird “flds/z/cw”, “fucompp”, “fnstsw”, “fistpl” and “sahf” x86 assembly instructions that I’ve never seen before.  TO THE INTEL BIBLE!

class Parent {
public:
virtual int foo(int bar) {
return bar + 1;
}
};

class Child: public Parent {
int quux;
public:
int foo(int bar) {
return bar + quux;
}
Child(int i) {
quux = i;
}
};

Parent baz(float x) {
if(x < 0.0)
return Child((int)x);
else
return Parent();
}

int main(int argc,char** argv) {
return 0;
}

Yeah, gorram WordPress doesn’t let me attach .cpp files.  They don’t meet its security guidelines .

EDIT: It turns out those funny instructions are floating-point instructions.  Made x an integer now to get rid of them.  The code still looks weird, but interpretable.

AGAIN EDIT: It appears the language feature I’m looking for is called return-type covariance.  So yeah, I need some way to return values of covariant type to my declared return type on the stack.