Re: emacs-25 1d4887a: Improve documentation of 'pcase'

Re: emacs-25 1d4887a: Improve documentation of 'pcase'

[Michael Heerdegen]

Hi Eli,

thanks for finalizing this stuff.


Some comments:


> -To compare a particular value against various possible cases, the macro
> -@code{pcase} can come handy.  It takes the following form:
> +The @code{cond} form lets you choose between alternatives using
> +predicate conditions that compare values of expressions against
> +specific values known and written in advance.  However, sometimes it
> +is useful to select alternatives based on more general conditions that
> +distinguish between broad classes of values.  The @code{pcase} macro
> +allows to choose between alternatives based on matching the value of
> +an expression against a series of patterns.  A pattern can be a
> +literal value (comparison to literal values is what @code{cond}
> does),

That does sound more as a description of `cl-case' -- typo?


> +@defmac pcase expression &rest clauses
> +Evaluate @var{expression} and choose among an arbitrary number of
> +alternatives based on the value of @var{expression}.  The possible
> +alternatives are specified by @var{clauses}, each of which must be a
> +list of the form @code{(@var{pattern} @var{body-forms})}.

I think we should write @code{(@var{pattern} . @var{body-forms})}
                                             ^
if we mean that BODY-FORMS is a list, or use an ellipsis: "...", as you
do later.

> +The @var{pattern} part of a clause can be of one of two types:
> +@dfn{QPattern}, a pattern quoted with a backquote; or a
> +@dfn{UPattern}, which is not quoted.  UPatterns are simpler, so we
> +describe them first.

I had hoped we can get rid of the QPattern/Upattern distinction.  Is it
too late to change that?  In particular, we wanted to speak of just
patterns instead of Upatterns.

> +@item '@var{val}
> +Matches if the value being matched is @code{equal} to @var{val}.
> +@item @var{atom}
> +Matches any @var{atom}, which can be a keyword, a number, or a string.
> +(These are self-quoting, so this kind of UPattern is actually a
> +shorthand for @code{'@var{atom}}.)

Can we say "matches any (equal) atom"?  This makes a difference for
strings.

And actually, this is not true for floats, only for integers (I'm not
sure why).

> +Matches if @var{boolean-expression} evaluates to non-@code{nil}.  This
> +allows to include in a UPattern boolean conditions that refer to
> +symbols bound to values (including the value being matched) by
> +previous UPatterns.  Typically used inside an @code{and} UPattern, see
> +below.  For example, @w{@code{(and x (guard (< x 10)))}} is a pattern
> +which matches any number smaller than 10 and let-binds the variable
> +@code{x} to that number.

Maybe we should use

  @w{@code{(and x (pred numberp) (guard (< x 10)))}}

instead in the example, because without the numberp test, the pattern
will raise an error if x is not bound to a number.


> +@table @code
> +@item `(@var{qpattern1} . @var{qpattern2})
> +Matches if the value being matched is a cons cell whose @code{car}
> +matches @var{qpattern1} and whose @code{cdr} matches @var{qpattern2}.
> +@item `[@var{qpattern1} @var{qpattern2} @dots{} @var{qpatternm}]
> +Matches if the value being matched is a vector of length @var{m} whose
> +@code{0}..@code{(@var{m}-1)}th elements match @var{qpattern1},
> +@var{qpattern2} @dots{} @var{qpatternm}, respectively.
> +@item `(,@var{upattern1} ,@var{upattern2} @dots{})
> +Matches if the value being matched is a list whose elements match the
> +corresponding @var{upattern1}, @var{upattern2}, etc.
> +@item @var{atom}
> +Matches if corresponding element of the value being matched is
> +@code{equal} to the specified @var{atom}.
> +@item ,@var{upattern}
> +Matches if the corresponding element of the value being matched
> +matches the specified @var{upattern}.

Please decide if you include the backquote in all examples, or in none.
The thing we name "qpattern" is without backquote, so with the current
wording, I would leave the backquote out.

And these templates are not covering everything possible, e.g. you can
also have

  `(,up1 . ,up2)

or

  `(,up qp1)

I think I would reorganize that paragraph.


Many, many thanks so far.


Regards,

Michael.

