JavaScript Fun

In the Berkeley compilers course I am TA'ing, we were going to have the students implement a JS1.5 to Python source to source translator. This would be bottom up: they wrote their parser generator previously, so now they would write the convoluted JavaScript grammar (an ANTLR3 grammar took pages), complete with line ending sensitivities (with and without semicolons etc), and then generate python code that would access hooks into a JS pseudo-interpreter. Unfortunately, I leaked the first part by accident in the previous assignment as a test case, and while coding the reference solution of the second, I became bored and unmotivated.

Instead, on Friday evening and Saturday I modified the grammar to support ES4 (JS2) class inheritance, sans namespacing and innerclasses, and wrote the corresponding pretty printer. Today, I added the optional type annotations to the grammar and built the symbol tables necessary for type checking. Tomorrow, the type checker. While parameterized, structural, and nullary types are a bit beyond the scope of the assignment, I did add something ES4 does not have for some inexplicable reason: higher order types. Subtyping functions is a good time :)

Incidentally, on Reddit, there is a big stir right now about garbage collector in Firefox suffering from heavy fragmentation. While people are suggesting many convoluted solutions, I'm wondering if an easy interim solution is possible: take advantage of virtual memory, so that even if there is fragmentation, it'll be paged to disk. This is a big insight of generational collection, but can be achieved without explicit generational collection algorithms.

On a sadder note, Rob mentioned interest in seeing some of the digital artwork I've done through the years (with most of the highlights being concert posters for various flavor of the week rock bands while I was at WBRU), and I realized that, with all the computer migration I've been doing in these past 8 or 9 years, I have very little left to show. Eg, I could only find an early draft of a poster I did for Guster, as well as some high school era photo and flash pieces. Some signed posters are still in a box in my room, and if I can find the cable to my external HD, I may be able to find some source files (I really want to get the one for The Living End poster), I may be in some more luck. Chris wanted my concert photos for the insert art of an live in-studio recordings WBRU album he is producing, and they're all trapped on that darn drive.

Edit 12/05/2007: I could not find any examples online of higher order types in EcmaScript 4, so I assumed there was no support for it. After some scouring, I found an example of defining a function type. Running in the EcmaScript 4 reference implementation shell, we see all is well:

>type bTi = function (boolean):int
>var z : bTi = function (x:boolean):int { return 1; }
>z(true)
1
>z = function (x:boolean):int { return 5; }
>z(true)
5
>z = function (x:boolean):int { return "hello"; }
>z(true)
hello // uh oh
>z = function (x:boolean):int { var s : string = "hello"; return s; }
>z(true)
hello // hmm...
>z = function (x:boolean):string { return "hello"; }
**ERROR** ...

I would have expected a type error on cases where I annotated the return type with "int" but actually returned a string. Going further:

>z = function (x:boolean):int { return 1; }
> type bTiTi = function (bTi) : int
> var c : bTiTi = function (f:bTi) : int { return f(true); }
>c(z)
1
> c = function (f) { return f(true); }
> c = function (f:int):int { return 1; }
**ERROR** ...

So, while returns are not checked against declared return types, function parameters seem to be. I should read Cormac's stuff more closely to understand what the heck is going on - this seems to be a lot of annotation for not a lot of checking.