* Serialise lisp objects for babel-supported langage
@ 2018-10-16 19:55 Garreau, Alexandre
2018-10-16 20:59 ` John Kitchin
0 siblings, 1 reply; 3+ messages in thread
From: Garreau, Alexandre @ 2018-10-16 19:55 UTC (permalink / raw)
To: emacs-org list
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).
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Serialise lisp objects for babel-supported langage
2018-10-16 19:55 Serialise lisp objects for babel-supported langage Garreau, Alexandre
@ 2018-10-16 20:59 ` John Kitchin
2018-10-16 21:23 ` Garreau, Alexandre
0 siblings, 1 reply; 3+ messages in thread
From: John Kitchin @ 2018-10-16 20:59 UTC (permalink / raw)
To: galex-713; +Cc: org-mode-email
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Serialise lisp objects for babel-supported langage
2018-10-16 20:59 ` John Kitchin
@ 2018-10-16 21:23 ` Garreau, Alexandre
0 siblings, 0 replies; 3+ messages in thread
From: Garreau, Alexandre @ 2018-10-16 21:23 UTC (permalink / raw)
To: John Kitchin; +Cc: org-mode-email
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).
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-10-16 21:23 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-16 19:55 Serialise lisp objects for babel-supported langage Garreau, Alexandre
2018-10-16 20:59 ` John Kitchin
2018-10-16 21:23 ` Garreau, Alexandre
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).