asgaard

My favourite JavaScript bug

Mon, 27 May 13 18:41:00 +0000

To be clear, this isn't a bug *in* JavaScript, it's a bug in my own code. But one which various properties of JavaScript made it both easy to write and very hard to detect later.

I am currently writing a LOLCODE interpreter in JavaScript. It's not overly complex - it just recursively evaluates an AST directly.

LOLCODE allows for user defined functions:

HOW DUZ I ADD YR NUM1 AN NUM2
  SUM OF NUM1 AN NUM2
OIC

VISIBLE ADD 1 AN 3 MKAY  BTW => prints 4

The AST for the function definition looks something like:

{
    "_name": "FunctionDefinition",
    "name": "ADD",
    "args": [
        "NUM1",
        "NUM2"
    ],
    "body": {
        "_name": "Body",
        "lines": [
            {
                "_name": "FunctionCall",
                "name": "SUM OF",
                "args": {
                    "_name": "ArgList",
                    "values": [
                        {
                            "_name": "Identifier",
                            "name": "NUM1"
                        },
                        {
                            "_name": "Identifier",
                            "name": "NUM2"
                        }
                    ]
                }
            }
        ]
    }
}

The easiest way to evaluate this is not to do anything special to compile that function, but just to use the magic of JS to represent the evaluation of the FunctionDefinition node as an interpreter action in its own right, similarly to how we'd evaluate an identifier or any other construct.

If we can create a function which represents the evaluation of 'ADD', then we have a nice consistency with evaluation of built-in functions, which are implemented natively, like SUM OF, e.g:

lol = function() {
    var self = this;

    this.symbols = {
      'SUM OF': function(a, b) { return a + b; }
    }


    var evalFuncDef = function(node) {
        self.symbols[node.name] = function() {
            return self.evaluate(node.body);
        }
    }

    this.evaluate(node) {
       // delegate to appropriate sub function
       if (node._name === 'FunctionDefinition') {
           return evalFuncDef(node);
       }
    }
}

I've omitted setting up the argument list, figuring out the return value, etc, but the basic point is that both 'SUM OF' (a native function) and 'ADD' (a user supplied LOLCODE function) both exist in the symbol table in the form of an executable JavaScript function.

It's a fairly innocent looking piece of code.

Except for one thing.

The interpreter also has the ability to pause the program and evaluate watch-statements, like what you'd find in Firebug or Chrome's debugger. For various uninteresting reasons¹, the easiest way to do this is to clone the current symbol table and other scope into another interpreter and execute it there.

Something interesting happens here.

In the above code, I've used the this/self idiom to get a reference to the current object into a nested function.

When we clone the symbol table into a different object, the self reference comes across unchanged. What that means is that the second interpreter happily executes any expression you give it correctly, until you supply it with one that tries to invoke a user written function. At this point, the first kicks into action, and continues executing. Imagine how difficult to debug this was - you can trace it all you want, you will see you're always in the right functions. The key is realising you've suddenly switched to the wrong object, which in this case, always has very similar (if not identical) state!

The solution to this is obvious - don't rely on self inside the function we create, instead require it to be called with symbols[node.name].call(this, ...).

But the bug itself is admirable in its subtlety.
____
1. Mostly to do with keeping track of an awkward asynchronous callback. Call it an 'implementation issue'.

I'm going to do something with loljs

Sun, 28 Apr 13 22:46:10 +0000

loljs is a pretty rubbish LOLCODE to JavaScript translator I hacked together a few years ago before I really knew JavaScript. It really is rubbish, half the time it will crash on bad input and give absolutely no indication that it has done so. But according to traffic stats, people love it.

It hit the big time (sort of) after a (relatively) popular YouTube channel video used it for a "how to learn programming video".

lolcode is not a sensible way to learn to program. But it strikes me that it is a sensible way to learn some things about programming languages. lolcode has the nice pair of properties that it's powerful enough to express normal programming constructs while being small enough to be able to keep the whole language's structure in your head at once. It's also amusing.

I would like to relaunch loljs as:

A more robust compiler/runtime.
A well featured text editor.
Something to visualise the relationship between the lolcode and the way a compiler sees it.

I have started writing the compiler using Jison, instead of the rubbish and buggy hand-written parser I had before. I am currently working down the route of interpreting the resulting tree instead of translating it to JS, as this gives a bit more runtime control and better error feedback. It's also easier and more fun than messing around with creating strings of JavaScript code and having to worry about how safe they are and how we figure out relaying runtime errors back to the user.

For the text editor I'll probably use CodeMirror and write a custom mode.

The third point needs more thought. I like the idea of being able to hover over blocks of code and see some representation of the syntax tree for that fragment. The first version will probably just show some nicely formatted JSON, but I wonder if something clever could be done with Canvas to display a real, explorable tree.

I am only working on this in my free time, so it might take a while.

Popularity is the hallmark of mediocrity

Sun, 26 Aug 12 10:31:09 +0000

So said Dr. Niles Crane, quoting an unspecified "great man".

I've sunk a lot of hours into building various different programs. Partly because I enjoy it, partly due to necessity and partly because sometimes I genuinely believe I'm creating something useful. The latter encompasses a bunch of my projects and with these I aim for painstakingly high quality because I want people to use them. I spend hours making sure code is written and formatted well, making sure unit test coverage is good, and ensuring that APIs are well documented, etc.

And then we have loljs. loljs is my LOLCODE to JavaScript translator/interpreter. It's a proper translator with a recursive descent parse, not just a hideous regular expression thing, but it's still pretty rubbish. Probably its one saving grace in my eyes is that it correctly converts LOLCODE's prefix notation to JavaScript's infix notation for operators with arbitrary arity. I wrote it as a "let's learn JavaScript project" in about two days. It's very rough, the internals are awful (it's pretty obvious I didn't know JavaScript) and it's not exactly easy to use.

And yet it's had literally thousands and thousands of visits. It's far and away the most successful project I've done. Even taking into account professional projects, and I've worked on some for a few big names, I think loljs is a pretty strong contendor in the popularity stakes.

It's recently been the subject of a "learn to program" video on a popular channel on YouTube and according to my primitive stats, it's had six thousand views in the last 36 hours (not *all* from YouTube). Which is great. My web host is earning their monthly fee. I'm very happy. I just wish you'd all be so interested in the stuff I spent more time doing.