johnwright
commented
7 years ago Hi @chenglou, in terms of tradeoffs it's worth me saying that this library isn't exactly one-to-one with the original pickler combinators paper, e.g. the conventional decoder input is a stream of bytes, but in this case it's a Js.Json.t.
I'd say the perf tradeoff is safety vs. allocations, decoding creates a lot of Js.Result.ts and maps/binds them, which is more expensive than an unsafe approach. There are some interesting opportunities for optimisation though, structure-sharing can reduce memory footprint.
I'm not really aware of any theoretical issues, but here's one consideration that comes up in practice: If you're used to parser combinators, you can expect extreme flexibility in constructing decoders. With a pickler combinator approach, you have to ensure that everything is reversible, and so provide functions in both directions. If you're only interested in decoding something very complex, having to provide two functions for things can be a drag.
Hope that helps!
Hello @johnwright. This JSON library looks interesting! I'll read its paper, but I was wondering about its tradeoffs too (perf, size, theoretical blockers, etc.)?
The idea of having a free decoder from an encoder or vice-versa sounds pretty attractive, and if possible, I'd like the official Reason one to be free of ppx (which is needed mostly because of the usual encoding/decoding boilerplate).