On 8/3/14, 10:19 AM, Sean Kelly wrote:
I don't want to pay for anything I don't use. No allocations should occur within the parser and it should simply slice up the input.
What to do about arrays and objects, which would naturally allocate arrays and associative arrays respectively? What about strings with backslash-encoded characters?
No allocation works for tokenization, but parsing is a whole different matter.
So the lowest layer should allow me to iterate across symbols in some way.
Yah, that would be the tokenizer.
When I've done this in the past it was SAX-style (ie. a callback per type) but with the range interface that shouldn't be necessary. The parser shouldn't decode or convert anything unless I ask it to. Most of the time I only care about specific values, and paying for conversions on everything is wasted process time.
That's tricky. Once you scan for 2 specific characters you may as well scan for a couple more, the added cost is negligible. In contrast, scanning once for finding termination and then again for decoding purposes will definitely be a lot more expensive.
I suggest splitting number into float and integer types. In a language like D where these are distinct internal bfulifbucivrdfvhhjnrunrgultdjbjutypes, it can be valuable to know this up front.
Yah, that kept on sticking like a sore thumb throughout.
Is there support for output? I see the makeArray and makeObject routines... Ideally, there should be a way to serialize JSON against an OutputRange with optional formatting.
Not yet, and yah those should be in. Andrei
