[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mapping data formats imported from C libraries
From: |
Ted Zlatanov |
Subject: |
Re: mapping data formats imported from C libraries |
Date: |
Wed, 26 Nov 2014 07:59:04 -0500 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) |
On Tue, 25 Nov 2014 18:06:37 +0100 Lars Magne Ingebrigtsen <address@hidden>
wrote:
LMI> Ted Zlatanov <address@hidden> writes:
>> Yes, but in a really sucky way. If you look at the libjson and json.el
>> output, it's much leaner. Mapping JSON up to XML pretty much guarantees
>> pain when you use it and on the way back. Do you want to inflict that
>> on everyone in the name of a unified DOM?
LMI> The Emacs DOM is quite non-sucky. It's just a tree.
LMI> (thing ((attrib . value)) (foo) (bar))
LMI> JSON maps onto it really nicely. The attributes are always nil, though.
Yeah, I've seen the mess that libxml2 and json.el produce (not the
coder's fault, it's just a pain to adapt without native types). It
doesn't help that XML/SGML and Lisp are inbred cousins :)
* it's a pain to distinguish JSON's `false' and `null' while using them
in code
* in json.el you pick the key-value storage method! yay!
* in json.el you pick the array storage method! yay!
* JSON data is not a tree
My ideal mapping from libjson and libyaml would be:
* unambiguous: you can reconstruct a canonical version of the input
stream from the parse data, as much as possible (JSON is better at this)
* native: you can iterate over JSON arrays as Lisp lists, and JSON
key-value mappings as alists. JSON's `false' and `null' are both
false in Lisp boolean context.
* clean: no extra cons cells for attributes
* readable: this is huge IMO, to be able to pretty-print the data and
quickly see what it contains... one of the things I like about JSON
vs. SGML/XML.
The ideal thing may be a "libjson/libyaml native" data format that can
then be bidirectionally mapped to the DOM you suggest...
Ted
- mapping data formats imported from C libraries (was: DOM manipulation functions), (continued)
- mapping data formats imported from C libraries (was: DOM manipulation functions), Ted Zlatanov, 2014/11/25
- Re: mapping data formats imported from C libraries, Lars Magne Ingebrigtsen, 2014/11/25
- Re: mapping data formats imported from C libraries, Ted Zlatanov, 2014/11/25
- Re: mapping data formats imported from C libraries, Lars Magne Ingebrigtsen, 2014/11/25
- Re: mapping data formats imported from C libraries, Ted Zlatanov, 2014/11/25
- Re: mapping data formats imported from C libraries, Lars Magne Ingebrigtsen, 2014/11/25
- Re: mapping data formats imported from C libraries, Steinar Bang, 2014/11/26
- Re: mapping data formats imported from C libraries, Lars Magne Ingebrigtsen, 2014/11/26
- Re: mapping data formats imported from C libraries, Steinar Bang, 2014/11/26
- Re: mapping data formats imported from C libraries, Lars Magne Ingebrigtsen, 2014/11/26
- Re: mapping data formats imported from C libraries,
Ted Zlatanov <=
- Re: mapping data formats imported from C libraries, Lars Magne Ingebrigtsen, 2014/11/26
- Re: mapping data formats imported from C libraries, Ted Zlatanov, 2014/11/26
Re: DOM manipulation functions, raman, 2014/11/23
Re: DOM manipulation functions, Nicolas Richard, 2014/11/25
Re: DOM manipulation functions, Lars Magne Ingebrigtsen, 2014/11/26