Re: emacs-25 1d4887a: Improve documentation of 'pcase'

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: John Wiegley <jwiegley@gmail.com>,
>     Emacs Development <emacs-devel@gnu.org>
> Date: Sat, 23 Jan 2016 12:38:34 +0100
> 
> Hi Eli,
> 
> thanks for finalizing this stuff.

You are welcome.

> > -To compare a particular value against various possible cases, the macro
> > -@code{pcase} can come handy.  It takes the following form:
> > +The @code{cond} form lets you choose between alternatives using
> > +predicate conditions that compare values of expressions against
> > +specific values known and written in advance.  However, sometimes it
> > +is useful to select alternatives based on more general conditions that
> > +distinguish between broad classes of values.  The @code{pcase} macro
> > +allows to choose between alternatives based on matching the value of
> > +an expression against a series of patterns.  A pattern can be a
> > +literal value (comparison to literal values is what @code{cond}
> > does),
> 
> That does sound more as a description of `cl-case' -- typo?

No, of course not.  What's incorrect about that text regarding
'pcase'?

> > +@defmac pcase expression &rest clauses
> > +Evaluate @var{expression} and choose among an arbitrary number of
> > +alternatives based on the value of @var{expression}.  The possible
> > +alternatives are specified by @var{clauses}, each of which must be a
> > +list of the form @code{(@var{pattern} @var{body-forms})}.
> 
> I think we should write @code{(@var{pattern} . @var{body-forms})}
>                                              ^
> if we mean that BODY-FORMS is a list, or use an ellipsis: "...", as you
> do later.

Sorry, I don't understand why.  "Forms", in plural, means there are
more than one of them.  I'm okay with adding @dots{}, if you somehow
think it's required.  But using a cons cell would be too confusing, as
none of the examples uses that form.

> > +The @var{pattern} part of a clause can be of one of two types:
> > +@dfn{QPattern}, a pattern quoted with a backquote; or a
> > +@dfn{UPattern}, which is not quoted.  UPatterns are simpler, so we
> > +describe them first.
> 
> I had hoped we can get rid of the QPattern/Upattern distinction.  Is it
> too late to change that?  In particular, we wanted to speak of just
> patterns instead of Upatterns.

Find a better name for them, and we can switch.  Using "pattern" for
UPattern is not a good idea, IMO, as that word is too generic, and we
are describing a feature where we must use that word all the time.

> > +@item '@var{val}
> > +Matches if the value being matched is @code{equal} to @var{val}.
> > +@item @var{atom}
> > +Matches any @var{atom}, which can be a keyword, a number, or a string.
> > +(These are self-quoting, so this kind of UPattern is actually a
> > +shorthand for @code{'@var{atom}}.)
> 
> Can we say "matches any (equal) atom"?  This makes a difference for
> strings.

Why does it make a difference?

> > +Matches if @var{boolean-expression} evaluates to non-@code{nil}.  This
> > +allows to include in a UPattern boolean conditions that refer to
> > +symbols bound to values (including the value being matched) by
> > +previous UPatterns.  Typically used inside an @code{and} UPattern, see
> > +below.  For example, @w{@code{(and x (guard (< x 10)))}} is a pattern
> > +which matches any number smaller than 10 and let-binds the variable
> > +@code{x} to that number.
> 
> Maybe we should use
> 
>   @w{@code{(and x (pred numberp) (guard (< x 10)))}}
> 
> instead in the example, because without the numberp test, the pattern
> will raise an error if x is not bound to a number.

I don't think we need to be so pedantic in "for example" fragments,
they are just there to illustrate a point.

> 
> > +@table @code
> > +@item `(@var{qpattern1} . @var{qpattern2})
> > +Matches if the value being matched is a cons cell whose @code{car}
> > +matches @var{qpattern1} and whose @code{cdr} matches @var{qpattern2}.
> > +@item `[@var{qpattern1} @var{qpattern2} @dots{} @var{qpatternm}]
> > +Matches if the value being matched is a vector of length @var{m} whose
> > +@code{0}..@code{(@var{m}-1)}th elements match @var{qpattern1},
> > +@var{qpattern2} @dots{} @var{qpatternm}, respectively.
> > +@item `(,@var{upattern1} ,@var{upattern2} @dots{})
> > +Matches if the value being matched is a list whose elements match the
> > +corresponding @var{upattern1}, @var{upattern2}, etc.
> > +@item @var{atom}
> > +Matches if corresponding element of the value being matched is
> > +@code{equal} to the specified @var{atom}.
> > +@item ,@var{upattern}
> > +Matches if the corresponding element of the value being matched
> > +matches the specified @var{upattern}.
> 
> Please decide if you include the backquote in all examples, or in none.

