Thursday, November 29, 2007

Something like Lisp

Ever since compilers class in college, I've toyed with the idea of creating a new programming language. Every year or so a spend a few days thinking about one and get off to a short start. The problem is I often try to bite off more than I can chew and start dealing with the most difficult parts first. So I recently decided to get a minimal language up and running. Something with simple syntax, no concern for efficiency, and an easy to build base.

Lisp has some of the simplest syntax of any of the languages I've worked with (perhaps with the exception of BF). I was looking for something simple which I could quickly implement, so I used it as a model and created an interpreter in Python. The whole project took just a couple of hours, but I was able to write an interpreter that would run the following program:
set[x 5]
set[x add[1 2 3 4 5]]
set[y add[1 2]]

As you might have guessed, this program displays the following in the terminal:
I implemented a simple parser using Python's regular expression module re (The group method can come in quite handy), and I defined each of the above functions in a dictionary which maps function calls in my custom language to functions in a Python script which I import. You might have noticed that each of the methods is designed to take a variable number of arguments (thought only they may not all be used), and all function calls are made recursively, with nested functions being evaluated first. The syntax looks slightly like s-expressions but it's a bit more accessible for someone who has worked with C-like languages (except there's no need to reach for the shift key for those tricky parenthesis). I haven't added a mechanism for lambda expressions yet, but defining new functions might look something like this:
function[my_fun group[x y] group[multiply[x add[x y]]]]
The above would define a function named my_fun which takes two arguments, and multiplies the first by the sum of the two arguments.

I just made up this micro language, and haven't given this a great deal of thought. The idea was to create something quick and dirty to create a working interpreter, rather than the usual of intense planning without a working prototype. This language will probably never see any further development. It was a mental exercise, but I found it quite enjoyable. If you'd like to see the source code for the interpreter, please let me know (I get the feeling Matt might be somewhat interested).

Monday, November 12, 2007

Fluxbuntu 7.10

Long time readers may remember the saga of my old laptop (a Compaq Presario 1700T circa 2000). I had ditched openSUSE several months ago in favor of Fluxbuntu, a variant of Ubuntu which used the light weight Fluxbox windowing system in place of the Gnome desktop. My old computer has only 128 megabytes of RAM, so memory is at a very high premium. With the release of Gutsy Gibbon, Fluxbuntu picked up a few new features, so I upgraded and gave it a try. I have been extremely pleased. All the good stuff is there that I enjoyed before (installing new free software using Synaptic or Aptitude, Firefox, XMMS, etc.) but there were a couple of great new additions. For one, automounting of USB drives. I have a small pen drive that I carry around to hold many of my files: music, programming projects, etc. Mounting had always been a bit of a pain with my laptop's OS. Now I just plug it in, it mounts, and an icon for the drive appears on my desktop.

The discovery came at a perfect time. My in-laws decided they wanted to resurrect an old PC so they could browse the web side by side. All they really needed was Firefox, Open Office, and Picasa and their computer had the same amount of RAM as my old laptop (probably from about the same time frame). Fluxbuntu to the rescue ;-) Can you believe it, my in-laws are running Linux.

Thursday, November 08, 2007

IE, XMLHttpRequest, and caching

I recently noticed an oft cited irritation with using XMLHttpRequest in Internet Explorer. Turns out, the browser intercepts HTTP GET requests made from within JavaScript and gives your Ajax application a cached response instead of fresh data.

I was running some tests on scorpion_server, using the JavaScript client in the example that I've packaged with the server, and I noticed that I could change the data stored in a resource when using IE6, but I couldn't get the value I had just set. This means my client-server pair is pretty much useless in IE6 (probably 7 too). But I thought of a solution. IE is just performing a test for exact match when checking the cache, so if any part of the URL is different, IE will actually perform the query like I want it to. So I added a timestamp URL parameter to all GET requests made by the client if the browser is IE, and I configured the server to ignore all URL parameters on GET requests. I wasn't using them anyway, perhaps someday I will, but I don't foresee a need because all I want is a super simple remote data store. (Who knows, YAGNI might just be my new mantra.)

Note that IE was the only browser (of those I tested) that exhibited this annoying behavior. Mozilla based browsers (Firefox, SeaMonkey, Flock), Opera, and Safari all behaved correctly and don't require the timestamp URL parameter hack.

Sunday, November 04, 2007

JavaScript client for my Scorpion Server

I've added a JavaScript client to the simple web server project: scorpion server. The client is able to set the username and password and make authenticated GET and POST requests to retrieve and modify resources on the server. Now that this portion is complete, I'm ready to rebuild my Ajax Wiki application to run on top of this simple web server.