Data-E in JSON - Revision history

Kevin Reid: describe new 'atom' design

2009-08-09T13:19:03Z

describe new 'atom' design

New page

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 [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.

{{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>
|-
| [[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>
|-
| [[Character]] || <code>'f'</code> || <code>["char", "f"]</code> || The string shall be of length 1. {{XXX|Consider UTF-16 issues.}}
|}

== Import and ibid ==

{|
! Data-E Source !! JSON
|-
| <code>foo</code> || <code>["import", "foo"]</code>
|-
| <code>t_9</code> || <code>["ibid", 9]</code>
|}

== Call ==

{|
! Data-E Source !! JSON
|-
| <code><var>foo</var>.bar(<var>baz...</var>)</code> || <code>["call", <var>foo</var>, "bar", [<var>baz...</var>]]</code>
|}

== Define ==

{|
! Data-E Source !! JSON
|-
| <code>def <var>t_9</var> := <var>bar</var></code> || <code>["define", <var>9</var>, <var>bar</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:JavaScript]]

Kevin Reid: revise introduction, link to caja-captp, link to CapTP on HTTP

2009-06-01T03:35:04Z

revise introduction, link to caja-captp, link to CapTP on HTTP

←Older revision		Revision as of 03:35, 1 June 2009
Line 1:		Line 1:
-	~~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]]~~.	+	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]].
		+
		+	It is being implemented as part of [[User:Kevin Reid]]'s [http://code.google.com/p/caja-captp/ GSoC project, caja-captp].

	==Literals==		==Literals==
Line 50:		Line 54:
	\| <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]]

Kevin Reid: /* Literals */ restrict integers

2009-05-29T18:28:35Z

Literals: restrict integers

←Older revision		Revision as of 18:28, 29 May 2009
Line 12:		Line 12:

	{\|		{\|
-	! !! 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.}}
	\|}		\|}

Kevin Reid: clarify "exactly the same"

2009-05-29T13:22:20Z

clarify "exactly the same"

←Older revision		Revision as of 13:22, 29 May 2009
Line 1:		Line 1:
	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]].		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]].	+	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==		==Literals==

Kevin Reid: /* Literals */ spec change for integers, some notes

2009-01-16T19:42:56Z

Literals: spec change for integers, some notes

←Older revision		Revision as of 19:42, 16 January 2009
Line 5:		Line 5:
	==Literals==		==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.	+	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		! !! Data-E Source !! JSON
	\|-		\|-
-	\| 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>
	\|-		\|-
-	\| 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>
	\|}		\|}

Kevin Reid at 02:01, 8 January 2009

2009-01-08T02:01:44Z

←Older revision		Revision as of 02:01, 8 January 2009
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]]