From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Pattern matching on match-string groups #elisp #question Date: Sat, 27 Feb 2021 15:32:02 -0500 Message-ID: References: <87v9agxkld.fsf@tcd.ie> <80CE2366-76F4-4548-B956-F16DFCE23E4C@acm.org> <258C930A-B183-4211-9917-0AD96C17A638@acm.org> <288FFC66-E3BE-4E5F-AAD5-309A632F8058@acm.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="344"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "Basil L. Contovounesios" , Ag Ibragimov , Emacs developers To: Mattias =?windows-1252?Q?Engdeg=E5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 27 21:33:31 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lG6HL-000AZn-1U for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Feb 2021 21:33:31 +0100 Original-Received: from localhost ([::1]:59058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lG6HK-00030d-4q for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Feb 2021 15:33:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58416) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lG6G5-0002G3-Cj for emacs-devel@gnu.org; Sat, 27 Feb 2021 15:32:13 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57911) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lG6G0-0001mV-UD for emacs-devel@gnu.org; Sat, 27 Feb 2021 15:32:12 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 41B1180880; Sat, 27 Feb 2021 15:32:06 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 797348026B; Sat, 27 Feb 2021 15:32:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1614457924; bh=EVGr7Q0nUu82U9ilrWMgrR6XNPo+QEcrmtTs8Rl/ZDg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nXqvUwqAvPTHVXd2FBfs2R0C0HTfFcKo0RXbB7oYR1olinsmSnyh06XSRUbAm7Tkc 6oa7bsP1Xy/oIsJDCbjJ7Y1v0WhKgwQchjWSf2HrSLsKL2Cok6cM7AfGTNjeh9gKSq 5QSRNRM+SBaF1sIBBP1Wfqgl2DIQn1LhQyVGldfah7IQTKjIj5n8q32b2PdS+QBiuD GX47QMcZW6LCY5uzoFGDK8SzGwEumJfzTtk/k8Jd/ozGDiMBHvorROrObI3vRbm9lU xLVIc6E4AyscqL42BZ4g5IcUyD+OG/vGQ+F8Nvs4fhcE3Ool32l9kRYgb4DSwf+Gc8 Cg0NSADa/jNIA== Original-Received: from alfajor (unknown [216.154.41.47]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2630A12017E; Sat, 27 Feb 2021 15:32:04 -0500 (EST) In-Reply-To: ("Mattias =?windows-1252?Q?Engdeg=E5rd=22's?= message of "Sat, 27 Feb 2021 19:10:59 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265735 Archived-At: >> Nevertheless, I went ahead with this change (after remembering that >> wrapping the code in `ignore` should eliminate the extra warnings). > So where does that leave us with the rx pattern? It doesn't affect it directly, except in the fact that the old definition would now also work for `pcase-let`. > Perhaps it is; a proposed diff is attached below which treats zero and one > variable specially and uses a list followed by immediate destructuring for > >1 variables. (By the way, using a backquote form to generate backquote > forms is annoying.) Indeed, nested backquotes are painful. > I now have, and am sad to say that a list is always faster for any practical > number of N (I didn't bother trying more than 30) although the difference > narrows as N grows. This is despite the destructuring code becoming > considerably bigger for lists (as we get a long chain of tests and branches) > than for vectors. It all boils down to vector construction being more > expensive than lists. Indeed, I think there's some optimization opportunities in our implementation of vector construction. We've already improved the performance significantly compared to Emacs<24, but there's still room for improvement. >> I don't think it's much more complicated than your current constant >> folding: when you see a let-binding of a variable to a *constructor*, >> stash that expression in your context as a "partially known constant" >> and then do the constant folding when you see a matching *destructor*. > > Doable, but definitely not low-hanging fruit. Since pcase has made a dog's > breakfast of the destructuring code it's not straightforward to recognise it > as such in the optimiser. Efforts needed elsewhere first! I wasn't talking about pcase-generated code in particular. But yes, it'd probably need to be combined with more general rewritings like "let associativity" in order to handle your particular case. I think we'd quickly get tired of scoping issues when doing that, so we'd want to first change the representation to one where that's less problematic (e.g. gensym all the lexical vars so we know there can't be any name capture when we massage the code, also also clearly separate lexical bindings from the dynamic bindings). >> go back to the last option it tried and accept it even though it failed >> to match. It still sucks, but maybe it'll give someone else a better idea? > Sounds like pcase--dead-end would fit then, at least as an internal name. > Or pcase--Sherlock-Holmes. Inspiring suggestions, thanks, Stefan