I did.  The two last ones belong to the "issues" I raise in a separate
mail: I Think they don't have a place in this list, at least not in
that syntax.  When that discussion ends to my satisfaction, I will fix
whatever needs to be fixed.

> The thing we name "qpattern" is without backquote, so with the current
> wording, I would leave the backquote out.

There's no backquote in the QPatterns in the text I wrote, see above.
the backquote is explicitly prepended.  So I'm not sure how to
understand this comment.

> And these templates are not covering everything possible, e.g. you can
> also have
> 
>   `(,up1 . ,up2)
> 
> or
> 
>   `(,up qp1)
> 
> I think I would reorganize that paragraph.

When the fog and the dust settle down, perhaps I will.  For now, this
is the best I could come up with, and it closely follows what you
wrote in your guide, btw.

Thanks for reviewing it.

Re: emacs-25 1d4887a: Improve documentation of 'pcase'

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > > -To compare a particular value against various possible cases, the
> > > macro
> > > -@code{pcase} can come handy.  It takes the following form:
> > > +The @code{cond} form lets you choose between alternatives using
> > > +predicate conditions that compare values of expressions against
> > > +specific values known and written in advance.  However, sometimes it
> > > +is useful to select alternatives based on more general conditions
> > > that
> > > +distinguish between broad classes of values.  The @code{pcase} macro
> > > +allows to choose between alternatives based on matching the value of
> > > +an expression against a series of patterns.  A pattern can be a
> > > +literal value (comparison to literal values is what @code{cond}
> > > does),
> > 
> > That does sound more as a description of `cl-case' -- typo?
>
> No, of course not.  What's incorrect about that text regarding
> 'pcase'?

"A pattern can be a literal value (comparison to literal values is what
@code{cond} does)".

Comparison to literal values is what case does.  cond evaluates
expressions and looks whether the value is non-nil.


> > > +@defmac pcase expression &rest clauses
> > > +Evaluate @var{expression} and choose among an arbitrary number of
> > > +alternatives based on the value of @var{expression}.  The possible
> > > +alternatives are specified by @var{clauses}, each of which must be a
> > > +list of the form @code{(@var{pattern} @var{body-forms})}.
> > 
> > I think we should write @code{(@var{pattern} . @var{body-forms})}
> >                                              ^
> > if we mean that BODY-FORMS is a list, or use an ellipsis: "...", as you
> > do later.
>
> Sorry, I don't understand why.  "Forms", in plural, means there are
> more than one of them.  I'm okay with adding @dots{}, if you somehow
> think it's required.  But using a cons cell would be too confusing, as
> none of the examples uses that form.

But if body-forms is a list, you would get a template like

  (pattern (expr1 expr2))

and that's wrong.


> > > +The @var{pattern} part of a clause can be of one of two types:
> > > +@dfn{QPattern}, a pattern quoted with a backquote; or a
> > > +@dfn{UPattern}, which is not quoted.  UPatterns are simpler, so we
> > > +describe them first.
> > 
> > I had hoped we can get rid of the QPattern/Upattern distinction.  Is it
> > too late to change that?  In particular, we wanted to speak of just
> > patterns instead of Upatterns.
>
> Find a better name for them, and we can switch.  Using "pattern" for
> UPattern is not a good idea, IMO, as that word is too generic, and we
> are describing a feature where we must use that word all the time.

I just call them pcase patterns.


> > > +@item '@var{val}
> > > +Matches if the value being matched is @code{equal} to @var{val}.
> > > +@item @var{atom}
> > > +Matches any @var{atom}, which can be a keyword, a number, or a
> > > string.
> > > +(These are self-quoting, so this kind of UPattern is actually a
> > > +shorthand for @code{'@var{atom}}.)
> > 
> > Can we say "matches any (equal) atom"?  This makes a difference for
> > strings.
>
> Why does it make a difference?

Strings and floats don't only match themselves, but also any equal
string/float.  That's important, since not everything is always tested
with `euqal' - multiple occurrences of a symbol are turned into `eq'
tests, for example.


