From: "Garreau\, Alexandre" <galex-713@galex-713.eu>
To: John Kitchin <jkitchin@andrew.cmu.edu>
Cc: org-mode-email <emacs-orgmode@gnu.org>
Subject: Re: Serialise lisp objects for babel-supported langage
Date: Tue, 16 Oct 2018 23:23:07 +0200 [thread overview]
Message-ID: <87k1mhoabo.fsf@portable.galex-713.eu> (raw)
In-Reply-To: <CAJ51ETriEZjYrjpCzcq-xB=ZPYY=mOPQa6sGtX7JwYmGdnx-dw@mail.gmail.com> (John Kitchin's message of "Tue, 16 Oct 2018 16:59:49 -0400")
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).
prev parent reply other threads:[~2018-10-16 21:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k1mhoabo.fsf@portable.galex-713.eu \
--to=galex-713@galex-713.eu \
--cc=emacs-orgmode@gnu.org \
--cc=jkitchin@andrew.cmu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).