Kfitzat Ha’derech

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 .

This entry was posted on Sunday, June 21st, 2009 at 4:24 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.