From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: User-defined record types
Date: Sat, 19 Oct 2013 07:48:27 -0400 [thread overview]
Message-ID: <87sivxmqgk.fsf@flea.lifelogs.com> (raw)
In-Reply-To: jwvtxgec8y4.fsf-monnier+emacs@gnu.org
On Fri, 18 Oct 2013 22:09:39 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>> Something that represents JSON and YAML well would be nice. Currently
>>>> we don't have an ELisp data structure that can preserve all JSON nuances
>>>> without acrobatics (e.g. preserving the difference between "null" and
>>>> "empty list" or the native JSON data types).
SM> I don't understand what you mean here. It's very easy to have special
SM> values, e.g. (defconst json-null (make-symbol "json-null")).
>> Yes, but it's not something you can communicate externally. Compare
>> with pure JSON or BSON, which are intended for communication across
>> programs.
SM> You lost me: I though "null" and "empty list" were JSON thingies, so
SM> I just offered you ways to represent them on the Elisp side. Of course,
SM> when turning those elements into JSON, you'd be careful to map them to
SM> the appropriate JSON elements.
Right. So instead of a special mapping operation, the underlying C
storage (record) should hold the JSON/YAML/XML types and values
directly. The ELisp API to that C storage would map things to
ELisp-land, but the original data would be preserved.
>> Sure. I'm saying a custom data structure would help here, not that it's
>> the only way to accomplish it, and trying to answer your earlier
>> question about custom record types.
SM> I still don't understand in what way a custom data structure would help.
By holding the original data in a way that today's Emacs internals can't.
>>>> a native XML data structure would also be nice. We have what libxml
>>>> produces, dumped in an awkward tree, but nothing native.
SM> Not sure what "native" can mean in this context: we were talking about
SM> new Lisp-defined types.
>> Native to ELisp, but in a way that represents the original data
>> structure cleanly and transparently.
SM> I still don't see what that means. In which way would it be cleaner or
SM> more transparent?
>> I'm talking about custom data types that can be efficiently and
>> transparently converted to what the external libraries and protocols
>> expect, and provide a good ELisp interface to their contents. I think
>> the currently available XML and JSON representation in ELisp don't do
>> both. Am I misunderstanding the question?
SM> What alternative do you have in mind that would be more efficient and/or
SM> more transparent?
Well, let's look at your original question:
On Sat, 12 Oct 2013 14:58:15 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:
>>> I'm not necessarily opposed to user-defined record types, but if
>>> cl-defstruct is not sufficient and C-level changes are required, then
>>> I'd hope for the new code to provide more exciting features than just
>>> "vectorp returns nil".
Look. This is JSON (YAML is similar; XML is much more complex but has
similar conversion and implementation issues):
{ "x": 1, "y": [ null, [], true, false ] }
A C structure would represent that as follows:
- the number 1 would be stored as a JSON-spec integer, which is
essentially a tagged string. These are not ELisp ints or bignums
although the implementation can choose to limit them to Javascript
ints. See http://www.json.org/ for the details on number formatting.
- the value under the "y" key has four distinct values that should be
represented and serialized differently, yet provide the expected
semantics for ELisp access ("null", "[]", and "false" would be exposed
as `nil').
- stored efficiently
All of this can be done in ELisp with custom symbols and other tricks,
but I think a C implementation would be cleaner by being closer to the
original input data and removing ELisp baggage from a simple data
format. The C implementation would also be more efficient than an ELisp
implementation if it serializes to and from JSON in C, but that's a
minor concern. Finally, a C implementation would be able to make null,
false, and [] look like `nil' in boolean or iteration contexts, yet
preserve the original data. I don't think an ELisp implementation can
do that unless all access goes through a forced API.
So the exciting feature is that you don't have to work around the
absence of these record types in ELisp. You may consider that an
advantage (less C code = less maintenance) but the original question was
about "exciting features" not maintainability.
Ted
next prev parent reply other threads:[~2013-10-19 11:48 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-10 11:22 RFC: User-defined pseudovectors Lars Brinkhoff
2013-10-10 11:29 ` Lars Brinkhoff
2013-10-10 11:40 ` Lars Brinkhoff
2013-10-10 12:52 ` Dmitry Antipov
2013-10-10 13:41 ` Dmitry Antipov
2013-10-10 16:40 ` Lars Brinkhoff
2013-10-10 14:00 ` Stefan Monnier
2013-10-10 16:30 ` Lars Brinkhoff
2013-10-10 20:42 ` Stefan Monnier
2013-10-11 6:00 ` Lars Brinkhoff
2013-10-11 12:22 ` Stefan Monnier
2013-10-12 16:01 ` User-defined record types Lars Brinkhoff
2013-10-12 18:58 ` Stefan Monnier
2013-10-18 13:39 ` Ted Zlatanov
2013-10-18 15:28 ` Stefan Monnier
2013-10-18 23:24 ` Ted Zlatanov
2013-10-19 2:09 ` Stefan Monnier
2013-10-19 2:30 ` Drew Adams
2013-10-19 11:48 ` Ted Zlatanov [this message]
2013-10-19 14:37 ` Stefan Monnier
2013-10-19 20:11 ` Ted Zlatanov
2013-10-19 21:48 ` Stefan Monnier
2013-10-10 20:43 ` RFC: User-defined pseudovectors Stefan Monnier
[not found] <87pokampa4.fsf@ericabrahamsen.net>
[not found] ` <handler.25295.B.148304476023950.ack@debbugs.gnu.org>
[not found] ` <8760m2mmlq.fsf@ericabrahamsen.net>
[not found] ` <jwv8tqsdnwl.fsf-monnier+bug#25295@gnu.org>
[not found] ` <87lguq5r87.fsf@ericabrahamsen.net>
[not found] ` <jwvr34i2s8w.fsf-monnier+emacsbugs@gnu.org>
[not found] ` <jwvfuky2ran.fsf-monnier+emacsbugs@gnu.org>
[not found] ` <jwvshoyazvd.fsf-monnier+emacsbugs@gnu.org>
[not found] ` <878tp0i74g.fsf@users.sourceforge.net>
[not found] ` <jwvk28jmpl5.fsf-monnier+emacsbugs@gnu.org>
2017-03-02 5:36 ` Elisp printer (was: bug#25295: Represent eieio objects using object-print in backtraces and edebug) Michael Heerdegen
2017-03-02 6:38 ` Elisp printer Stefan Monnier
2017-03-08 4:09 ` Tom Tromey
2017-03-08 18:17 ` Lars Brinkhoff
2017-03-08 23:02 ` Stefan Monnier
2017-03-14 9:52 ` User-defined record types Lars Brinkhoff
2017-03-14 12:28 ` Lars Brinkhoff
[not found] ` <86bmt42nk2.fsf_-_@molnjunk.nocrew.org>
[not found] ` <jwvzigoow0k.fsf-monnier+emacs@gnu.org>
2017-03-14 13:25 ` Lars Brinkhoff
2017-03-14 14:28 ` Lars Brinkhoff
2017-03-14 15:20 ` Stefan Monnier
2017-03-14 17:23 ` Lars Brinkhoff
2017-03-15 14:38 ` Stefan Monnier
2017-03-15 18:14 ` Lars Brinkhoff
2017-03-15 19:12 ` Stefan Monnier
2017-03-15 19:21 ` Lars Brinkhoff
2017-03-15 20:05 ` Stefan Monnier
2017-03-15 21:49 ` Lars Brinkhoff
2017-03-15 23:42 ` Stefan Monnier
2017-03-16 3:05 ` Stefan Monnier
2017-03-16 3:08 ` Stefan Monnier
2017-03-16 20:03 ` Lars Brinkhoff
2017-03-16 21:32 ` Stefan Monnier
2017-03-17 11:22 ` Lars Brinkhoff
2017-03-17 20:45 ` Lars Brinkhoff
2017-03-18 23:24 ` Stefan Monnier
2017-03-18 23:36 ` Stefan Monnier
2017-03-19 9:34 ` Lars Brinkhoff
2017-03-19 12:42 ` Stefan Monnier
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.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sivxmqgk.fsf@flea.lifelogs.com \
--to=tzz@lifelogs.com \
--cc=emacs-devel@gnu.org \
/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.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).