2 ms·
Following the examples in the blog post, seems like the author would translate the following JSON expressions: {'a': 1} {'a': [1]} ['a' 1] ['a'
by buddydvd 15y ago
Following the examples in the blog post, seems like the author would translate the following JSON expressions:
{'a': 1}
{'a': [1]}
['a' 1]
['a' [1]]
into this:
('a' 1)
Isn't that ambiguous? Or, do they need to be demarcated using special tokens (e.g. a for array and o for object) like this?
{'a': 1} => (o ('a' 1))
{'a': [1]} => (o ('a' (a 1)))
If that's the case, nested arrays would require more characters to encode in S-expression than in JSON.
['a',['b',['c',['d',['e']]]]]
vs
(a 'a' (a 'b' (a 'c' (a 'd' (a 'e')))))
- qntm 15y agoYou're correct, the major disadvantage here is the ambiguity not just in this JSON/S-expression translation but in any possible JSON/S-expression translation. Linear arrays and key-value dictionaries in most programming languages are intuitive and meaningful and usually even have a native data type. The conversion is usually very obvious. Not so much with S-expressions. An even simpler problem is how do you express an empty array and an empty object in S-expressions? Is it () for both? EDIT: and what about nulls? What about strings that resemble numbers?
- buddydvd 15y agoYes, there are certainly more problems. I think the reason why the author thought S-expressions are more compact is because the comparison was made between formatted versions of the expressions (how they would appear in code): ["a", "b", "c"] ("a" "b" "c") Since people generally put spaces after their commas.
- rdtsc 15y agoI did this in my code: {'a': 1} -> (dict ('a' 1)) {'a': [1]} -> (dict ('a' (1))) ['a' 1] -> ('a' 1) ['a' [1]] -> ('a' (1)) ['a',['b',['c',['d',['e']]]]] -> ('a' ('b' ('c' ('d' ('e')))))