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: Sat, 19 Oct 2013 07:48:27 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87sivxmqgk.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> <87wqlamacc.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 1382183319 23005 80.91.229.3 (19 Oct 2013 11:48:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Oct 2013 11:48:39 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 19 13:48:43 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 1VXV1L-0003Kp-DO for ged-emacs-devel@m.gmane.org; Sat, 19 Oct 2013 13:48:39 +0200 Original-Received: from localhost ([::1]:32923 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXV1L-0006hw-2B for ged-emacs-devel@m.gmane.org; Sat, 19 Oct 2013 07:48:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXV1C-0006fC-Af for emacs-devel@gnu.org; Sat, 19 Oct 2013 07:48:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXV16-00087E-Bg for emacs-devel@gnu.org; Sat, 19 Oct 2013 07:48:30 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:52662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXV16-00086v-0n for emacs-devel@gnu.org; Sat, 19 Oct 2013 07:48:24 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VXV12-0003Aq-RO for emacs-devel@gnu.org; Sat, 19 Oct 2013 13:48:20 +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 13:48:20 +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 13:48:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 93 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:hF2xadN2hKlp97QAIUCdW8yOxFw= 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:164355 Archived-At: On Fri, 18 Oct 2013 22:09:39 -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> 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. The ELisp API to that C storage would map things to ELisp-land, but the original data would be preserved. >> 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. 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. >>>> 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> I still don't see what that means. In which way would it be cleaner or SM> 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? SM> What alternative do you have in mind that would be more efficient and/or SM> more transparent? Well, let's look at your original question: On Sat, 12 Oct 2013 14:58:15 -0400 Stefan Monnier wrote: >>> I'm not necessarily opposed to user-defined record types, but if >>> cl-defstruct is not sufficient and C-level changes are required, then >>> I'd hope for the new code to provide more exciting features than just >>> "vectorp returns nil". Look. This is JSON (YAML is similar; XML is much more complex but has similar conversion and implementation issues): { "x": 1, "y": [ null, [], true, false ] } A C structure would represent that as follows: - the number 1 would be stored as a JSON-spec integer, which is essentially a tagged string. These are not ELisp ints or bignums although the implementation can choose to limit them to Javascript ints. See http://www.json.org/ for the details on number formatting. - 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'). - stored efficiently All of this can be done in ELisp with custom symbols and other tricks, but I think a C implementation would be cleaner by being closer to the original input data and removing ELisp baggage from a simple data 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. 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. I don't think an ELisp implementation can do that unless all access goes through a forced API. So the exciting feature is that you don't have to work around the absence of these record types in ELisp. You may consider that an advantage (less C code = less maintenance) but the original question was about "exciting features" not maintainability. Ted