Kfitzat Ha’derech

OK, so the whole notion of having separate textures and pictures is stupid. What I actually want to do is render to surfaces, yielding surfaces with things on them. Paths can be stroked, filled, or textured to yield pictures. Pictures can be rendered to yield a surface. Now, Escher’s conception of a surface should not just be a big bitmap or a printed page. It should be a surface with a clipping path and a transformation matrix.

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.

Start with high-level decisions and any obvious implementation details.

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 .

Tonight we had a bit of a conversation over whether stupid Anne Rice-style vampire romances such as “Twicraplight” came from something inherent in the trope of vampires in general or had grown as a phenomenon. Eventually, everyone came around to Lauren’s point of view that vampires tapped into the fantasies of threatening lovers and into rape fantasies, which apparently have existed since “the dawn of time” (those readers who fantasize about the most horrific act one human being can inflict on another without special training can leave now).

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.