unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Bruce V Chiarelli <mano155@gmail.com>
Cc: Philipp Stephani <p.stephani2@gmail.com>,
	Theresa O'Connor <hober0@gmail.com>,
	emacs-devel@gnu.org
Subject: RE: two json.el bugs
Date: Sun, 28 May 2017 17:42:25 -0700 (PDT)	[thread overview]
Message-ID: <4fde90dc-4387-420a-a6fa-ec3f8d832327@default> (raw)
In-Reply-To: <871sr87gaz.fsf@topd0g>

> >> > 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.  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)
 
> 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.)



      reply	other threads:[~2017-05-29  0:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 17:51 two json.el bugs Theresa O'Connor
2017-05-05 18:44 ` Yuri Khan
2017-05-05 19:25   ` Drew Adams
2017-05-20 15:51   ` [PATCH] Fix definition of whitespace in JSON Philipp Stephani
2017-05-20 17:28     ` Dmitry Gutov
2017-05-21 21:03       ` Philipp Stephani
2017-05-27 13:32   ` two json.el bugs Philipp Stephani
2017-05-27 13:48 ` Philipp Stephani
2017-05-28  1:30   ` Drew Adams
2017-05-28 18:47     ` Philipp Stephani
2017-05-28 22:12       ` Drew Adams
2017-05-28 22:44         ` Bruce V Chiarelli
2017-05-29  0:42           ` Drew Adams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4fde90dc-4387-420a-a6fa-ec3f8d832327@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=hober0@gmail.com \
    --cc=mano155@gmail.com \
    --cc=p.stephani2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).