Data-E in JSON

From Erights

(Difference between revisions)
Jump to: navigation, search
(describe new 'atom' design)
Line 1: Line 1:
-
This is a definition of [[JSON]] syntax for Data-E.
+
There is interest (2009-01-07) in using [[CapTP]] in [[Cajita]] systems, with a [[JSON]] syntax for the message/serialization layer. Therefore, this page defines a 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, 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].
+
String literals are copied as-is into JSON (rationale: compactness, readability). The three other types of literals are tagged, since JSON does not have character values and (we assume) JavaScript-based JSON implementations will not distinguish floats from integers.
-
 
+
-
==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
! !! Data-E Source !! JSON
|-
|-
-
| [[String]] || <code>"foo"</code> || <code>"foo"</code>
+
| String || <code>"foo"</code> || <code>"foo"</code>
|-
|-
-
| [[Float64]] || <code>-9.99</code> || <code>-9.99</code>
+
| Integer || <code>9</code> || <code>["int", 9]</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.
+
-
 
+
-
{{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]] || <code>"foo"</code> || <code>"foo"</code>
+
| Float64 || <code>9.99</code> || <code>["float64", 9.99]</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}}
+
| Character || <code>'f'</code> || <code>["char", "f"]</code>
-
|-
+
-
| [[Float64]] || <code>9.99</code> || <code>["float64", 9.99]</code>
+
-
|-
+
-
| [[Character]] || <code>'f'</code> || <code>["char", "f"]</code> || The string shall be of length 1. {{XXX|Consider UTF-16 issues.}}
+
|}
|}
Line 68: Line 46:
| <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]]

Revision as of 02:01, 8 January 2009

There is interest (2009-01-07) in using CapTP in Cajita systems, with a JSON syntax for the message/serialization layer. Therefore, this page defines a JSON syntax for Data-E.

Except for literals, it is exactly the same as the Data-E in TermL format as implemented by deASTKit.

Contents

Literals

String literals are copied as-is into JSON (rationale: compactness, readability). The three other types of literals are tagged, since JSON does not have character values and (we assume) JavaScript-based JSON implementations will not distinguish floats from integers.

Data-E Source JSON
String "foo" "foo"
Integer 9 ["int", 9]
Float64 9.99 ["float64", 9.99]
Character 'f' ["char", "f"]

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]...]
Personal tools
more tools