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

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

[Dmitry Gutov]

On 01/03/2016 05:47 AM, Eli Zaretskii wrote:

> The syntax of 'when' is nowhere as complex as that of 'pcase'.

Obviously.

But the given example uses a simple, small subset of pcase syntax. If 
you don't want to use even that, it seems to indicate that you're going 
to avoid the more complex uses of it even more so. And thus, never use 
pcase at all.

Which doesn't seem like a good choice, from my perspective.

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

[David Kastrup]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 01/03/2016 05:47 AM, Eli Zaretskii wrote:
>
>> The syntax of 'when' is nowhere as complex as that of 'pcase'.
>
> Obviously.
>
> But the given example uses a simple, small subset of pcase syntax. If
> you don't want to use even that, it seems to indicate that you're
> going to avoid the more complex uses of it even more so.

Uh what?  Whether pcase does not help with simple cases should have
little bearing on whether it helps with more complex cases.

> And thus, never use pcase at all.

If it does not help with simple cases, and it does not help with complex
cases, yes, that would be the obvious best choice.  I don't think that
this the argument you intend to make.

> Which doesn't seem like a good choice, from my perspective.

You are arguing as if we were paid for its use, not as if it had
inherent value.

Let it make its own case where it actually brings something to the
table.  We don't replace trivial cases of `if` with `cond`, `while` with
`cl-loop` and so on.

If we used constructs for the sake of using constructs, the code base
would show a lot more use of `cl-do` (which offers little savings in
return for its unreadability).

Let it speak for itself where it makes sense instead of everywhere.

-- 
David Kastrup

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

[Dmitry Gutov]

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, and follows the common design of 
pattern matching, which isn't hard to understand and internalize. In the 
more complex cases, the syntax may have some thorns, but not in cases 
where you could replace it with `cl-case'.

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.

> If it does not help with simple cases, and it does not help with complex
> cases, yes, that would be the obvious best choice.  I don't think that
> this the argument you intend to make.

And I didn't.

> 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.

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

[David Kastrup]

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

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

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

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. Honestly, I also found
the existing documentation completely adequate.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[David Kastrup]

Daniel Colascione <dancol@dancol.org> writes:

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

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]

On 01/03/2016 06:50 AM, David Kastrup wrote:
> Daniel Colascione <dancol@dancol.org> writes:
> 
>> On 01/03/2016 06:07 AM, David Kastrup wrote:
>>> 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.
>>
>> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Dmitry Gutov]

On 01/03/2016 04:50 PM, David Kastrup wrote:

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

I think you should file bug(s) with specific examples and improvements.

> 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.

IIUC, you can use quotes where they would "suffice".

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

[David Kastrup]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 01/03/2016 04:50 PM, David Kastrup wrote:
>
>> So it should not get fixed or made more consistent with expectations?
>
> I think you should file bug(s) with specific examples and improvements.
>
>> 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.
>
> IIUC, you can use quotes where they would "suffice".

So why would people write

(pcase exp
  (`nil nil) ...

?  What's with the overuse of quasiquote?

-- 
David Kastrup

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

[Dmitry Gutov]

On 01/03/2016 05:15 PM, David Kastrup wrote:

> So why would people write
>
> (pcase exp
>    (`nil nil) ...

Easier to just use the same kind of quote everywhere?

> ?  What's with the overuse of quasiquote?

You should ask those people.

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

[Eli Zaretskii]

> Cc: dancol@dancol.org, michael_heerdegen@web.de, dak@gnu.org,
>  emacs-tangents@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 3 Jan 2016 06:08:35 +0200
> 
> On 01/03/2016 05:47 AM, Eli Zaretskii wrote:
> 
> > The syntax of 'when' is nowhere as complex as that of 'pcase'.
> 
> Obviously.
> 
> But the given example uses a simple, small subset of pcase syntax. If 
> you don't want to use even that, it seems to indicate that you're going 
> to avoid the more complex uses of it even more so. And thus, never use 
> pcase at all.
> 
> Which doesn't seem like a good choice, from my perspective.

But that's not my choice.  My choice is to use 'pcase' where it's
really needed.

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

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> But that's not my choice. My choice is to use 'pcase' where it's really
> needed.

I like `destructuring-bind' for simple pattern matches, and cond for simple
logic, but I really like pcase for combining the two. I guess we're all really
just arguing about balance, which even for one individual changes based on
mood and perspective.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2