From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: User-defined record types Date: Fri, 18 Oct 2013 22:09:39 -0400 Message-ID: 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> <87wqlamacc.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1382148596 24066 80.91.229.3 (19 Oct 2013 02:09:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Oct 2013 02:09:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 19 04:10:00 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 1VXLzL-0004cG-NW for ged-emacs-devel@m.gmane.org; Sat, 19 Oct 2013 04:09:59 +0200 Original-Received: from localhost ([::1]:60038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXLzK-0003PT-RB for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2013 22:09:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXLzA-0003P3-Tu for emacs-devel@gnu.org; Fri, 18 Oct 2013 22:09:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXLz3-0003ou-KV for emacs-devel@gnu.org; Fri, 18 Oct 2013 22:09:48 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:47276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXLz3-0003oq-G3 for emacs-devel@gnu.org; Fri, 18 Oct 2013 22:09:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFsr+S0/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBsEtjWGDKQOkeoFegxM X-IPAS-Result: Av4EABK/CFFsr+S0/2dsb2JhbABEvw4Xc4IeAQEEAVYoCws0EhQYDYhCBsEtjWGDKQOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="35854948" Original-Received: from 108-175-228-180.dsl.teksavvy.com (HELO pastel.home) ([108.175.228.180]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Oct 2013 22:09:40 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 53007610B6; Fri, 18 Oct 2013 22:09:39 -0400 (EDT) In-Reply-To: <87wqlamacc.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Fri, 18 Oct 2013 19:24:19 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:164341 Archived-At: >>> 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