Re: Serialise lisp objects for babel-supported langage

[John Kitchin <jkitchin@andrew.cmu.edu>]

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