emacs-devel
[Top][All Lists]
Advanced

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

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


From: Phillip Lord
Subject: Re: The poor state of documentation of pcase like things.
Date: Sun, 20 Dec 2015 18:51:54 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Michael Heerdegen <address@hidden> writes:

> address@hidden (Phillip Lord) writes:
>
>> Irrespective of whether you agree with this or not, what I would say is
>> that the current requirement for ,_ is not obvious, and that it is a
>> pcase "gotcha".
>
> You know, I wanted to make the same suggestion a year ago.  ,_ looks
> weird, I see all your arguments, they are all valid.
>
> But how would that fit into the semantics we have?  _ is a pcase
> pattern.  You would like it to be also a valid QPAT, matching anything.

I don't know. I am thinking of it from a point-of-view of the syntax I
would like as a user, rather than the semantics I would use to achieve
this.

I do worry that the syntax of pcase is too complex. As an example
compare dash.el and pcase:

(-let [(a b _) '(1 2 3)]
  (list a b))

(pcase-let
    ((`(,a ,b ,_) '(1 2 3)))
  (list a b))

I've chosen an extreme example here, but the pcase version has a lot of
punctuation (and worth remembering however familiar the macro expert is
with punctuation not all emacs-lisp programmers are).

Set against this, dash is imperfect in it's handling of "_". Compare:

(-let [(a b _) '(1 2 3)]
  (list a b _))

(pcase-let
    ((`(,a ,b ,_) '(1 2 3)))
  (list a b _))

The former returns "(1 2 3) while the later errors with "No such var".


> This would mess up the semantics to the worse: `_ would
> then be a pcase pattern matching anything.  Should '_ also match
> anything?  But how to match the symbol _ then?  If not, why should `_ be
> different from '_ when there is no unquoting involved?
>
> Or should _ as a QPAT only behave different when used "not at toplevel"?
> This would be horribly inconsequent: We would get two different types of
> QPATs: toplevel QPATS, and non-toplevel-QPATS.  That would confuse
> people even more, a pain to explain and to internalize.

I thought we were not going to mention q-patterns any more!

I think that too much of the implementation semantics is poking through
into the syntax. I suspect no one would notice if "_" matched anything
inside a backquoted list, because it feels natural.

Phil



reply via email to

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