Re: [PATCH] add compiled regexp primitive lisp object

[Danny McClanahan]

The talk description I submitted a bit ago can be viewed at 
https://emacsconf.org/2024/talks/regex/ for anyone who is interested. I am 
planning to be around over IRC for a good amount of the conference but 
especially around the talk time.

The description serves partially as a manifesto for my own purposes, and also 
as a self study of how Emacs allows the user to extract so much meaning out of 
pattern matching, as part of a general conception of Emacs as a mode of 
technical empowerment.

On Tuesday, November 26th, 2024 at 13:05, Danny McClanahan 
<dmcc2@hypnicjerk.ai> wrote:

> 
> 
> Thanks so much for this thorough and thoughtful response! I am compiling a 
> 20-minute recorded talk for the upcoming EmacsConf regarding these 
> discussions and investigations. I am also now waiting for a response from 
> graduate school, during which I hope to then have more time to pin down 
> several of the threads raised by this discussion.
> 
> This has all been immensely helpful and I really appreciate how responsive 
> emacs-devel has been in elaborating much of the packed-together assumptions I 
> was making.
> 
> On Tuesday, August 13th, 2024 at 21:32, Stefan Monnier 
> monnier@iro.umontreal.ca wrote:
> 
> > > Ignoring the issue that regexps may be syntax-table dependent and other
> > 
> > > complications (issues which also would need to be addressed in the
> > > proposed approach), what would be the advantage of exposing compiled
> > > regexp objects versus having an infinite regexp cache?
> > 
> > I can think of the following:
> > 
> > - Not having to pay as much attention to the engineering of the cache
> > (it's currently small because the lookup could become costly, with
> > the current implementation).
> > 
> > - We could offer to spend a fair bit more time optimizing the compiled
> > code (e.g. removing backtracking).
> > 
> > But there's always the question of whether it's worth the complexity.
> > IOW, what are the concrete use cases where it makes
> > a measurable difference.
> > 
> > Stefan
> 
> 
>