Re: [O] Serialise lisp objects for babel-supported langage

[Garreau\, Alexandre]

On 2018-10-16 at 16:59, John Kitchin wrote:
> This might be going the opposite direction, but I worked on a way to make
> it easier to digest the output of Python in elisp, in these two posts:
>
> http://kitchingroup.cheme.cmu.edu/blog/2015/05/16/Python-data-structures-to-lisp/
> http://kitchingroup.cheme.cmu.edu/blog/2016/05/30/Writing-lisp-code-from-Python/

So like Pymacs already does?  Quite the opposite, I’d say: all that
seems to go in the same direction.

> These days I would probably try serializing via json. it is easy to read
> and write in most languages.

I feel like not all languages might support json (especially for every
object), and it is way more complex to implement than sexps.

It feels a bit frustrating to abdicate in front of a lower-standard
format than sexps: json could not even be predating sexp if only sexp
wasn’t so infamous: they are more efficient, older, and *in reality*
easier to read [1].

Also sexps have an efficient, straight-forward, almost-standard
representation in memory, and some standard APIs to operate on them.
Json doesn’t.

Note for each serialization format, the question arise again,
quadratically: it is a n² problem.  However I believe some languages
might already have some standard inter-lingual serializers (including
sexps, json, xml^Wetc.), so anything that kind could as well, for (good,
I decide) redundancy to specify which serializers are supported by each,
how are they called, and ways to serialize toward them.  So it becomes a
less-than-n problem.

And there is the case of course of javascript which json is a subset of,
and the more beautiful case of the yet young purely-functional Curv [0],
which elegantly builds upon a minimal superset of json.

[0] https://github.com/doug-moen/curv

[1] only difference is “{}” vs “()” (how funny it would if TeX began
predating them and won), and culturally they use more arrays, and put
quotes everywhere (and yeah they steal their familiarity from something
“almost” compatible with C and CSS (in two different incompatible ways)
and compatible with javascript).