std.jgrandson

[Sönke Ludwig via Digitalmars-d]

Am 03.08.2014 17:34, schrieb Andrei Alexandrescu:
> On 8/3/14, 2:38 AM, Sönke Ludwig wrote:
> [snip]
>
> We need to address the matter of std.jgrandson competing with
> vibe.data.json. Clearly at a point only one proposal will have to be
> accepted so the other would be wasted work.
>
> Following our email exchange I decided to work on this because (a) you
> mentioned more work is needed and your schedule was unclear, (b) we need
> this at FB sooner rather than later, (c) there were a few things I
> thought can be improved in vibe.data.json. I hope that taking
> std.jgrandson to proof spurs things into action.
>
> Would you want to merge some of std.jgrandson's deltas into a new
> proposal std.data.json based on vibe.data.json? Here's a few things that
> I consider necessary:
>
> 1. Commit to a schedule. I can't abandon stuff in wait for the perfect
> design that may or may not come someday.

This may be the crux w.r.t. the vibe.data.json implementation. My 
schedule will be very crowded this month, so I could only really start 
to work on it beginning of September. But apart from the mentioned 
points, I think your implementation is already the closest thing to what 
I have in mind, so I'm all for going the clean slate route (I'll have to 
do a lot in terms of deprecation work in vibe.d anyway).

>
> 2. Avoid UTF decoding.
>
> 3. Offer a lazy token stream as a basis for a non-lazy parser. A lazy
> general parser would be considerably more difficult to write and would
> only serve a small niche. On the other hand, a lazy tokenizer is easy to
> write and make efficient, and serve as a basis for user-defined
> specialized lazy parsers if the user wants so.
>
> 4. Avoid string allocation. String allocation can be replaced with
> slices of the input when these two conditions are true: (a) input type
> is string, immutable(byte)[], or immutable(ubyte)[]; (b) there are no
> backslash-encoded sequences in the string, i.e. the input string and the
> actual string are the same.
>
> 5. Build on std.variant through and through. Again, anything that
> doesn't work is a usability bug in std.variant, which was designed for
> exactly this kind of stuff. Exposing the representation such that user
> code benefits of the Algebraic's primitives may be desirable.
>
> 6. Address w0rp's issue with undefined. In fact std.Algebraic does have
> an uninitialized state :o).
>
> Sönke, what do you think?

My requirements would be the same, except for 6.

The "undefined" state in the vibe.d version was necessary due to early 
API decisions and it's more or less a prominent part of it (specifically 
because the API was designed to behave similar to JavaScript). In 
hindsight, I'd definitely avoid that. However, I don't think its 
existence (also in the form of Algebraic.init) is an issue per se, as 
long as such values are properly handled when converting the runtime 
value back to a JSON string (i.e. skipped or treated as null values).