From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: JSON->lisp Mapping: Hash vs AList Date: Sun, 17 Dec 2017 17:44:34 +0000 Message-ID: References: <838te5uvee.fsf@gnu.org> <838te1qrkq.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1147dcac0b287c05608ccad8" X-Trace: blaine.gmane.org 1513532583 27708 195.159.176.226 (17 Dec 2017 17:43:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 17 Dec 2017 17:43:03 +0000 (UTC) Cc: emacs-devel@gnu.org, raman@google.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 17 18:42:58 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 1eQcxl-0006da-Uo for ged-emacs-devel@m.gmane.org; Sun, 17 Dec 2017 18:42:58 +0100 Original-Received: from localhost ([::1]:55036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQczh-0003Kk-4q for ged-emacs-devel@m.gmane.org; Sun, 17 Dec 2017 12:44:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56696) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQczZ-0003Kf-Qe for emacs-devel@gnu.org; Sun, 17 Dec 2017 12:44:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQczY-0005gR-KC for emacs-devel@gnu.org; Sun, 17 Dec 2017 12:44:49 -0500 Original-Received: from mail-qk0-x236.google.com ([2607:f8b0:400d:c09::236]:46147) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eQczW-0005dJ-J1; Sun, 17 Dec 2017 12:44:46 -0500 Original-Received: by mail-qk0-x236.google.com with SMTP id c85so1715726qkh.13; Sun, 17 Dec 2017 09:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jHnNUbG3ofbwb25mbIfxZLDVzNBnXytNG5HwoE19uzo=; b=HTBXAwhSXNTLFbzYWjJHnrjyEYsbBBE2yMbr9m2t8S2PkgyvrPRrQbFJQr5BEl8i/N miuUERFlkTRELqCvvyLfU7nHwqXa86D9BeMHrV06SvdwIbOLdmPx+ngLKwx+9tImYH2a zACSFGiH12LuBBYAtYNiyGOrtOMpgCSQETYi50OIlKr3BlnMcmspbIv4k2RWlBATTaom ZcbiAQ12h7g6WUJPGNZ5U3OSk/hufnUy8z1dJYmC95Aw8GYBDufTuhuuNk0BiD8BEyPP waeGrpkjEjjazK6T+OERn7dvp87O5mJgvqFrUERnxPrTXRRdazOvgyVIaGfXLc7C9X9q /ITw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jHnNUbG3ofbwb25mbIfxZLDVzNBnXytNG5HwoE19uzo=; b=mxl4iwWwR9zinkpGfccuqd6qqEnydlgTMG9cY8ZQxLMGpsqsZV/NPcl2adI/v7+De+ IL8lHbVshKVV00iQXFKJxszzYFOxqtW//ZKoYV8kDi8lKFNr8Z3RqaAhYU2znzGho2J4 +4/ORkz4eir9DZ40zZflCZ51BN2DZecN5rYxZn1Aqdfeb5bkR6kLjgR2U4KpRwfhH1sM 1CB2v01h7bBzt4tz2w33flHrRDBzPIP+q3ju1QIgu55QM5xjj74JH7xT6MZV2AKhj4GG TI0BnS0xc9F1e/sSho5vNO5rEkOvW7rQGLjHXlv1Dmd5XfQHaGh7OYbrOgN7HVXnUG1f +G7g== X-Gm-Message-State: AKGB3mI5iCADVXGS+aMmItHl4bY0xuj2I7xWUqzw20KTyx+B2fJUG++p FPTQi4YlvVxN8gbGhVqh3J3JnA0O0DfJ0dTgbZIXkw== X-Google-Smtp-Source: ACJfBouy2mrx6sEGNMv6CJC8YxhqO9GIBSeWT8XAIK48EprVryw1cfAmAIUHTFiKKXxlMbY0WyMrYRen04hh/o2xPeM= X-Received: by 10.55.31.131 with SMTP id n3mr7694791qkh.274.1513532684968; Sun, 17 Dec 2017 09:44:44 -0800 (PST) In-Reply-To: <838te1qrkq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c09::236 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:221178 Archived-At: --001a1147dcac0b287c05608ccad8 Content-Type: text/plain; charset="UTF-8" Eli Zaretskii schrieb am So., 17. Dez. 2017 um 16:53 Uhr: > > From: Philipp Stephani > > Date: Sat, 16 Dec 2017 22:24:35 +0000 > > Cc: raman@google.com, emacs-devel@gnu.org > > > > > -@defun json-parse-string string > > > +@defun json-parse-string string &key (object-type 'hash-table) > > > > Hmm.. why is there an apostrophe before "hash-table"? What do you > > want to get in the output there? > > > > An apostrophe? It seems to work as expected. > > That's not what I meant. I meant we never use a bare apostrophe in > Texinfo, we use markup instead. So I asked what you want to get there > in the Info and printed output, so I could suggest a proper markup. > My goal was to specify the default value the same way that cl-lib does. With cl-lib you'd write the function as (cl-defun json-parse-string (string &key (object-type 'hash-table))) We can't do that in C, but we can keep the same syntax. > > > And btw, I don't see "&key" mentioned anywhere in the ELisp manual, so > > I wonder whether the reader will understand what it means. > > > > This is the Common Lisp syntax, from cl-defun etc. It's a bit > unfortunate that it's not used in Emacs core, even > > for functions that take keyword arguments such as `make-process'. I can > switch to '&rest args' if you prefer > > that. > > Let's wait until the discussion of using &key in the code reaches its > conclusion. If &key will stay in the source, I do prefer &rest in the > manual. > I think the discussion will reach a conclusion if and when you or John as maintainers make a decision :-) > > > > + result = Fnreverse (result); > > > > Is there a reason for calling nreverse here? > > > > It puts the elements in the same order as the original JSON. (The > Jansson parser also retains the original > > order.) > > This isn't very important, just a bit nicer and less surprising. > > It's a potential performance hit, but if you think it's worthwhile, > it's fine with me. > I don't care much. For now I'd leave it in, we can take it out later if it hurts performance too much. (Though people that care about performance should probably use hashtables anyway.) > > > > +The keyword argument OBJECT-TYPE specifies which Lisp type is used to > > ^^^^^^^^^^^ > > Shouldn't that be `:object-type' (including quotes)? > > > > Depending on whether we can use &key in a docstring in core. If so, then > this one is correct, see e.g. the > > docstring of should-error. > > IMO, the doc string of should-error is no less confusing than this > one, because it expects something like ":type 'foo". > Arguably yes. Though that has been the convention for cl-lib functions for a while. --001a1147dcac0b287c05608ccad8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= So., 17. Dez. 2017 um 16:53=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 16 Dec 2017 22:24:35 +0000
> Cc: raman@google= .com, emacs-de= vel@gnu.org
>
>=C2=A0 > -@defun json-parse-string string
>=C2=A0 > +@defun json-parse-string string &key (object-type '= ;hash-table)
>
>=C2=A0 Hmm.. why is there an apostrophe before "hash-table"?= =C2=A0 What do you
>=C2=A0 want to get in the output there?
>
> An apostrophe? It seems to work as expected.

That's not what I meant.=C2=A0 I meant we never use a bare apostrophe i= n
Texinfo, we use markup instead.=C2=A0 So I asked what you want to get there=
in the Info and printed output, so I could suggest a proper markup.

My goal was to specify the default value the s= ame way that cl-lib does. With cl-lib you'd write the function as=C2=A0=

(cl-defun json-parse-string (string &key= (object-type 'hash-table)))

We can'= t do that in C, but we can keep the same syntax.
=C2=A0

>=C2=A0 And btw, I don't see "&key" mentioned anywhere= in the ELisp manual, so
>=C2=A0 I wonder whether the reader will understand what it means.
>
> This is the Common Lisp syntax, from cl-defun etc. It's a bit unfo= rtunate that it's not used in Emacs core, even
> for functions that take keyword arguments such as `make-process'. = I can switch to '&rest args' if you prefer
> that.

Let's wait until the discussion of using &key in the code reaches i= ts
conclusion.=C2=A0 If &key will stay in the source, I do prefer &res= t in the
manual.

I think the discussion will rea= ch a conclusion if and when you or John as maintainers make a decision :-)<= /div>
=C2=A0

>=C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 result = =3D Fnreverse (result);
>
>=C2=A0 Is there a reason for calling nreverse here?
>
> It puts the elements in the same order as the original JSON. (The Jans= son parser also retains the original
> order.)
> This isn't very important, just a bit nicer and less surprising.
It's a potential performance hit, but if you think it's worthwhile,=
it's fine with me.

I don't care= much. For now I'd leave it in, we can take it out later if it hurts pe= rformance too much. (Though people that care about performance should proba= bly use hashtables anyway.)
=C2=A0

>=C2=A0 > +The keyword argument OBJECT-TYPE specifies which Lisp type= is used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^
>=C2=A0 Shouldn't that be `:object-type' (including quotes)?
>
> Depending on whether we can use &key in a docstring in core. If so= , then this one is correct, see e.g. the
> docstring of should-error.

IMO, the doc string of should-error is no less confusing than this
one, because it expects something like ":type 'foo".

Arguably yes. Though that has been the conventi= on for cl-lib functions for a while.=C2=A0
--001a1147dcac0b287c05608ccad8--