Data-E in JSON
From Erights
Kevin Reid (Talk | contribs) (clarify "exactly the same") |
(describe new 'atom' design) |
||
| (2 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
| - | + | 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]]. | 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]]. | ||
| - | ==Literals== | + | It is being implemented as part of [[User:Kevin Reid]]'s [http://code.google.com/p/caja-captp/ GSoC project, caja-captp]. |
| + | |||
| + | ==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. | ||
| Line 12: | Line 30: | ||
{| | {| | ||
| - | ! !! Data-E Source !! JSON | + | ! !! Data-E Source !! JSON !! Notes |
|- | |- | ||
| [[String]] || <code>"foo"</code> || <code>"foo"</code> | | [[String]] || <code>"foo"</code> || <code>"foo"</code> | ||
|- | |- | ||
| - | | [[Integer]] || <code>9</code> || <code>["int", "9"]</code> | + | | [[Integer]] || <code>9</code> || <code>["int", "9"]</code> || The numeric string shall be only digits, with no leading zeros. {{XXX|Decide about negative integers}} |
|- | |- | ||
| [[Float64]] || <code>9.99</code> || <code>["float64", 9.99]</code> | | [[Float64]] || <code>9.99</code> || <code>["float64", 9.99]</code> | ||
|- | |- | ||
| - | | [[Character]] || <code>'f'</code> || <code>["char", "f"]</code> | + | | [[Character]] || <code>'f'</code> || <code>["char", "f"]</code> || The string shall be of length 1. {{XXX|Consider UTF-16 issues.}} |
|} | |} | ||
| Line 50: | Line 68: | ||
| <code>def <var>t_9</var> := <var>...t_9...</var></code> || <code>["defrec", <var>9</var>, <var>...["ibid", 9]...</var>]</code> | | <code>def <var>t_9</var> := <var>...t_9...</var></code> || <code>["defrec", <var>9</var>, <var>...["ibid", 9]...</var>]</code> | ||
|} | |} | ||
| + | |||
| + | == See also == | ||
| + | |||
| + | * [[CapTP on HTTP]] | ||
[[Category:Data-E]] | [[Category:Data-E]] | ||
[[Category:JavaScript]] | [[Category:JavaScript]] | ||
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]...]
|
