[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: User-defined record types
From: |
Ted Zlatanov |
Subject: |
Re: User-defined record types |
Date: |
Sat, 19 Oct 2013 16:11:41 -0400 |
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) |
On Sat, 19 Oct 2013 10:37:48 -0400 Stefan Monnier <address@hidden> wrote:
>> - 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').
SM> Let's call [[e]] the Elisp representation of JSON's e.
SM> Then you're saying that [[null]] would be exposed as nil and
SM> [[false]] as well? Then would it be the case that (eq [[false]] [[null]])?
I would leave that up to the creator of the user-defined record type.
SM> I really don't see how you expect to turn those into `nil', preserve
SM> sane semantics (and Elisp performance), and be able to recover null, [],
SM> and false when converting them back to JSON. You can probably pick any
SM> two of the three, but all three together sounds pretty much
SM> impossible.
The job of this hypothetical user-defined record type would be:
- preserve the original data
- provide the facilities to do value folding based on the underlying data type
- transparent conversion back and forth between ELisp and the C implementation
- preserve ELisp semantics as far as deemed necessary by the type's creator
>> 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.
SM> C is not magic. Such a "feature" would require changes deep in the
SM> elisp/bytecode interpreter, the NILP function/macro, ...
I understand that. Again, you asked about exciting features that could
come from user-defined record types. You didn't qualify it further as
"must be implemented with no major changes" etc.
So to restate things clearly, I think some facility that represents
structured data such as JSON, YAML, and XML well based on some
user-supplied mappings would be terrific. The current ELisp
representations of those three structured data formats are pretty lousy.
I think this facility would be useful in many other situations by
essentially encapsulating external data and providing an API on top.
Whether that's a realistic priority for anyone and whether it's
interesting to the Emacs maintainers, I don't know.
Ted
- Re: RFC: User-defined pseudovectors, (continued)
- Re: RFC: User-defined pseudovectors, Stefan Monnier, 2013/10/11
- User-defined record types, Lars Brinkhoff, 2013/10/12
- Re: User-defined record types, Stefan Monnier, 2013/10/15
- Re: User-defined record types, Ted Zlatanov, 2013/10/18
- Re: User-defined record types, Stefan Monnier, 2013/10/18
- Re: User-defined record types, Ted Zlatanov, 2013/10/18
- Re: User-defined record types, Stefan Monnier, 2013/10/18
- RE: User-defined record types, Drew Adams, 2013/10/18
- Re: User-defined record types, Ted Zlatanov, 2013/10/19
- Re: User-defined record types, Stefan Monnier, 2013/10/19
- Re: User-defined record types,
Ted Zlatanov <=
- Re: User-defined record types, Stefan Monnier, 2013/10/19
- Re: RFC: User-defined pseudovectors, Stefan Monnier, 2013/10/10