Re: The poor state of documentation of pcase like things.

[David Kastrup <dak@gnu.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 01/03/2016 11:02 AM, David Kastrup wrote:
>
>> Uh what?  Whether pcase does not help with simple cases should have
>> little bearing on whether it helps with more complex cases.
>
> But it does. It takes less code,

You mean, less input.

> and follows the common design of pattern matching, which isn't hard to
> understand and internalize.

And yet Emacs has more than just regexp operations for dealing with
strings, and most string operations are carried out without reverting to
regexps.

> In the more complex cases, the syntax may have some thorns,

Then it's not doing a good job of reducing complexity.  If it requires
me to use quasiquote for stuff that contains neither unquote nor
unquote-splicing (and has no sensible interpretation of unquote-splicing
in connection with its own use of quasiquote anyway), it does a bad
human interfacing job.  Why do I need to quote self-quoting expressions
at all?  And why do self-quoting symbols differ in meaning when preceded
by quasiquote?  In Lisp, `nil is equivalent to nil .  That's not what
pcase sees, I think.

What's actually involved here is that quoted parts are matched
literally, and unquoted symbols are matched to single elements.
Special-casing only ` and , to work according to that equivalence leads
to awkward input, awkward reading, and premature complexity.

> So if a person refuses to use it, *and* would choose to rewrite it
> using `cond' on any occasion, that tells me they won't reach for it in
> the more complex cases either.

We don't forcefeed people complex constructs for simple cases.  Even the
ubiquitous quasiquote is not used gratuitously in our code base just to
get people used to the idea they might want to use it in cases where it
would actually be needed in connection with unquote or unquote-splicing.

>> You are arguing as if we were paid for its use, not as if it had
>> inherent value.
>
> If *you* use it, *I* get to read it, and enjoy the succinctness and
> readability. And it's easier to extend later.

It is less succinct and readable than existing quite less complex
utilities for simple uses.

-- 
David Kastrup