JSONization of level-2 syntax

Google Group
21

Done. Should be available in the next release.
For now, please try the pre-release of ATS2-0.1.9:

http://www.ats-lang.org/Downloads.html

Confirmed: I now get a /d2eclist/39/d2ecl_node/D2Coverload/0 whose value
is ~.

22

Yes, the command-line should be:

patsopt --jsonize-2 -d ${PATSHOME}/doc/EXAMPLE/INTRO/acker1.dats

Also there is a bug: end of line escaped characters (\n) in string
literals, are turned into real end of line in the output, which the JSON
output, invalid.

I have fixed this one. Changes are in ATS2-0.1.9 pre-release.On Wed, Feb 11, 2015 at 10:58 AM, ‘Yannick Duchêne’ via ats-lang-users < ats-lan...@googlegroups.com> wrote:

Le samedi 13 décembre 2014 05:12:15 UTC+1, gmhwxi a écrit :

Patsopt can be used to turn ATS source code into a serialized
representation in JSON.

For instance, the command-line below:

patsopt --jsonize-2 ${PATSHOME}/doc/EXAMPLE/INTRO/acker1.dats

generates the JSON text included at the end of this message. The text can
be readily
parsed. An example of doing so can be found in the UTFPL0 directory:

For me, a -d option has to be added before the file name, otherwise I
get an error about an unrecognised option, ex:

 waring(ATS): unrecognized command line argument [test.dats] is

ignored.

Also there is a bug: end of line escaped characters (\n) in string
literals, are turned into real end of line in the output, which the JSON
output, invalid. Ex:

…  "Hello\n" …

is turned into this:

 … "Hello
 " …

–
You received this message because you are subscribed to the Google Groups
“ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/55b9c3d5-e83e-4980-abb3-c376efe3bdca%40googlegroups.com
https://groups.google.com/d/msgid/ats-lang-users/55b9c3d5-e83e-4980-abb3-c376efe3bdca%40googlegroups.com?utm_medium=email&utm_source=footer
.

23

Patsopt can be used to turn ATS source code into a serialized
representation in JSON.

Just out of curiosity, why JSON instead of simple XML 1.0?

For instance, the command-line below:

patsopt --jsonize-2 ${PATSHOME}/doc/EXAMPLE/INTRO/acker1.dats

generates the JSON text included at the end of this message. The text can
be readily
parsed. An example of doing so can be found in the UTFPL0 directory:

https://github.com/githwxi/ATS-Postiats-contrib/tree/master/projects/MEDIUM/UTFPL0

In ATS, level-2 syntax is used after fixities (infix, prefix and postfix)
and bindings are resolved.

What is “binding” in this context? Some kind of name resolution?

If you ever want to design/implement a language, then you can use this
tool to get going quickly.
This is especially so if you want to play with fancy types as the concrete
syntax of ATS allows
the programmer to readily add type-annotations. I myself intend to use the
tool for teaching PL
and compilers.

Does it mean one can generate ATS source from a constructed JSON
representation?

24

Thanks for pointing this out!

I fixed this. For now I only handle UTF-8.

I have never understood why people want UTF-16. They could use UTF-8 or
UTF-32.
But why UTF-16 :)On Tuesday, February 17, 2015 at 5:09:07 PM UTC-5, Yannick Duchêne wrote:

Le mercredi 11 février 2015 18:42:41 UTC+1, gmhwxi a écrit :

Also there is a bug: end of line escaped characters (\n) in string
literals, are turned into real end of line in the output, which the JSON
output, invalid.

I have fixed this one. Changes are in ATS2-0.1.9 pre-release.

A character escape issue remains: in doc/EXAMPLE/INTRO/hello.dats, there
are many Unicode characters. In the generated JSON, these are escaped as
\NNN, which is not valid JSON. The proper way to escape these characters
is \uNNNN: \u followed by four digits for character in the BMP (whose
code point are 16 bits) and characters beyond the BMP are to be encoded as
UTF‑16 16 bits word paires (yes, unfortunately less direct), according to
the JSON specification, on printed page 9 (displayed page 10):
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
.

Ex. \344 should be \u0344.

Fixing the case of characters from the BMP is obvious: just use \u and
pad left with 0 up to four digits next to the \u. The case of
characters beyond de BMP is less obvious, and fortunately, these ones are
rare (however common in some use case). I will search the Unicode reference
for the exact encoding to be applied.