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

[David Kastrup]

Daniel Colascione <address@hidden> writes:

> On 01/03/2016 06:07 AM, David Kastrup wrote:
>> Dmitry Gutov <address@hidden> 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.
>
> A side effect of a more expressive system.
>
>>> 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.
>
> I find pcase quite readable; it's not going away.

So it should not get fixed or made more consistent with expectations?

> Honestly, I also found the existing documentation completely adequate.

The problem is that its underlying design principle, matching quoted
stuff structurally/literally and using unquoted symbols as variable
names, is only implemented in a cursory manner.  That means that reading
a pcase expression and understanding what it does does not enable you to
fix it with confidence or write your own.

Its forced use of `quasiquote' where `quote' would suffice were it
properly implemented is a contributor to the "there must be something
non-obvious going on" impression.

Scheme has the somewhat similar pattern matching library by Andrew
Wright <URL:http://wiki.call-cc.org/man/3/Pattern%20matching> but it
does not make the design mistake of using quasiquote while ignoring
quote.

People don't use it as a control structure replacement, however, in
spite of it being more coherent and powerful than Emacs' pcase.

It is used when needed and/or appropriate.  Which is perfectly fine.
For example, matching patterns in the byte compiler would be an
excellent case for working with matching/binding constructs of that
kind.

Indeed, Scheme's more "modern" replacement of the macro system, syntax
forms, tends to be used for a lot of code in Scheme
interpreters/compilers (particularly in GUILE-2.x, incidentally a
significant contributing factor to its abysmal bootstrapping performance
as the bootstrapping variant does not scale to the task) and is also of
somewhat similar kind.

But syntax-case system, while based on similarly syntaxed elements, is
quite different from a particular expression matcher as it basically is
used to extend one large global pattern matcher used for eval rather
than doing a single matching operation per call.

-- 
David Kastrup