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

[Daniel Colascione]

On 01/03/2016 06:50 AM, David Kastrup wrote:
> 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.

I find it adequately general --- much more so than, say,
destructuring-bind. Do you have a concrete proposal?

signature.asc
Description: OpenPGP digital signature