From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Leo Liu Newsgroups: gmane.emacs.bugs Subject: bug#20268: 25.0.50; pcase-lambda broken Date: Wed, 08 Apr 2015 09:01:13 +0800 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1428454943 8558 80.91.229.3 (8 Apr 2015 01:02:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Apr 2015 01:02:23 +0000 (UTC) To: 20268@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 08 03:02:11 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YfeNe-0000dI-2O for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Apr 2015 03:02:10 +0200 Original-Received: from localhost ([::1]:49798 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfeNd-0007N1-De for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Apr 2015 21:02:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfeNa-0007Mu-AY for bug-gnu-emacs@gnu.org; Tue, 07 Apr 2015 21:02:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfeNX-0000vi-3l for bug-gnu-emacs@gnu.org; Tue, 07 Apr 2015 21:02:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfeNW-0000vd-Vz for bug-gnu-emacs@gnu.org; Tue, 07 Apr 2015 21:02:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YfeNW-00034V-Jv for bug-gnu-emacs@gnu.org; Tue, 07 Apr 2015 21:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Leo Liu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Apr 2015 01:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20268 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20268-submit@debbugs.gnu.org id=B20268.142845489011767 (code B ref 20268); Wed, 08 Apr 2015 01:02:02 +0000 Original-Received: (at 20268) by debbugs.gnu.org; 8 Apr 2015 01:01:30 +0000 Original-Received: from localhost ([127.0.0.1]:48606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YfeMz-00033j-NZ for submit@debbugs.gnu.org; Tue, 07 Apr 2015 21:01:30 -0400 Original-Received: from mail-pd0-f170.google.com ([209.85.192.170]:33355) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YfeMx-00033V-MI for 20268@debbugs.gnu.org; Tue, 07 Apr 2015 21:01:28 -0400 Original-Received: by pdbnk13 with SMTP id nk13so96788969pdb.0 for <20268@debbugs.gnu.org>; Tue, 07 Apr 2015 18:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:face:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=Xleu0gW2qi1sZ1RAhkNFTxqyIkAb9siW7+Jkb4dY2Hs=; b=grf/vMORisIxz712tjDPtRbKOBtjz7NqmaAqnU3S58XaNimuO8ZSoSF0n1xOVcZEVO ODOvkhJ17kcvVJ03XVIwtgR15NSlJORcS4YvYpMZ6s7xOVkf+hab8wMRsvZhqR597UKK qZHqYYda81epoeSGf8WzE3Xvj37X5w52fmke5hq5o0/HZChhwF0SS/FSMVrfrPL3jFLL gRexXRnYOQQqaOXSX4JglAHKWeTQhAiZha5bSGkKs06ADMJJptKOaHEkRYb9N36V5kmx lzdlAZvrMjpIW+O+QTO7S4sCZN9ktQ6Kkc/gLNkZH0yahrqsPtj4MaDxJlnWQjI7oYP3 vj9w== X-Received: by 10.70.135.106 with SMTP id pr10mr41153594pdb.156.1428454881618; Tue, 07 Apr 2015 18:01:21 -0700 (PDT) Original-Received: from zeuss-MBP.lan ([128.199.230.246]) by mx.google.com with ESMTPSA id fm3sm9329521pdb.73.2015.04.07.18.01.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 18:01:20 -0700 (PDT) Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoBAMAAAB+0KVeAAAAGFBMVEUKDAg1NjRWV1V9fnyg op/DxcLk5uP8/voi63ReAAAACXBIWXMAAAWJAAAFiQFtaJ36AAAAB3RJTUUH1goZAgAz00bgXgAA AeVJREFUKM9lk0Fz2jAQhQXJD3CCO70CmcC1YMtcWyTZ14Bl69xats4N9r6/3zWQBlodNKNPu/s0 b1cCQFuZGpfVVh3vAvBJolIXRkapSuoRUtIdFyo1Y5xSdlAj7OtvD1XnXxmWRi+eWgcxyCed1lVV B1CrKyujMoi+eLA5kU1SsjoHlW+nQjTtFxk4MXgrOxvIqzoTZR8XgPaLl419zgsMaSGFPiUOZCIh thsx5Xy9NsK8Kwf/JoQgMxcVJ301HKkcSWaT0O7FY056J4U9xcYfnmVXG4801lW6lqwu2nKFZoHC HuzvaTVndZ+LaRQgZdthXw1cpynEkLEwyFHXk/aIxNQ6QeooJuzPMB+wn+D7JJNsiCcVA13/A3h/ xE9J+WidpAwoYNmRFwyvSRhNVtsdaAewzZZP5uw82QL9+tyNfocyP0McAzICUr5Mk9RdIjWasUNx aIIt6NK4ZtXIMdfMQt3nuMAyWbLI4DqZ4xPq/ag8jPond4XU/cLuOgw6XCFX/YCUfcDAMMH58fD4 G9kDchwfqVefkBwup2uZM+Q4WhJt5jN3AxXCsaS2yXEDuWgS8VOzW0gFjhEPmLyFMKBFaLb1HRwc DiaKwx0EeTMRYnYPQRW3PP4HApvlMv0PttX5v/D6Aws3IOSEwzmLAAAAAElFTkSuQmCC In-Reply-To: (Leo Liu's message of "Tue, 07 Apr 2015 15:42:32 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (OS X 10.10.2) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:101272 Archived-At: Forgive me to rely here. None of our messages shown up in bug#19670. > After recent rewrite of pcase-lambda I am seeing: > (cl-some (pcase-lambda (`[fullsweep_after ,v]) v) > '([min_bin_vheap_size 46422] > [min_heap_size 233] > [fullsweep_after 65535] > > [minor_gcs 10])) > > Indeed, that's the semantics I chose. > The previous semantics was for the function to do nothing and return nil > if the arg doesn't match. The new semantics is the same as the one used > by pcase-let. It's not without its fault of course, but at least it does > correspond to the usual idea of "destructuring" and generates more > efficient code. I don't mind new semantics but I want to make sense of it so as to use it with confidence. What I am seeing is: (funcall (pcase-lambda (`[fullsweep_after ,v]) v) [min_bin_vheap_size 46422]) => 46422 That doesn't make sense to me. Could you explain why this is the right thing? > I think if you prefer to return nil, then the macro should look like > (pcase-lambda ((`[fullsweep_after ,v]) v)) > which would then naturally let you add additional cases like > (pcase-lambda ((`[fullsweep_after ,v]) v) > ((`[min_heap_size ,v]) (/ v 2))) I didn't choose the multiple-clause version because it is a cheap shortcut for (lambda (...) (pcase ... ...)). The single-clause pcase-lambda makes a lot of higher-order functions fun to use and that is where I am reaping the benefits. > Admittedly, for the current pcase-lambda (and pcase-let) macro, the > pcase.el code should be refined so as to emit a warning when it ends up > ignoring a constant like `fullsweep_after' above. Yes, I am having a lot of trouble understanding and using pcase-let* except for trivial cases. I don't want the same thing to happen to pcase-lambda. > Stefan Thanks, Leo