GNU bug report logs - #20784
25.0.50; pcase documentation on t and nil

Previous Next

Full log

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 20784 <at> debbugs.gnu.org, Artur Malabarba <bruce.connor.am <at> gmail.com>
Subject: Re: bug#20784: 25.0.50; pcase documentation on t and nil
Date: Thu, 11 Jun 2015 15:18:28 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> > SELFQUOTING matches itself. This includes keywords, numbers, and
> > strings.
>
> > However, that doesn't apply to t and nil, instead, they are covered by
> > the SYMBOL clause.
>
> I think the problem is in the wording: t and nil are neither keywords,
> nor numbers, nor strings, which is why they aren't treated as
> SELFQUOTING.  IOW the wording shouldn't say "including" but make it
> clear that these are the (currently) only accepted selfquoting entities.
> E.g. vectors (and friends) aren't considered as SELFQUOTING by
> pcase either.

Just an opinion from another user:

I think the semantic of SELFQUOTING is so non-obvious and non-intuitive
that it's not worth it to confuse people who learn pcase with it, for
the sake that it's more or less the same as the pattern 'VAL, or a
subset from it:

SELFQUOTING applies to some atomic expressions that eval to themselves,
to others not.  SELFQUOTING "matches itself", which again depends on the
kind of thing.  It doesn't always mean `eq' (as the wording "itself"
suggests), because strings don't just match only themselves but any
other `equal' string.  But it also doesn't mean "equal" because in the
case of numbers, comparison is done with `eq':

(pcase 5.0
  (5 5)
  (5.0 5.0))  => 5.0

The case of t is especially non-obvious; it's neither treated as
SELFQUOTING nor as SYMBOL, but as a pattern matching anything.  While
`t' meaning "applies always" makes sense in `cond', because there the
right sides are interpreted as booleans, it can be IMHO confusing to
beginners in pcase because it could make you think that pcase is about
booleans, but it's about pattern matching.  I found myself trying stuff
like

  (pcase expr
    ((and x (symbolp x)) (symbol-name x))),

maybe having the `t' pattern in mind?

And `nil' OTOH is different again.  It is not interpreted as "applies
never", but raises an error when used  ("applies never" could make
sense when the code is generated by a macro).

I think I would consider to trivialize the semantic, merging the
SELFQUOTING and 'VAL case.

I would remove the SELFQUOTING thing as it is now.  I would keep the
semantic of 'VAL as it is now, as it is perfectly clear.  To substitute
the SELFQUOTING thing, we could allow something like ATOM - which can be
any atomic expression that is not a symbol that can be bound - and make
it simply an abbreviation for 'ATOM.  (FWIW, unifying `ATOM and 'ATOM
would IMHO also be worth it; currently 'ATOM is compared always with
`equal', whereby `ATOM is compared with `equal' for strings and `eq'
else.  You can always use guard when you want a different comparison
predicate.)

I know that would all would break existing code, but it would make pcase
easier to understand and to learn.

Just my two cents.


Regards,

Michael.

Previous Next

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