Top of the “for fun” stack looks like this:

• Write, write, write. My book is not moving along as fast as I had hoped. In fact, I'm waaaay behind schedule. Thankfully my publisher's understanding, but I'm certainly testing their patience!
• Finish reading the two books I picked up recently:
• Concepts, Techniques, and Models of Computer Programming. All I can say is wow. I wish I learned programming with this as my guide (along with SICP). Great focus on declarative, lazy, functional, parallel, higher order programming. Reading 800+ pages from cover to cover is really difficult. Sleep? What's that?
• Parallel Programming: Techniques and Applications Using Networked Workstations and Parallel Computers. Pretty good read thus far, although I'm only ~100 pages into it. Drills into parallelism at the hardware and software level, including message passing and shared memory techniques. Some of the most interesting bits are in depth inspection of common algorithms under a parallel torch. Nice.
• Fix bugs in Sencha, especially in the area of quotations. Get more of the SXML, SXSLT, etc. stuff implemented. Work on platform interop. Finish up the standard library functions. VSIP. Interpreted mode? Found some interesting dynamic bugs recently due to the way I statically bind at compile time. Only crops up when working in the toplevel, but (interestingly) this is a pretty big use case for Scheme programming. ;)
• Get HaskIL off the ground. I've done some work, using GHC Core as the one real truth, but not nearly enough. Need more time. I'm really excited to work on some of the lazy and parallel aspects of this project... gotta get over the hump first.
• Put my two forks of Rotor back together. I'm learning to navigate the JIT and EE interactions a bit better, although I've come to a particularly unsurprising conclusion: the CLR is a complex beast. I haven't been able to get either of these two things to actually run a program that takes advantage of the changes I've made. Ugh.
• First class continuations (and coroutines) in the runtime. My approach here is to capture stack state and wrap it up in an object. This can be used to restore at a later point in time. You just call the static method System.Threading.Continuation.Capture(), returning a Continuation instance c; then later you can call c.Restore(). Makes it pretty easy to implement call/cc. I'm now at least a little proficient in writing fcalls; all the whacky macros are making my head hurt. Interactions between stack unwinding and restore is a tricky thing, and I'm finding that CAS is a pickle. My current design does a stack crawl and throws if it notices any type of assert or demand... not for technical reasons, but because it seems pretty bad to capture this and pass it around. Similarly, I fail if you're inside a try { } ... finally { } block since shared state can munged up in a finally (which gets torn down as part of the stack unwind). One of the huge difficulties here is state which doesn't get represented in data structures that the EE knows about--for example, JIT only stack frames. In fact, I'm slowly realizing that this might not be possible without an explicit level of indirection with stack management.
• Software transactional memory. System.Transactions is one step in the right direction. I'm interested in retry-style STM support, however, directly baked into the runtime. Some of the MSR folks have been doing amazing work here. This one's a tough nugget, too. You can't know statically if you're inside a transacted block--unless you limit transactions to simple blocks w/out function calls--so when you JIT a memory access, it's pretty damn tough to figure out the right thing to do. Ultimately, you don't want to add a level of indirection for each memory read/write. But this is what I've done thus far, mainly because it's a step in the right direction. Further, you can't safely retry stuff that does I/O, so I'm building a constant list of “known“ I/O routines in the BCL. This is crap and doesn't scale. I wish we had monads in the runtime... or at least some form of annotation so that I knew what library call ended up doing I/O.
• Did I mention I have a book to write?

I was thinking tonight: it'd be freaking awesome to have a pure functional language based on Haskell's laziness, pattern matching, and approach to I/O (monads). But with a paranthetic syntax, along with lists like Lisp/Scheme. Wow. Does it exist?

Perhaps I'll go and *do* something now. Instead of just talking about doing something.