From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: User-defined record types
Date: Sat, 19 Oct 2013 10:37:48 -0400 [thread overview]
Message-ID: <jwv7gd9cqzi.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87sivxmqgk.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Sat, 19 Oct 2013 07:48:27 -0400")
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.
Huh... no, I'm thinking about json.el, with no C code involved at all.
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.
For example?
> - 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').
Let's call [[e]] the Elisp representation of JSON's e.
Then you're saying that [[null]] would be exposed as nil and
[[false]] as well? Then would it be the case that (eq [[false]] [[null]])?
I really don't see how you expect to turn those into `nil', preserve
sane semantics (and Elisp performance), and be able to recover null, [],
and false when converting them back to JSON. You can probably pick any
two of the three, but all three together sounds pretty much impossible.
> - stored efficiently
Saying so is not sufficient to make it so.
> 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.
We're back at the FFI discussion, which is a different issue.
> 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.
C is not magic. Such a "feature" would require changes deep in the
elisp/bytecode interpreter, the NILP function/macro, ...
Stefan
next prev parent reply other threads:[~2013-10-19 14:37 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
2013-10-19 14:37 ` Stefan Monnier [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2016-12-29 20:52 bug#25295: 26.0.50; Represent eieio objects using object-print in backtraces and edebug Eric Abrahamsen
[not found] ` <handler.25295.B.148304476023950.ack@debbugs.gnu.org>
2016-12-29 21:50 ` bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug) Eric Abrahamsen
2017-01-03 18:21 ` bug#25295: Represent eieio objects using object-print in backtraces and edebug Stefan Monnier
2017-01-04 23:40 ` Eric Abrahamsen
2017-01-05 1:51 ` Stefan Monnier
2017-01-05 2:11 ` Stefan Monnier
2017-01-05 4:37 ` Stefan Monnier
2017-02-21 2:56 ` npostavs
2017-02-21 17:23 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv7gd9cqzi.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.