I'm still laughing hard! These guys deserve to graduate right now ... or maybe a perpetual grant to stay in school and write such assignments :D Excellente!
I downloaded Safari 5 more or less as a routine update, but I must say I'm very pleasantly surprised by its speed and Reader. S5 rocks on Snow Leopard.
That said, S5 is still plagued by some of the problems I had with earlier versions - such as "completed 7 of 8 items" ... (I'm waiting), not logging in to my univ's network, etc. So Chrome it is, for now.
My mom - yes that's right - my MOM runs Ubuntu on her laptop for email and watching videos off the net. As long as she sees Firefox, she's happy. I recently wiped her machine clean of Windows XP and installed Ubuntu 'cos the virus scanner was complaining a lot. Thanks Ubuntu!
Fine print: It took some geekery to get the plugins needed to play youtube stuff. Haven't quite sorted out DVD playing yet.
I think the observation that conditionals are difficult to work with is valid, however the suggestion that "proper use of object oriented principles" is the solution to that problem is totally mistaken. To understand why I say that, watch Jonathan Edwards presentation "No Ifs, Ands or Buts" about Subtext (http://subtextual.org/subtext2.html)
My comment wasn't JSON specific. After all, the JSON spec was designed to support simple parsing logic from the start. My comment was more oriented towards generalization.
Each element of the returned list represents one way that the parser can "succeed". For example, if your parser is for the regexp "a+" and you give the string "aaabc", then the parser can return (("a" . "aabc") ("aa" . "abc") ("aaa" . "bc")] to say that it can interpret "aaabc" in 3 ways. You can transform this into the "longest" parse by filtering this list for the shortest "remaining string".
If your parser returns [] it means it cannot parse the string, so it all fits together. I don't know if I can find the time to rewrite the code to show you explicitly how this could help, but looking at Parsec (in Haskell) will give you a good idea of what I'm talking about
It looks like modeling your parser as fn(str) -> (list-of (pair-of value remaining-str)) might work out as a more compact (in terms of code) and powerful representation. I did something similar when writing a combinator library for querying xml-like trees and it ended up quite powerful. (you can replace "str" with any sequence type).
For one thing, you can write parsers that return more than one value - i.e. parsers that are ambiguous about how they parse the string they are given. That lets you express "longest" and "shortest" as parser combinators rather than some special operation for each parser.
Edit: Just noticed 2001