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-...@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). > >
