From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Replace trivial pcase occurrences in the Emacs sources Date: Thu, 01 Nov 2018 22:02:51 +0200 Message-ID: <83efc4h8gk.fsf@gnu.org> References: <83tvlcsnee.fsf@gnu.org> <86mur137n8.fsf@gmail.com> <20181029130132.GB4195@ACM> <20181029134722.GC4195@ACM> <87lg6gifnb.fsf@web.de> <87muqwxs7m.fsf@ericabrahamsen.net> <83h8h3jlyd.fsf@gnu.org> <83efc7jjm2.fsf@gnu.org> <87tvl1poc8.fsf@portable.galex-713.eu> <83zhuth1z7.fsf@gnu.org> <87a7mtnziq.fsf@portable.galex-713.eu> <83va5ghdsx.fsf@gnu.org> <87bm78a8vm.fsf@portable.galex-713.eu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1541102474 8344 195.159.176.226 (1 Nov 2018 20:01:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Nov 2018 20:01:14 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Garreau\, Alexandre" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 01 21:01:10 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 1gIJ9R-00023C-M7 for ged-emacs-devel@m.gmane.org; Thu, 01 Nov 2018 21:01:09 +0100 Original-Received: from localhost ([::1]:43822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIJBY-0004YG-8p for ged-emacs-devel@m.gmane.org; Thu, 01 Nov 2018 16:03:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIJBR-0004YA-Rh for emacs-devel@gnu.org; Thu, 01 Nov 2018 16:03:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gIJBP-0003h7-3K for emacs-devel@gnu.org; Thu, 01 Nov 2018 16:03:13 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gIJBL-0003fr-8m; Thu, 01 Nov 2018 16:03:08 -0400 Original-Received: from [176.228.60.248] (port=2455 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gIJBJ-0000Hk-Uu; Thu, 01 Nov 2018 16:03:07 -0400 In-reply-to: <87bm78a8vm.fsf@portable.galex-713.eu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:230963 Archived-At: > From: "Garreau\, Alexandre" > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Thu, 01 Nov 2018 20:35:41 +0100 > > Let’s say this was in a language were arguments evaluation order is not > specified, and it is wrapped as macro/function set-two-vars-from-car-and-caddr, > how wouldn’t that match your definition? > > After all this later form can be considered as atomic, or pcase as not > atomic (it will necessarily get one value before the other) That's implementation details. We are talking about defining the concept. > > It didn't look like a more clear description to me, no. > > Do you have some more precise suggestion on why is not clear and how to > clearly phrase the concept of “specifying a matched data structure” One problem with your suggestion is that destructuring itself doesn't need specification of a matching structure to extract values into, that's only needed for destructuring binding. When explaining destructuring binding, I used "object of compatible structure" because I deliberately wanted to avoid using the concept of "matching", which can easily cause misinterpretation due to its other meanings in the context of Emacs. > should I just give up and accept the rest of world is fine with a more > loose, large, less specific, and according to me, wrong, definition of > “destructuring”? That's also an option, of course. Yet another option is to trust my experience in writing Emacs documentation a little more.