GNU bug report logs - #18288
pcase documentation rewrite

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18288 in the body.
You can then email your comments to 18288 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mario Valencia <mariovalspi <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: pcase documentation rewrite
Date: Mon, 18 Aug 2014 00:48:03 -0500

[Message part 1 (text/plain, inline)]

The documentation in '(elisp) Pattern matching case statement' is very
difficult to understand. Could somebody please rewrite it so mere mortals
can read it? thnx

[Message part 2 (text/html, inline)]

Message #8 received at 18288 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Mario Valencia <mariovalspi <at> gmail.com>
Cc: 18288 <at> debbugs.gnu.org
Subject: Re: bug#18288: pcase documentation rewrite
Date: Mon, 18 Aug 2014 10:12:50 +0200

Mario Valencia <mariovalspi <at> gmail.com> writes:

Hi Mario,

> The documentation in '(elisp) Pattern matching case statement' is very
> difficult to understand. Could somebody please rewrite it so mere
> mortals can read it?

Could you be a bit more specific?  What exactly is difficult to
understand?  What further questions do you still have after reading the
docs?

Bye,
Tassilo

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: gnu-emacs-bug <at> moderators.isc.org
Subject: Re: bug#18288: pcase documentation rewrite
Date: Sat, 23 Aug 2014 14:57:05 +0000 (UTC)

[1}Tassilo Horn <tsdh <at> gnu.org> wrote:
>Mario Valencia <mariovalspi <at> gmail.com> writes:

>Hi Mario,

>> The documentation in '(elisp) Pattern matching case statement' is very
>> difficult to understand. Could somebody please rewrite it so mere
>> mortals can read it?

>Could you be a bit more specific?  What exactly is difficult to
>understand?  What further questions do you still have after reading the
>docs?

OK, I'll bite.  I think the OP was quite clear - he was utterly unable to
understand the page at all, so asking him for "further questions" is not
helpful.

After trying to read that info page several times over the last few
months, I've still only got a vague idea of how to use pcase, so I have to
agree with the OP.  Here are some of the things that are wrong:

(i) Bug: ".... and then compare the value against _each_ UPATTERN ...."
  is surely wrong - it will compare the value only against _some_
  UPATTERNs, stopping when a match is found.  Surely?

(ii) "UPATTERN" and "QPATTERN" have no definitions - only the
  relationship between them is sketched, not what they _are_.  This makes
  is difficult to get a conceptual handle on everything.

(iii) In the first example ("(pcase (get-return-code x) ...)") it is
  entirely unclear why the symbols there are quoted with backquote.  Why
  not just with quote?

(iv) It would seem that the reader macros backquote and comma mean
  something different in the pcase construct from their normal meanings.
  This desperately needs explicitly stating and emphasising, and early
  on.  What about ",@"?

(v) The meaning and rules for the idiosyncratic backquote and comma need
  to be rigorously and explicitly documented.

(vi) Where, if anywhere, inside a pcase construct can standard backquote
  be used?

(vii) "The UPATTERN mentioned above are ..." is a singlular noun with a
  plural verb.

(viii) [In the "definition" of QPATTERN] "The intention is to mimic the
  backquote macro: this pattern matches those values that COULD HAVE BEEN
  BUILT BY SUCH A BACKQUOTE EXPRESSION" is very vague.  What on earth is
  "could" supposed to mean here?  In what parallel universe might those
  values have been built?  "the backquote macro" could be confusing -
  there would seem to be (at least) two distinct backquote macros;
  perhaps the word "standard" should be inserted before "backquote".

(ix) [Carrying on from (viii)] "Since we're pattern matching rather than
  building a value, the unquote does not indicate where to plug an
  expression, but .....".  This is so bad as to be painful to dissect.
  o - What does "building a value" here mean?
  o - What's an "unquote"?  Throughout the Elisp manual "unquoted" means
    "not being quoted by '".  Is "backquote" meant here?
  o - What does "plug an expression" (at a place) mean?

(x) [Carrying on from (ix)] "... but instead it lets one specifiy a
  U-pattern that should match the value at that location".  Which
  "location"?  What does "location" even mean?  What "value"?

(xi) It would be really nice if "QPATTERN" were defined.

(xii) [First paragraph] "the macro `pcase' can come handy", should be
  "... can come IN handy".

(xiii) Why is the "don't care" symbol "_" rather that t?  This should be
  explained.

The entire page is wishy-washy and vague.  I think it probably makes good
sense to somebody who already knows how pcase works.  As I said, I
haven't grasped the pcase mechanism enough even to be able to criticize
the info page properly.  It would seem readers are expected to absorb the
details of pcase by osmosis rather than systematic reading.

>Bye,
>Tassilo

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.