From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: New jrpc.el JSONRPC library Date: Wed, 23 May 2018 22:07:39 -0400 Message-ID: References: <87lgcrqgvz.fsf@gmail.com> <831seipvdb.fsf@gnu.org> <871se9lyid.fsf_-_@gmail.com> <87d0xqs56o.fsf@gmail.com> <87d0xp5e5o.fsf@gmail.com> <877enx5b3j.fsf@gmail.com> <87tvr04ymv.fsf@gmail.com> <87r2m26yrg.fsf@gmail.com> <871se2ds1o.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1527127588 17441 195.159.176.226 (24 May 2018 02:06:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 May 2018 02:06:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 24 04:06:24 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 1fLfe4-0004Nd-Bx for ged-emacs-devel@m.gmane.org; Thu, 24 May 2018 04:06:24 +0200 Original-Received: from localhost ([::1]:36160 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLfg6-0003Wt-4u for ged-emacs-devel@m.gmane.org; Wed, 23 May 2018 22:08:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42563) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLffV-0003Wb-Mv for emacs-devel@gnu.org; Wed, 23 May 2018 22:07:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLffQ-0000U4-Pj for emacs-devel@gnu.org; Wed, 23 May 2018 22:07:53 -0400 Original-Received: from [195.159.176.226] (port=40642 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fLffQ-0000Tg-II for emacs-devel@gnu.org; Wed, 23 May 2018 22:07:48 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fLfdH-0003b5-Fd for emacs-devel@gnu.org; Thu, 24 May 2018 04:05:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 30 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:zNAOteceO3VlPepAtduHkoLiwHc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:225640 Archived-At: > (cl-destructuring-bind (&key _boring-key very-important) > '(:very-important 42 :boring-key 92) > very-important) FWIW, we could of course do a (pcase-defmacro cl (...) ...) such that (cl-destructuring-bind PAT VAL EXP) can be written (pcase-let (((cl PAT) VAL)) EXP) This is the only significant advantage of pcase patterns: they're extensible, whereas CL's destructuring patterns are not. CL's destructuring patterns in return have the advantage of being available in cl-defmethod whereas there's no pcase-defmethod (yet?). With respect to the support for "default" and "provided-p" thingies, as recently mentioned elsewhere I prefer designs where we avoid distinguishing nil from "absent", so I rarely if ever need them. But of course, distinguishing nil from "absent" also comes with advantages, so it's just the usual style tradeoffs: If you're used to one style the other looks inconvenient. IOW, it's another bikeshed color. Stefan