Next week I am going to start taking a course in linguistics at UCLA, but I'm not quite sure which. My two options are both taught by Daniel Büring, who I emailed earlier this week about sitting in. One is a seminar about focus and intonation and the other is semantics 2. I'm kinda leaning toward the latter but I have to think about it. I really think I only have time for one, seeing how I have a full-time job.

She don't like she don't like she don't like

I'm trying to take Emma further into the programming fold (no pun intended). I helped her learn Scheme a while back which was a very good first step for her. It definitely complemented her semantics interest nicely. But Scheme is not exactly a champion when it comes to getting anything real done, so we've been hovering around a few practical languages trying to choose one that I could be happy working on with her. First it was Ruby because as mentioned previously I had this brief hope that I would settle on it as my web-language-of-choice, and I thought we could work on web projects together. But that dream died in my annoyance with writing scripting code on a paper-thin database abstraction and doing lots of redundant tasks. Rails put me to sleep, so it was hard to push Emma to take it up with much gusto. Now we've settled on Objective-C, and I think it's going to be good. At first I just sat her down and made her read the introductory developer docs like a shot of tequila before we wrote anything. That's my preferred mode of learning... like everyone, I'm an "active" learner. But I like to know as much as possible before I become active and learn against a conceptual framework that is cohesive and deep. Apparently Emma isn't that way, and she was complaining rather quickly and itching to write some code. But I couldn't bare to have her write a freaking currency converter, and I couldn't find any cool tutorials. But last night I solved the problem. We're going to work through Essentials of Programming Languages and write our own language interpreter. They teach it all in Scheme, which Emma already knows. We're translating it to Objective-C, so she can learn imperative object-oriented programming on a non-trivial problem and we both can learn about interpreters. It's going to be awesome. I have big plans for our newfound language making skills. And a cool name for our Cocoa-based dream scripting language: Cocaine. Cue the Eric Clapton guitar riff now.

Margarita post

Now for a lighter, perhaps bordering on inane post. I swung by and got a margarita with Emma, Kate, and Kate last night at La Barca. It was fun to be social again and laugh a lot. The four of us had a warm-feeling synergy that made me feel happy.

Das Editor

I worked quite a bit this weekend on the very initial phases of my grand plan for an OS X text editor. I bought TextMate some time ago out of a feeling of obligation since its Ruby support seemed ideal and I was all set on learning Ruby. Now I don't really have much use for it because I wasn't that impressed by Ruby and its Rubinista hype. It seems way too disorganized at its core even though it offers some nice syntactic tricks. Syntax can only get a language so far with me. So anyway, I've been brewing this editor idea for some time now. The plan is to integrate support for parsing expression grammars as the basis for a user-controllable extension language. The user defines emacsesque functionality, but rather than just loading this pile of code into an interpreter, the scripting code is attached to a continually-updated parse-tree of the document being edited. When a keystroke is entered in the editing window, the event of that keystroke is first sent to the terminal node containing the cursor. This node's grammar module code can handle the event or it can be passed up the parse tree, eventually reaching the root node. This would allow for relatively simple syntax-specific command handling to be installed. Non event-driven code like syntax coloring would also benefit from being nailed to a syntax tree. I am pretty certain that I've devised a way to efficiently update a context-free parse every time new text is inserted while maintaining the integrity of portions of the parse tree that have not been disturbed by the modification of the text. In addition, the grammar will be specifiable down to the individual character, with no need for tokenization, which I think is important in really making this model work well. So satisfied in the algorithm department (and implementing the early stages), I am still wondering what to use as my extension language. I am of course partial to functional languages, particularly Scheme-like ones. This is partly aesthetic and emotional, but I also think that the Lispy languages are very good "meta-languages" or languages that deal with language. All the PLT people love functional languages, and the PLT people are the ones writing compilers and interpreters. I think the user-experience for text-editing any language is directly proportional to how well the editor I am using can mimic the functionality of that language's compiler. But I have reluctance. Scheme was very inspiring but I'm getting pretty over it. Every implementation seems to fall short when it comes to practicality, and I don't quite know why. The shining hope is GOO, a pure Dylan-style object oriented dialect of Lisp heavily inspired by Scheme but a lot terser and seemingly better organized to get shit done. It's really really young and has barely any documentation, but everything I've learned so far impresses me. In particular, for my current purposes, it has an amazingly simple C-interface that lets you mix C and S-expressions together freely. I could imagine building quite a nice Objective-C interface in it. The one issue is the generic functions approach, which I am still unsure about. It's more expressive than message passing, but it still leaves you with this perspective that procedures, not classes, are fundamental. I don't quite know how to adapt it to the more message-passing centric idea for attaching code to nodes in a syntax tree. But it's Lisp right? If I want a message passing system it shouldn't be too much of an issue to implement it. An easier but potentially less powerful route is a Smalltalk-inspired extension language system designed specifically for Cocoa. It's called F-Script. But it just doesn't seem to have the cajones to step up to the plate as far as hardcore language modeling is concerned. I don't want to embed OpenMCL. But whatever language needs to be pretty powerful while being lightweight and easy to integrate. If you have any ideas out there in TV-land, email me. If anyone read this I'll write another maybe.