On Fri, Jan 12, 2024 at 3:05 AM Stefan Monnier wrote: > I don't think there's a clear enough need for it right now in Emacs core > to motivate its integration in Emacs proper. Also, because several > people have expressed an opinion that leans towards recommending that > Emacs's own code should probably better avoid using this functionality. Those people are trying to come up with alternative pattern-matching libraries which we start to see are not simpler or as powerful as pcase. But sure, other pattern-matching libraries exist out there. See CL's optima/trivia [1/2] for some very good ones. Emacs just happens to have pcase readily available. > I'd be quite happy to include such a think in GNU ELPA, OTOH. Could be, but why really? Why are CL things which rest on such high-quality well-known designs, older than many things Emacs, relegated to a place where they're less discoverable? Here, I think at least the new fresh implementation of lambda-list parsing (which is the meat-and-bones of this patch) is worth taking a look at. It's the function 'cl--pcase-cl-lambda-var-groups'. I would definitely consider grooming this function, renaming it, and keeping it in core, exposing to general Elisp usage in cl-macs.el (or cl-lambdalist.el, cl-ll.el), even if a new pcase pattern that uses it goes to ELPA (but why, really?) That util could help us write other lambda-list destructuring alternatives that understand &optional, &rest. Because with or without it, we already use a lot of the &optional, &rest explicitly in Emacs. And we also use &key and &allow-other-keys in many other places, though sometimes in ad-hoc lets-not-call-this-bull-by-its-name fashion. IOW there is no general purpose-util like Alexandria's 'parse-ordinary-lambda-list', and this could be it. It could not only be used to simplify and add coherence to many of these existing compile-time structures, for example helping simplify things and address FIXMEs in cl-lib.el. João [1] https://github.com/m2ym/optima [2] https://github.com/guicho271828/trivia