Data-E in JSON
From Erights
Kevin Reid (Talk | contribs) (revise introduction, link to caja-captp, link to CapTP on HTTP) |
(describe new 'atom' design) |
||
(4 intermediate revisions not shown) | |||
Line 7: | Line 7: | ||
It is being implemented as part of [[User:Kevin Reid]]'s [http://code.google.com/p/caja-captp/ GSoC project, caja-captp]. | It is being implemented as part of [[User:Kevin Reid]]'s [http://code.google.com/p/caja-captp/ GSoC project, caja-captp]. | ||
- | ==Literals== | + | ==Atoms== |
+ | |||
+ | The atom types are [[String]] and [[float64]], which are copied as-is into the JSON structure. Integers are not atoms and must be handled by an uncaller, since JavaScript-based JSON implementations will not preserve int/float distinctions or the values of integers that don't fit in float64. Characters are not atoms and must be handled by an uncaller. | ||
+ | |||
+ | {| | ||
+ | ! !! Data-E Source !! JSON | ||
+ | |- | ||
+ | | [[String]] || <code>"foo"</code> || <code>"foo"</code> | ||
+ | |- | ||
+ | | [[Float64]] || <code>-9.99</code> || <code>-9.99</code> | ||
+ | |} | ||
+ | |||
+ | ==Literals (old design)== | ||
+ | |||
+ | {{XXX|Delete/fold this into the previous section. See [http://www.eros-os.org/pipermail/e-lang/2009-June/013157.html] for the context.}} | ||
String literals are copied as-is into JSON (rationale: compactness, readability). Characters are tagged since JSON does not have character values. Integers are tagged and written as strings since JavaScript-based JSON implementations will not preserve the values of integers that don't fit in float64. | String literals are copied as-is into JSON (rationale: compactness, readability). Characters are tagged since JSON does not have character values. Integers are tagged and written as strings since JavaScript-based JSON implementations will not preserve the values of integers that don't fit in float64. |
Latest revision as of 13:19, 9 August 2009
This is a definition of JSON syntax for Data-E.
It was created around 2009-01-07 due to interest in using CapTP in Cajita systems, with a JSON syntax for the message/serialization layer.
Except for literals and that it uses tuples with string tags instead of TermL tagged terms, it is exactly the same as the Data-E in TermL format as implemented by deASTKit.
It is being implemented as part of User:Kevin Reid's GSoC project, caja-captp.
Contents |
Atoms
The atom types are String and float64, which are copied as-is into the JSON structure. Integers are not atoms and must be handled by an uncaller, since JavaScript-based JSON implementations will not preserve int/float distinctions or the values of integers that don't fit in float64. Characters are not atoms and must be handled by an uncaller.
Data-E Source | JSON | |
---|---|---|
String | "foo" | "foo"
|
Float64 | -9.99 | -9.99
|
Literals (old design)
XXX Delete/fold this into the previous section. See [1] for the context.
String literals are copied as-is into JSON (rationale: compactness, readability). Characters are tagged since JSON does not have character values. Integers are tagged and written as strings since JavaScript-based JSON implementations will not preserve the values of integers that don't fit in float64.
XXX justify or remove tagging of float64.
XXX review what base/format to write integers in. In particular, if there is such, it should be readily convertible to a the format used by some big-integer-in-JavaScript library.
Data-E Source | JSON | Notes | |
---|---|---|---|
String | "foo" | "foo"
| |
Integer | 9 | ["int", "9"] | The numeric string shall be only digits, with no leading zeros. XXX Decide about negative integers |
Float64 | 9.99 | ["float64", 9.99]
| |
Character | 'f' | ["char", "f"] | The string shall be of length 1. XXX Consider UTF-16 issues. |
Import and ibid
Data-E Source | JSON |
---|---|
foo | ["import", "foo"]
|
t_9 | ["ibid", 9]
|
Call
Data-E Source | JSON |
---|---|
foo.bar(baz...) | ["call", foo, "bar", [baz...]]
|
Define
Data-E Source | JSON |
---|---|
def t_9 := bar | ["define", 9, bar]
|
def t_9 := ...t_9... | ["defrec", 9, ...["ibid", 9]...]
|