> > > +Matches if @var{boolean-expression} evaluates to non-@code{nil}.
> > > This
> > > +allows to include in a UPattern boolean conditions that refer to
> > > +symbols bound to values (including the value being matched) by
> > > +previous UPatterns.  Typically used inside an @code{and}
> > > UPattern, see
> > > +below.  For example, @w{@code{(and x (guard (< x 10)))}} is a pattern
> > > +which matches any number smaller than 10 and let-binds the variable
> > > +@code{x} to that number.
> > 
> > Maybe we should use
> > 
> >   @w{@code{(and x (pred numberp) (guard (< x 10)))}}
> > 
> > instead in the example, because without the numberp test, the pattern
> > will raise an error if x is not bound to a number.
>
> I don't think we need to be so pedantic in "for example" fragments,
> they are just there to illustrate a point.

But the reader may get the impression that such things are tested
implicitly, or the error is silenced and the pattern just doesn't match.
That's why I think it's a bad example without the additional test.


> > > +@table @code
> > > +@item `(@var{qpattern1} . @var{qpattern2})
> > > +Matches if the value being matched is a cons cell whose @code{car}
> > > +matches @var{qpattern1} and whose @code{cdr} matches @var{qpattern2}.
> > > +@item `[@var{qpattern1} @var{qpattern2} @dots{} @var{qpatternm}]
> > > +Matches if the value being matched is a vector of length @var{m}
> > > whose
> > > +@code{0}..@code{(@var{m}-1)}th elements match @var{qpattern1},
> > > +@var{qpattern2} @dots{} @var{qpatternm}, respectively.
> > > +@item `(,@var{upattern1} ,@var{upattern2} @dots{})
> > > +Matches if the value being matched is a list whose elements match the
> > > +corresponding @var{upattern1}, @var{upattern2}, etc.
> > > +@item @var{atom}
> > > +Matches if corresponding element of the value being matched is
> > > +@code{equal} to the specified @var{atom}.
> > > +@item ,@var{upattern}
> > > +Matches if the corresponding element of the value being matched
> > > +matches the specified @var{upattern}.
> > 
> > Please decide if you include the backquote in all examples, or in none.
>
> I did.  The two last ones belong to the "issues" I raise in a separate
> mail: I Think they don't have a place in this list, at least not in
> that syntax.  When that discussion ends to my satisfaction, I will fix
> whatever needs to be fixed.

Ok, I hope I don't miss it.


> > The thing we name "qpattern" is without backquote, so with the current
> > wording, I would leave the backquote out.
>
> There's no backquote in the QPatterns in the text I wrote, see above.
> the backquote is explicitly prepended.  So I'm not sure how to
> understand this comment.

I think Stefan has answered this question in a different post.  Sorry if
he answered other things already that I tell here.


> > And these templates are not covering everything possible, e.g. you can
> > also have
> > 
> >   `(,up1 . ,up2)
> > 
> > or
> > 
> >   `(,up qp1)
> > 
> > I think I would reorganize that paragraph.
>
> When the fog and the dust settle down, perhaps I will.  For now, this
> is the best I could come up with, and it closely follows what you
> wrote in your guide, btw.

Ok.


Thanks,

Michael.

Re: emacs-25 1d4887a: Improve documentation of 'pcase'

[Stefan Monnier]

> with `equal' - multiple occurrences of a symbol are turned into `eq'
> tests, for example.

