From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: User-defined record types Date: Fri, 18 Oct 2013 19:24:19 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87wqlamacc.fsf@flea.lifelogs.com> References: <85k3hlcqvm.fsf@junk.nocrew.org> <8561t5cclt.fsf@junk.nocrew.org> <85mwmgbb4l.fsf@junk.nocrew.org> <85vc12a36o.fsf_-_@junk.nocrew.org> <87a9i6ofzg.fsf@flea.lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1382138664 28951 80.91.229.3 (18 Oct 2013 23:24:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Oct 2013 23:24:24 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 19 01:24:25 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VXJP7-0005X9-EP for ged-emacs-devel@m.gmane.org; Sat, 19 Oct 2013 01:24:25 +0200 Original-Received: from localhost ([::1]:59721 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXJP6-0001Ra-Lz for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2013 19:24:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXJOy-0001RR-HD for emacs-devel@gnu.org; Fri, 18 Oct 2013 19:24:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXJOs-0006J3-MR for emacs-devel@gnu.org; Fri, 18 Oct 2013 19:24:16 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:57227) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXJOs-0006Iv-Cl for emacs-devel@gnu.org; Fri, 18 Oct 2013 19:24:10 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VXJOq-0005Nk-8S for emacs-devel@gnu.org; Sat, 19 Oct 2013 01:24:08 +0200 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Oct 2013 01:24:08 +0200 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Oct 2013 01:24:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 52 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:+MPm14tiw160aSFuvY7ym9HJVk8= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164338 Archived-At: On Fri, 18 Oct 2013 11:28:17 -0400 Stefan Monnier 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> IIUC The problem of json.el is that it wants to provide a bridge between SM> traditional Elisp data structures and JSON, and there is no reliable SM> two-way conversion between the two. SM> IIUC the current json.el focuses on making sure that converting to JSON SM> and back returns the same object. SM> But I don't see any technical difficulty writing a json2.el alternative SM> which focuses on "to Elisp and back", i.e. when it reads a JSON object SM> it returns an Elisp object that preserves all JSON nuances so that it SM> can be reliably converted back to the "exact same" JSON object. 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. >> 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> Whereas you seem to be talking about getting access to objects defined SM> in other (non-Lisp) libraries, i.e. an FFI. SM> Or maybe you're just talking about a more efficient representation for SM> an XML/JSON tree. If Lisp-defined data types could offer that, it would be SM> great, of course, but I personally don't see how that would work. 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? Ted