Arc Forumnew | comments | leaders | submitlogin
4 points by aw 5504 days ago | link | parent

This is an updated and expanded version of my earlier "A parser-combinator approach to parsing JSON" writeup.


3 points by conanite 5504 days ago | link

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.

-----

4 points by aw 5504 days ago | link

Thanks!

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.

-----