bug#67611: [PATCH] Add a Pcase pattern `cl-lambda` equivalent to `cl-destructuring-bind`

[João Távora]

reopen 67611
thanks

On Fri, Jan 12, 2024 at 3:38 PM Stefan Monnier <monnier@iro.umontreal.ca> 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.
>
> Only some of them are.  Others are perfectly happy with using `pcase`
> but still aren't super happy about combining the complexity of `pcase`
> with that of CL destructuring syntax.
>
> Personally I'm rather put off by the difficulty of figuring out which
> part is using CL syntax and which part is using Pcase: the transition
> from Pcase to CL is fairly clear (marked by `cl-arglist` or somesuch),
> but the other is much less so.
> I'd be happier with a `cl-arglist` which cannot contain nested Pcase
> patterns (i.e. a one-way street from Pcase to CL) with
> `cl-destructuring-bind` reimplemented on top of it.

Can a pcase extension even be a one-way street?   And if so, isn't
that contrary to the whole purpose of pcase itself? Why have this ban
specifically on a CL pattern (should really be called "lambda-list"
by the way) when we have a cl library in core and so many uses
of CL things that use CL-style lambda lists, with or without cl-*.el.

We have so many other less commonly used extensions, some of them
subtle performance problems, like seq extensions that rely on generic
functions.

Pcase is complicated and hard-to-follow yes.  Becasue complex pattern
matching is a complicated thing to express, just as regular expressions
are such a thing (I for one do not think 'rx' makes things particularly
simpler). If you ask me, we'd be better off designing an "explain pcase"
utility or designing font-lock rules that helps explain it.

The byte-compiler  is already traversing that anyway and flagging
unused variables and stuff.  Can't we use this to mark what is a
lexical variable and what is a literal symbol, for example?  Can't
we have a very clear highlighting of the pcase extension being
used, like highlighting the '`' or the 'cl-arglist' or the 'seq'.

> I'd also be interested in a new Pcase pattern that provides the part of
> `cl-arglist` functionality that's missing from current Pcase patterns
> (like "optional" elements in a list), but with a syntax that blends
> better in Pcase patterns.

I'd rather not reinvent half-baked CL things, as it's all
too common to discover later we should have gone full-baked and
we have digressed for no good reason.

> > 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.
>
> That's a different question: improving up cl-lib's implementation would
> be welcome, yes.  That's not what the current patch does, tho.

It provides a tool to help do that, of course.

Anyway if there's some common ground here, let's not throw
the entire baby out with the bathwater.

Maybe Okamsn can repurpose the helper function he created
to parse lambda lists to be akin to Alexandria's
parse-simple-lambda-list.  It seems it already is fairly
close (the alist retun type in Elisp is natural as we don't
have multiple values).  Also the function's implementaion
should be changed to rely on as little as possible of
existing cl-macs (cl-copy-list and cl-flet can maybe
be skipped -- and maybe added back again later).

Shoulnd't be a very hard job (I might be wrong).

Then we can consider merging that including figuring out
where to merge it.

And then we can continue discussing about the usefulness
the pcase patterns that can be built with it, sure.

I've reopened the bug.

João