`pcase'/`case' implementation [Was: Re: Replace trivial pcase occurrences in the Emacs sources]

[Garreau\, Alexandre]

On 2018-10-29 at 16:18, Eric Abrahamsen wrote:
> Eric Abrahamsen <address@hidden> writes:
>> I wonder if the manual shouldn't have a section somewhere making
>> explicit the difference between `pcase' -- where a single value is
>> matched against many patterns, and may fail to match altogether, and
>> destructuring is only one of the use-cases -- and the other
>> pcase-derived forms, where many values are matched against a single
>> pattern, which *must* match (or error), and destructuring is kind of the
>> whole point. Conceptually, they're pretty different.
>
> In fact, when you think about it, the "case" nature of pcase is pretty
> orthogonal to the "match/destructure" nature of pcase. If anything
> fairly fundamental were to be done to refactor pcase, I wonder if it
> shouldn't be to separate these two concerns. In a sense, we already have
> `cl-case', why would we need another case-like structure? All we really
> need are new _matching forms_, which could be used within `cl-case',
> `dolist', `lambda'...

I also believe this.  We should, on one side, have a `match' function,
that would do more advanced destructuring than `cl-destructuring-bind'
(and, potentially, be based on it (so it could seeminglessly be used in
`pcase-lambda' on whole argument list), or the other way around, so
match returns an env (like other one-clause `match'), without having to
execute body, so to be more composable, and only then it would be used
in `cl-destructuring-bind' (which would then be accordingly more
powerful (but potentially incompatible in some corner cases (or more
than corner cases, if we don’t implement unquoted “(a . b)” where “a”
isn’t a predefined pattern, to match a cons)))), preferably based on it
(and potentially with an `unify' based on it).

Then, on another, I strongly believe we need a `case' struct that takes
a test function as an argument.  That test function might be `equal', so
that to make `case' generally more useful, but also `match', so now we
got a neat composition of two orthogonal and separate functions to make
a more complex one.  Then, we might tweak `case' so that to take the
result of the test function as an environment to be used for each BODY:
most test functions returns t, and in emacs, that’s already the void
environment referring to the global dynamical one, and `match' would
return what it bound.

Then `pcase' would simply be “case :test #'match” (like (setf pcase
(apply-partially #'case :test #'match)), but with its defun, docstring,
et al), get a simpler implementation, neat internal interfaces, and ends
that sort of sterile and useless implicit fight between `case' and
`pcase' (as they’re only two different levels).

I like minimalism, composition and reductionnism.