3 ms·
One of the debates I always enjoy when it shows up on HN is the comparison of lightweight serialization formats, especially, e.g., sexprs vs json. I don’t belie
by gglitch 6y ago
One of the debates I always enjoy when it shows up on HN is the comparison of lightweight serialization formats, especially, e.g., sexprs vs json. I don’t believe I’ve ever seen Prolog terms show up, but they seem apposite.
- sedachv 6y agoOne of those three is not like the others. Prolog is homoiconic. JavaScript programs are not JSON. Parsing Prolog terms is easy. Parsing JSON correctly is very difficult: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php
- gglitch 6y agoIt seems to be conventional to use the homoiconicity of Tcl to serialize data out in a way intended to be interpreted back in again as code [0], but I don’t think I’ve seen this recommended by Lispers. [0] - e.g. https://trs.jpl.nasa.gov/bitstream/handle/2014/7660/03-1728.pdf https://trs.jpl.nasa.gov/bitstream/handle/2014/7660/03-1728....
- tom_mellior 6y ago> Parsing Prolog terms is easy. Parsing JSON correctly is very difficult: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php Most of that page is about character escaping as well as Unicode and floating point corner cases. You'll need to handle the same corner cases if you want to write a robust Prolog parser (it's slightly simpler if you cheat by rejecting Unicode).
- tannhaeuser 6y agoBasic JSON support using Prolog's built-in operator precedence parsing or pio lib should be as easy as :- op(600, xfy, :). MyJSON = { "this": "bla", "that": 100, "L": [ 1, "two", 3 ] } provided your Prolog has curly braces (should come with DCGs).