I have used Parsec. One of the most dramatic differences is that Parsec supports backtracking, and so it's a more powerful parser. Since parsing JSON doesn't need backtracking, I got to avoid both the complexity of implementing backtracking and the need to carefully avoid exponential backtracking blowups :D
This is an awesome piece of work - not just the code, but the whole tutorial/guide.
Previously (iirc) you simply used the input stream to keep track of the parse position - now you manage the input as a list of characters. I presume this is to allow backtracking from failed matches, or is there another reason?
My gut reaction to the idea of converting the input to a list was "OMG scaling issues!!!" but I must admit I've never had to deal with a really big json object.
Actually, all the various versions of my JSON parser have converted the input to a list of characters. I wouldn't be surprised if it did in fact turn to be slow, but I see it as an optimization issue: until I have (or someone else has) a program that's actually slow because of it, then I don't know if it's a useful optimization to work on. For example, if JSON parsing were a thousand times faster if I wasn't using lists, but JSON parsing was only 0.1% of the program's total execution time, then I might not care.
what will happen to hacks.catdancer.ws? Do you prefer that people refer to code previously published by CatDancer as "aw's code" now?
I'll be moving the pages on hacks.catdancer.ws to a new site, and I'll have hacks.catdancer.ws redirect to the new site so that old links still work. And yes, all my code can be referred to "aw's" code now.
And, are you really Pure Evil or is that google mixing you up with someone else?
Er, no, never heard of "Pure Evil" before. That's someone else... :-)
