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.
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?
Andrei
