Functional Form

Avoiding side-effects since 2004.

Monday, March 27, 2006

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.

0 Comments:

Post a Comment

<< Home