Open ncalexan opened 6 years ago
Do we intend to do support anything other than debugging? Adding serde support is extremely simple for the default case, but as soon as we want to do more interesting things such as customising the actual syntax for textual formats, custom serialisation logic needs to be written.
An example where this matters is supporting json output: my experience is that serde's defaults are (although still human readable) extremely verbose and not something one would naturally write.
Do we intend to do support anything other than debugging? Adding serde support is extremely simple for the default case, but as soon as we want to do more interesting things such as customising the actual syntax for textual formats, custom serialisation logic needs to be written.
I don't have strong opinions. I do know that I like dumping structures (datoms, transactions, query results) as EDN and pretty-printing them (using the pretty-printer you built!). I don't really care about serializing arbitrary Rust structures to and from EDN, since I think JSON is much more likely to be used in the wild.
An example where this matters is supporting json output: my experience is that serde's defaults are (although still human readable) extremely verbose and not something one would naturally write.
Is this in the encoding? EDN is richer than JSON (e.g., lists, vectors, and sets are all syntactically differentiated) and keywords are more natural than some of the "tagging" encodings I saw the serde-json
writing out.
I'd be pretty interested in seeing if we could make simple structures that #[derive(Serialize)]
serialize to reasonable EDN cheaply.
It's quite convenient to be able to turn arbitrary things into EDN for debugging, and we have many places in the tree where we do just that. For example, this is used extensively in the
mentat_db
crate toassert_matches!
EDN representations of datoms and transactions.We could do this a little more generally if we made it easy to serialize into
edn::Value
.