[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: User-defined record types
From: |
Stefan Monnier |
Subject: |
Re: User-defined record types |
Date: |
Fri, 18 Oct 2013 22:09:39 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
>>> 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.
You lost me: I though "null" and "empty list" were JSON thingies, so
I just offered you ways to represent them on the Elisp side. Of course,
when turning those elements into JSON, you'd be careful to map them to
the appropriate JSON elements.
> 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.
I still don't understand in what way a custom data structure would help.
>>> 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.
I still don't see what that means. In which way would it be cleaner or
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?
What alternative do you have in mind that would be more efficient and/or
more transparent?
Stefan
- Re: RFC: User-defined pseudovectors, (continued)
- Re: RFC: User-defined pseudovectors, Stefan Monnier, 2013/10/10
- Re: RFC: User-defined pseudovectors, Lars Brinkhoff, 2013/10/10
- Re: RFC: User-defined pseudovectors, Stefan Monnier, 2013/10/10
- Re: RFC: User-defined pseudovectors, Lars Brinkhoff, 2013/10/11
- 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 <=
- 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, 2013/10/19
- Re: User-defined record types, Stefan Monnier, 2013/10/19
- Re: RFC: User-defined pseudovectors, Stefan Monnier, 2013/10/10