From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] add compiled regexp primitive lisp object Date: Wed, 07 Aug 2024 15:00:51 +0300 Message-ID: <868qx8o83w.fsf@gnu.org> References: <87mslxxddk.fsf@protonmail.com> <5He97LtsyeyQoTLU7d91oP2CLO8s_2afdgcNxozsFjzu8qGbB_7nXmsZL5O6Ej7K-tuEmngCcPKJpDAjxeKz4jk1DvqSUbdOLpw5U1vo1SY=@hypnicjerk.ai> <87le1avopk.fsf@protonmail.com> <2LOLmIp1X8w4CGbqq3qDrzmKVA0KzYNL1N9lBtWdB-MtEv9oCuYgJMYprG170wMPjYxeQImAmWOPatGTTl4KxZMlptNo9A9hnHt84vdN9EA=@hypnicjerk.ai> <87ttfxtszi.fsf@protonmail.com> <86r0b1o5sr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37327"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, emacs-devel@gnu.org, mattiase@acm.org, acorallo@gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com To: Danny McClanahan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 07 14:02:49 2024 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 1sbfNR-0009Yo-4o for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Aug 2024 14:02:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sbfLp-0006qe-T1; Wed, 07 Aug 2024 08:01:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sbfLn-0006px-M3 for emacs-devel@gnu.org; Wed, 07 Aug 2024 08:01:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sbfLm-0006IU-Mp; Wed, 07 Aug 2024 08:01:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2qoTuVWfP/vh8eeizD0AWDKB518arLF4uUyTl0ao+ig=; b=lNLrqnple5OC 29LBzpePbk6DcQeQkTu9z3XN+TMwwPGlsoKN+y+voYlfJOg+Zb4zxBwOIHm/hJDFmcdUIn2anmpn+ AN6wsLZ0kqz0PsglorL95pW0Jv0Rj23sHMQyrvun7WmCYmcgLziym/77vAPtzQgZShun39wuPu32c c9/fOaS87tUx3eiP8L4UXPwAYyoLxMWX40XdhVOX2MuBm/F04wXoZiuugXDiKhVKnCjBhws7KBfiP R+t+KiTBex4tyWtXOy0OPyURTg6wmHBfHQT+sUb7gu/choSwmEV+Ytq8VhuV/LJcEV1cM32h5lkMP obIGhAOZhrgyhV/LYCnVZA==; In-Reply-To: (message from Danny McClanahan on Wed, 07 Aug 2024 04:23:33 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322499 Archived-At: > Date: Wed, 07 Aug 2024 04:23:33 +0000 > From: Danny McClanahan > Cc: Pip Cet , emacs-devel@gnu.org, mattiase@acm.org, Andrea Corallo , "monnier@iro.umontreal.ca" , "stefankangas@gmail.com" > > cc'ing Andrea Corallo, Stefan Kangas, and Stefan Monnier with a much more > concise email this time. > > > On Tuesday, August 6th, 2024 at 14:38, Eli Zaretskii wrote: > > > > I'm still waiting to see a concise description of the advantages of > > introducing these new objects. > > Right now, I think the optional STRING argument to `match-string' and > `replace-match' is the strongest argument that we are currently working around > a confusing implicit dependency on implicitly-clobbered global match data by > adding new optional arguments to low-level search functions to index into this > implicit global result cache which may be invalidated at any time. I think it > would make elisp programs easier to write if we had the `struct Lisp_Match' > object introduced by this patch. This argues that using the current regexps is inconvenient, and makes Lisp programs using regexps harder to write. Did I understand you correctly? > Separately, I think the fact that it's possible to mix up regexp patterns > (interpreted as a regexp string) and string arguments to search against > (interpreted as a literal string), and thereby induce silent search errors, is > the strongest argument for introducing a separate `struct Lisp_Regexp' > object. The fact that `search-spaces-regexp' can be set by a user and introduce > errors to modes which don't explicitly set it seems to bolster the argument that > introducing an explicit "compile" method for regexp patterns would make it > easier to write correct elisp extensions. And this says that the way we must use regexps is error-prone. Is that what you are saying? So these are two (or maybe even one) advantages, mainly in the convenience area. My counter-argument would be that the long history of using the current regexps in Emacs means that these advantages are relatively minor. I'm not sure they justify adding new objects into Emacs Lisp, with all its baggage. But maybe others will disagree with me. Are there other advantages? Thanks.