From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Accept plists when serializing and parsing JSON Date: Sun, 03 Jun 2018 01:34:49 +0100 Message-ID: <87a7scu2qe.fsf@gmail.com> References: <87sh6awls5.fsf@gmail.com> <87in75bjvm.fsf@gmail.com> 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 1527986013 24086 195.159.176.226 (3 Jun 2018 00:33:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Jun 2018 00:33:33 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Yuri Khan , Emacs developers To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 03 02:33:29 2018 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 1fPGxb-00068k-OM for ged-emacs-devel@m.gmane.org; Sun, 03 Jun 2018 02:33:27 +0200 Original-Received: from localhost ([::1]:33195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fPGzi-0004VJ-QG for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2018 20:35:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fPGz5-0004Uz-2K for emacs-devel@gnu.org; Sat, 02 Jun 2018 20:35:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fPGz1-0000yP-VL for emacs-devel@gnu.org; Sat, 02 Jun 2018 20:34:59 -0400 Original-Received: from mail-wr0-x242.google.com ([2a00:1450:400c:c0c::242]:38361) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fPGz1-0000wr-NR for emacs-devel@gnu.org; Sat, 02 Jun 2018 20:34:55 -0400 Original-Received: by mail-wr0-x242.google.com with SMTP id 94-v6so39578100wrf.5 for ; Sat, 02 Jun 2018 17:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=QePV4TKhHoJbyyVOUd1ADzjp/iD6P1yarcfQ4/Nj2nM=; b=a05kDnOwzWhJziFzk/v4GXUg2h+lOxrxvip3Gb+qRtSTPN1LzOnCTe5PqYCGS7dKkS Mv/5JaxixtW027WPqfRlA0mAIzCUKEybPXLb0IfeYZl9ALrOpUIDdA4OIWCXDC7uHzOI UFm9AyzPK2whf90Y8/XwGWCWK4rWgZcVfs6kTF18S9N+fnweuFvjU1g+0ZZS5VQHk8jo 8xIZ/i9JnA1jtLXY1Sxm8LGEihdNpDrmF8QGXykZvPGnKfVhF9aEjtVBQwI2FIlQcl+j crw3SUhtozJjshN2aVSwIyaZNIxAVVjzZ5ulkpSSQ746Hykkim96yBWA40T15Q0EQuoX UPGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=QePV4TKhHoJbyyVOUd1ADzjp/iD6P1yarcfQ4/Nj2nM=; b=g/q0K33Bp+N7QOZqqM1OavLcJCjpBDvSZUA1QuJJ1elX39GTRkmTkC53qKsOpeAQgW I51Zc4QcXzDHRTdJSmmM1XByFgjB2wYAnK+dCSzI2pfx4KocGhmW1sVtuTZuLEHEMs66 jkhv5VMrL745LcqtPSJEh78GYY1NvC07ZiIQViY+gG4vG0Pe6d7lsA0k3xxn5Djj1NCu qWpEqC+7qwpRJ8ZjPwTQFH5c/OCHeQn9IzInHdDoVACiam88E55wJ+vWS1gYUSW7XwRx DsektVh62yKVNGSWWvUkV16ymEzKHbvN5Q67neWux0wFmit0FSWE96kN/oWbfuKUMtoW mxQA== X-Gm-Message-State: ALKqPwc+WGhMXDSEAwGwgM4unFXElmXeR3gVhpZ4jWhFUvHssmOBrdXC 0cYQJBjTrdLareUjX9KaAZHM5+BZ X-Google-Smtp-Source: ADUXVKKPLolep11p10I7h3fQtE8iUbUigs0WsKztIEbRvoc/GK0iQ3lJzDSbUAxy7kb49V7ZXw+nJw== X-Received: by 2002:adf:f2cb:: with SMTP id d11-v6mr11471591wrp.263.1527986093928; Sat, 02 Jun 2018 17:34:53 -0700 (PDT) Original-Received: from lolita.yourcompany.com (179.39.158.5.rev.vodafone.pt. [5.158.39.179]) by smtp.gmail.com with ESMTPSA id t13-v6sm9991330wro.62.2018.06.02.17.34.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 02 Jun 2018 17:34:52 -0700 (PDT) In-Reply-To: (Philipp Stephani's message of "Sat, 2 Jun 2018 10:04:55 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::242 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:225941 Archived-At: Philipp Stephani writes: > (a 1 b 2) gets serialized to {"a": 1, "b": 2} and then might reasonably > conclude that (a 1 :a 2) gets serialized to {"a": 1, ":a": 2}, but that > would be wrong. It's more obvious and easier to understand to not treat > colons specially. I think we should do what json.el does here. It's doing otherwise that would confuse people. >> char *keyword_key_str =3D SAFE_ALLOCA (1 + strlen(key_str) + 1); >> keyword_key_str[0]=3D':'; > Again, no special treatment for colons please. No. Because this would, with no obvious reason , defeat the main purpose of making plists, which is to use them in destructuring lambda lists, such as the one you yourself chose for json-parse-string. Regarding the doc comments, I'll do my best to rephrase and use consistent commas. I'll also add the test you suggested as well. >>>> talking about, because no part of the library is maintaining any state= in >>>> global variables -- it's read-only from json.c. >>> after ironing out all [the other?] bugs related to shared state >> Which ones? Those seem to be precisely the ones I meant to say are >> excluded because the var is read-only. > It is not read-only. If it were read-only, it would be just a constant > and not a variable (in the imperative programming sense) at all. Read some 5 lines above and you will see that what I meant, and indeed wrote, it's "read-only from json.c"". You may hold another interpretation, and that's just fine, but by "global state", in Emacs, I understand things like buffer, point, mark, match data, etc... That is, I mean exactly what Emacs adds to these functions' docstrings. From help-fns.el (when (or (function-get function 'pure) (function-get function 'side-effect-free)) (insert "\nThis function does not change global state, " "including the match data.")) This is what I mean by global state. Anything else is potentially erudite bikeshedding in which I'm not particularly interested right now. > There are many variables like this in emacs. > > Yes, unfortunately. That's no reason to introduce new ones. Emacs was > written in simpler times (the 1970s?) when the amount of code in the > world was much smaller and people didn't yet know everything that we I really don't think of programmers of the 70's as these simpletons, quite the contrary actually. Certainly the best programming paradigms IMHO are those started around that time, in Common Lisp for example, where dynamic variables abound. But as I write this, I feel the trappings another bikeshed starting to materialize so I must say that's just, like, my opinion, man. Jo=C3=A3o