std.jgrandson

[Andrei Alexandrescu via Digitalmars-d]

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