From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: two json.el bugs Date: Sun, 28 May 2017 17:42:25 -0700 (PDT) Message-ID: <4fde90dc-4387-420a-a6fa-ec3f8d832327@default> References: <16aabb87-3130-41b8-968e-52bc5aea3956@default> <4054d683-e291-4512-b5c6-1b10997c0d02@default> <871sr87gaz.fsf@topd0g> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1496018609 2693 195.159.176.226 (29 May 2017 00:43:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 May 2017 00:43:29 +0000 (UTC) Cc: Philipp Stephani , Theresa O'Connor , emacs-devel@gnu.org To: Bruce V Chiarelli Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 29 02:43:19 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dF8mF-0000ZI-2X for ged-emacs-devel@m.gmane.org; Mon, 29 May 2017 02:43:19 +0200 Original-Received: from localhost ([::1]:46296 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dF8mK-0001FQ-GS for ged-emacs-devel@m.gmane.org; Sun, 28 May 2017 20:43:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dF8lb-0001FL-HP for emacs-devel@gnu.org; Sun, 28 May 2017 20:42:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dF8lW-00038B-KZ for emacs-devel@gnu.org; Sun, 28 May 2017 20:42:39 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:43073) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dF8lW-000385-AW for emacs-devel@gnu.org; Sun, 28 May 2017 20:42:34 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4T0gUhi014409 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 29 May 2017 00:42:30 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v4T0gSHU011853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 May 2017 00:42:29 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v4T0gQaN009252; Mon, 29 May 2017 00:42:27 GMT In-Reply-To: <871sr87gaz.fsf@topd0g> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:215296 Archived-At: > >> > If you're talking about JSON objects then no, no particular > >> > meaning or behavior is defined for duplicate fields (keys) > >> > in a JSON object. > >> > > >> > A given application that handles JSON object is free to > >> > act as you say.=C2=A0 And it is free to act otherwise. > >> > >> Please see Theresa's initial post why this matters. > > > > It is generally good to preserve the order. With > > that general intention I agree. > > > > What's not true is that "in JSON the last one wins" > > when there are duplicates. JSON itself imposes no > > such semantics. > ECMA 404 doesn't specify anything about duplicate keys, And rightfully so. > but the JSON parser behavior _JavaScript_ JSON parser behavior > required by Section 24.3 of ECMA 262 does indeed. It's > not an implementation of course, but it does dictate how > compliant JS implementations should handle JSON. Yes, compliant _JavaScript_ implementations. Is `json.el' intended to provide JavaScript handling (compliant or not) of JSON data? Dunno. JavaScript is not JSON is not JavaScript. JSON is almost, but not quite, a subset of JavaScript object-literal notation (thus the name). JSON allows unescaped Unicode chars U+2028 (LINE SEPARATOR) and U+2029 (PARAGRAPH SEPARATOR) in strings. JavaScript notation requires such control chars to be escaped in strings. JavaScript is one language that parses and makes use of JSON data. It is not the only one. > From the end of listing 24.3.1.1: (24.5.1.1 in the latest draft) =20 > It could be argued that Emacs does not need to have (or pretend > to have) a 262-conforming parser. After all, it's not a JS > interpreter. But as Tess mentioned, this particular point > creates interoperability issues with conforming interpreters. Other things being equal, Emacs should preserve the order of JSON object fields, for maximum fidelity. Emacs should at least provide a way to preserve the order. And if there is no good reason to do otherwise then preserving the order should be the default behavior. Insofar as Emacs tries to handle JSON data as would a _JavaScript_ parser, stringifier, or interpreter, yes, it would be good for it to act similarly to what ECMA 262 prescribes. But that's about JavaScript, not JSON. Is `json.el' trying to provide a JavaScript parser for JSON? Dunno. The names and comments talk only about JSON and JSON parsing. JavaScript parsing of JSON is one way to go. (I have nothing against that, a priori.)