Indeed, I think that was a mistake on my part.  We should change the
code to use `equal' there as well.


        Stefan

Re: emacs-25 1d4887a: Improve documentation of 'pcase'

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > with `equal' - multiple occurrences of a symbol are turned into `eq'
> > tests, for example.
>
> Indeed, I think that was a mistake on my part.  We should change the
> code to use `equal' there as well.

No strong opinion on my side.  I think I never had a case where it made
a difference.

FWIW Drew mentioned that it maybe could be cool if the equivalence
predicate could be specified locally for a pcase form like

(pcase my-string #'string-collate-equalp
   ("Noël" "Christmas"))

or so.


Michael.

RE: emacs-25 1d4887a: Improve documentation of 'pcase'

[Drew Adams]

> FWIW Drew mentioned that it maybe could be cool if the equivalence
> predicate could be specified locally for a pcase form like
> (pcase my-string #'string-collate-equalp ("Noël" "Christmas")) or so.

I didn't remember suggesting that, but I guess maybe you meant this:

   I think [pcase] is only useful when destructuring is
   involved.  If it is just doing literal pattern-matching
   then it offers nothing more than does `cl-case'.

   (Unless it lets you change the equality predicate (does it?).
   That's one thing that I wish `cl-case' (and Common lisp `case')
   would let you do: specify ... a comparer other than `eql'.)

Anyway, it's a good idea, but unlike the simple case of Common Lisp
`case', `pcase' uses multiple complex patterns, and they can involve
destructuring.

So in principle there could be a need to specify different equality
predicates for different patterns of the same `pcase', or even for
different parts of the same pattern.

Or maybe the different-parts-of-the-same-pattern problem could
be expressed in stages, i.e., by breaking a complex pattern into
multiple simpler patterns, each possibly with its own equality
predicate.

When it comes to pattern matching, different equality predicates
can become important.  In Lisp, we have `eq', `equal', `eql', `=',
`string=', etc., and users can of course define their own.

Re: emacs-25 1d4887a: Improve documentation of 'pcase'

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> So in principle there could be a need to specify different equality
> predicates for different patterns of the same `pcase', or even for
> different parts of the same pattern.
>
> Or maybe the different-parts-of-the-same-pattern problem could
> be expressed in stages, i.e., by breaking a complex pattern into
> multiple simpler patterns, each possibly with its own equality
> predicate.

That's already possible by calling a predicate explicitly by using pred,
e.g. instead of a second occurrence of SYMBOL you can use

 (pred (my-equal SYMBOL))

I think a distinct controlling mechanism for "implicit" equivalence
testing would make the thing too complicated.


Michael.

Re: emacs-25 1d4887a: Improve documentation of 'pcase'

[Stefan Monnier]

> FWIW Drew mentioned that it maybe could be cool if the equivalence
> predicate could be specified locally for a pcase form like
> (pcase my-string #'string-collate-equalp
>    ("Noël" "Christmas"))

We can already do that in the following way:

 (pcase my-string
   ((or (pred (string-collate-equalp "Noël"))
        (pred (string-collate-equalp "Christmas")))
    ...))

And if you think that's too verbose, you can define your own pcase-macro
so it can turn into something like:

 (pcase my-string
   ((or (my-string "Noël")
        (my-string "Christmas"))
    ...))


-- Stefan

Re: emacs-25 1d4887a: Improve documentation of 'pcase'

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: jwiegley@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 25 Jan 2016 14:49:20 +0100
> 
> "A pattern can be a literal value (comparison to literal values is what
> @code{cond} does)".
> 
> Comparison to literal values is what case does.  cond evaluates
> expressions and looks whether the value is non-nil.

What I meant was that 'cond' can be used to compare against literal
values.  I will tweak the wording to make that more clear, thanks.

> > > > +@defmac pcase expression &rest clauses
> > > > +Evaluate @var{expression} and choose among an arbitrary number of
> > > > +alternatives based on the value of @var{expression}.  The possible
> > > > +alternatives are specified by @var{clauses}, each of which must be a
> > > > +list of the form @code{(@var{pattern} @var{body-forms})}.
> > > 
> > > I think we should write @code{(@var{pattern} . @var{body-forms})}
> > >                                              ^
> > > if we mean that BODY-FORMS is a list, or use an ellipsis: "...", as you
> > > do later.
> >
> > Sorry, I don't understand why.  "Forms", in plural, means there are
> > more than one of them.  I'm okay with adding @dots{}, if you somehow
> > think it's required.  But using a cons cell would be too confusing, as
> > none of the examples uses that form.
> 
> But if body-forms is a list, you would get a template like
> 
>   (pattern (expr1 expr2))
> 
> and that's wrong.

I didn't say body-forms is a list.  I just said that there can be more
than one form there.

> > > > +The @var{pattern} part of a clause can be of one of two types:
> > > > +@dfn{QPattern}, a pattern quoted with a backquote; or a
> > > > +@dfn{UPattern}, which is not quoted.  UPatterns are simpler, so we
> > > > +describe them first.
> > > 
> > > I had hoped we can get rid of the QPattern/Upattern distinction.  Is it
> > > too late to change that?  In particular, we wanted to speak of just
> > > patterns instead of Upatterns.
> >
> > Find a better name for them, and we can switch.  Using "pattern" for
> > UPattern is not a good idea, IMO, as that word is too generic, and we
> > are describing a feature where we must use that word all the time.
> 
> I just call them pcase patterns.

Too wordy, IMO.  Try using that in the descriptions of each pattern,
and you quickly get a mouthful.

> > > > +@item '@var{val}
> > > > +Matches if the value being matched is @code{equal} to @var{val}.
> > > > +@item @var{atom}
> > > > +Matches any @var{atom}, which can be a keyword, a number, or a
> > > > string.
> > > > +(These are self-quoting, so this kind of UPattern is actually a
> > > > +shorthand for @code{'@var{atom}}.)
> > > 
> > > Can we say "matches any (equal) atom"?  This makes a difference for
> > > strings.
> >
> > Why does it make a difference?
> 
> Strings and floats don't only match themselves, but also any equal
> string/float.  That's important, since not everything is always tested
> with `euqal' - multiple occurrences of a symbol are turned into `eq'
> tests, for example.

But there's no reference to 'eq' or 'equal' in that text.  It just
says "matches".

> > > > +below.  For example, @w{@code{(and x (guard (< x 10)))}} is a pattern
> > > > +which matches any number smaller than 10 and let-binds the variable
> > > > +@code{x} to that number.
> > > 
> > > Maybe we should use
> > > 
> > >   @w{@code{(and x (pred numberp) (guard (< x 10)))}}
> > > 
> > > instead in the example, because without the numberp test, the pattern
> > > will raise an error if x is not bound to a number.
> >
> > I don't think we need to be so pedantic in "for example" fragments,
> > they are just there to illustrate a point.
> 
> But the reader may get the impression that such things are tested
> implicitly, or the error is silenced and the pattern just doesn't match.

There's no reason to believe readers will get such an expression from
something that is clearly an incomplete fragment.

> > > The thing we name "qpattern" is without backquote, so with the current
> > > wording, I would leave the backquote out.
> >
> > There's no backquote in the QPatterns in the text I wrote, see above.
> > the backquote is explicitly prepended.  So I'm not sure how to
> > understand this comment.
> 
> I think Stefan has answered this question in a different post.

He just said that he (and evidently you as well) use a different
"language" when you talk about QPatterns.  I think my "language" is
more easily understood and matches the actual usage better, even if
it's pedantically less rigorous.

Thanks.

Re: emacs-25 1d4887a: Improve documentation of 'pcase'

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > > > > The possible +alternatives are specified by @var{clauses},
> > > > > each of which must be a +list of the form @code{(@var{pattern}
> > > > > @var{body-forms})}.

> I didn't say body-forms is a list.  I just said that there can be more
> than one form there.

If a (meta) variable has a plural name, it's unexpected in Lisp that
it's not the name of a list or sequence, I think.


> > I just call them pcase patterns.
>
> Too wordy, IMO.  Try using that in the descriptions of each pattern,
> and you quickly get a mouthful.

In this context it's clear that we speak about pcase, so the generic
term pattern suffices.


> > Strings and floats don't only match themselves, but also any equal
> > string/float.  That's important, since not everything is always tested
> > with `euqal' - multiple occurrences of a symbol are turned into `eq'
> > tests, for example.
>
> But there's no reference to 'eq' or 'equal' in that text.  It just
> says "matches".

"Themselves" or "itself" in Lisp often means "only this object", that's
why I wanted to be precise.  But I won't argue about that one.


> > > > Maybe we should use
> > > > 
> > > >   @w{@code{(and x (pred numberp) (guard (< x 10)))}}

> There's no reason to believe readers will get such an expression from
> something that is clearly an incomplete fragment.

Ok, let's keep it.


> > > > The thing we name "qpattern" is without backquote, so with the
> > > > current wording, I would leave the backquote out.

> > I think Stefan has answered this question in a different post.
>
> He just said that he (and evidently you as well) use a different
> "language" when you talk about QPatterns.  I think my "language" is
> more easily understood and matches the actual usage better, even if
> it's pedantically less rigorous.

We speak about a language defined by a formal grammar, you about English
language.  I hope we can make the both fit.  Obscuring the formal
grammar will be confusing to some sort of people, depending on how they
build their mental models.


Michael.

RE: emacs-25 1d4887a: Improve documentation of 'pcase'

[Drew Adams]

> I think a distinct controlling mechanism for "implicit" equivalence
> testing would make the thing too complicated.

You mean it's not already too complicated? ;-)