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: Mon, 23 Dec 2024 18:49:06 +0200 Message-ID: <868qs64a65.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> <868qx8o83w.fsf@gnu.org> <875xscec62.fsf@gmail.com> <87o764sb6y.fsf@gmail.com> <87a5cn7cnu.fsf@localhost> <86cyhj5xmc.fsf@gnu.org> <87ttavlc50.fsf@localhost> <86a5cn5v1n.fsf@gnu.org> <87r05zlas8.fsf@localhost> <8634ie60jd.fsf@gnu.org> <87y106jr4i.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29908"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, mattiase@acm.org, arstoffel@gmail.com, eller.helmut@gmail.com, dmcc2@hypnicjerk.ai, pipcet@protonmail.com, emacs-devel@gnu.org, acorallo@gnu.org, stefankangas@gmail.com To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 23 17:49:45 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 1tPlcl-0007aU-RL for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Dec 2024 17:49:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPlcR-00016N-In; Mon, 23 Dec 2024 11:49:23 -0500 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 1tPlcM-00015u-3i for emacs-devel@gnu.org; Mon, 23 Dec 2024 11:49:20 -0500 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 1tPlcJ-0006Ro-Ql; Mon, 23 Dec 2024 11:49:15 -0500 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=bY0kTn+GUosRju9IVByV1G7/OyAa5lYE97s4N2Nuxwg=; b=affAN5/GOKh1 JK1g8QDbO4TJ8COC6NypFV2WB9LWDCci4iocaoWEbk7zv0OUPV63RmCccRsusVwOqySrJFfj4Jnw7 TbajPcwYOPR5DKiZseMCTTpS5ldHSbBQJ98Ol1/lPtW+hkb6EmOpdtCNCZ6YKW8rcQv51T+H9uAjb BStdkeN0yDxZiG2HfOTvu2ltnD9Asszlhpz92liXPoV4wr4fVZh7mKzALMfO5gu9B9pS7Ouzs9DMj FwCfDNzGzd/wuXrRU8ksz65702XcyMNri9gKekMmckV5xTKF9RZrL/4QR6gUMI+5xMFmxriS5L1aY F/zcYFsNKP4Idr+MiQ9llg==; In-Reply-To: <87y106jr4i.fsf@localhost> (message from Ihor Radchenko on Mon, 23 Dec 2024 16:33:49 +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:326921 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, mattiase@acm.org, arstoffel@gmail.com, > eller.helmut@gmail.com, dmcc2@hypnicjerk.ai, pipcet@protonmail.com, > emacs-devel@gnu.org, acorallo@gnu.org, stefankangas@gmail.com > Date: Mon, 23 Dec 2024 16:33:49 +0000 > > Having compiler regexp object exposed to Elisp would open the > following extra opportunities: > > 1. They could be inspected from Elisp, and hopefully optimized > better. For now, there is simply no way to detect which parts of > regexps are slow and which are not. If we can optimize them from Lisp, we should be able to do the same in C. If you explain what kind of optimization opportunities you had in mind, we could discuss how to implement that. In any case, adding APIs for regexp optimizations doesn't require to have compiled regexp objects. > 2. They could maybe even be constructed from Elisp, opening > opportunities for custom regexp compilers that can be tailored to > specific application needs rather than having to stick to hard-coded > generic tradeoffs Emacs has to do without knowing the purpose of a > regexp. How will this help making matching faster, and why does this have to be via compiled regexp objects?