[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Colascione
Subject: Re: The poor state of documentation of pcase like things.
Date: Sun, 3 Jan 2016 06:56:11 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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?

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]