Serialise lisp objects for babel-supported langage

Serialise lisp objects for babel-supported langage

[Garreau, Alexandre]

Would it be useful to begin integrating into babel functions so to
serialize lisp objects (just as prin1-to-string) in other languages?

I’ve read some babel files trying to do that, independently of each
others (that’s a lot of similar `typecase's (seeing it I’m regretting
each type-spec in it can’t be a list of types) …when authors even think
about using typecase instead of just `cond' or `if's): for instance
Fortran, so that to declare variables given as arguments to its source
blocks. imho, that may be of some use for other languages.

It may be useful as well for stuff outside of org-mode: e.g. iirc Pymacs
serialize/deserialize (read and print (and also eval, but not loop x)))
to allow the gateway between elisp and python and making each one
libraries available to the other.  That must be (really partially)
redundant with python babel.  And so on.

I don’t know well-enough enough languages to begin doing it right away,
and I might try to do only for scheme, ocaml and C then, so just
throwing the idea here.

Moreafter: deserialization might come handy as well, as if trying to
factorize between serialization and deserialization, this might as well
some sort of lower grammar or anyway easier to read, extend and debug
form of specifying the translation.  And then when a source block
outputs results, having a deserialization function might help to get
consistent output which then may be processed to make, for instance,
org-tables (though I know currently to do this it’s pretty imperative
and edition-oriented, rather than functional like this approach does
suggest).

Re: Serialise lisp objects for babel-supported langage

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]

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/

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

John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Tue, Oct 16, 2018 at 3:55 PM Garreau, Alexandre <galex-713@galex-713.eu>
wrote:

> Would it be useful to begin integrating into babel functions so to
> serialize lisp objects (just as prin1-to-string) in other languages?
>
> I’ve read some babel files trying to do that, independently of each
> others (that’s a lot of similar `typecase's (seeing it I’m regretting
> each type-spec in it can’t be a list of types) …when authors even think
> about using typecase instead of just `cond' or `if's): for instance
> Fortran, so that to declare variables given as arguments to its source
> blocks. imho, that may be of some use for other languages.
>
> It may be useful as well for stuff outside of org-mode: e.g. iirc Pymacs
> serialize/deserialize (read and print (and also eval, but not loop x)))
> to allow the gateway between elisp and python and making each one
> libraries available to the other.  That must be (really partially)
> redundant with python babel.  And so on.
>
> I don’t know well-enough enough languages to begin doing it right away,
> and I might try to do only for scheme, ocaml and C then, so just
> throwing the idea here.
>
> Moreafter: deserialization might come handy as well, as if trying to
> factorize between serialization and deserialization, this might as well
> some sort of lower grammar or anyway easier to read, extend and debug
> form of specifying the translation.  And then when a source block
> outputs results, having a deserialization function might help to get
> consistent output which then may be processed to make, for instance,
> org-tables (though I know currently to do this it’s pretty imperative
> and edition-oriented, rather than functional like this approach does
> suggest).
>
>

[-- Attachment #2: Type: text/html, Size: 3295 bytes --]

Re: 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).