# How do I construct a Pattern with Alternatives and PatternSequence without getting Pattern::patvar messages?

Bug introduced 8.0 or earlier and persisting through 11.0 [CASE:3631078]

In Mathematica 8 and 9, defining this rule:

rule =
func[a | b, c_][PatternSequence[x_, z_] | PatternSequence[{x_}, z_]] :> {c, x, z}


leads to Pattern::patvar error messages. But it seems to apply correctly:

func[a, 2][1, 3] /. rule
(*  {2, 1, 3}  *)


In Mathematica 10, defining the rule works without error messages, but applying the rule gives Pattern::patvar error messages, although it returns the correct result.

I think I'm doing something wrong in making this pattern. Question: What is the correct way to construct it without getting error messages?

By the way, changing the c_ to a _ in rule makes the error go away:

rule =
func[a | b, _][PatternSequence[x_, z_] | PatternSequence[{x_}, z_]] :> {c, x, z}


But I need the c in the LHS because it appears in the RHS.

By the way #2, if I use this pattern:

rule = func[var : PatternSequence[a | b, c_]][
PatternSequence[x_, z_] | PatternSequence[{x_}, z_]] :> {c, x, z}


General::mbox errors are generated. In Mathematica 10, the error messages reveal that c_ is getting internally converted to Pattern[1,_]

HELP!

EDIT

I just realized that I can define the rule like this without problems:

rule = func[a | b, c_][{x_}|x_, z_] :> {c, x, z}


But this is an unfortunate case of stripping down too much from my real case which has variable number of arguments on each side of the Alternatives, like this:

rule =
func[a | b, c_][PatternSequence[x_, z_] | PatternSequence[{x_, z_}]] :> {c, x, z}


This still leads to Pattern::patvar error messages.

• The patvar messages also only appear on the first /., not subsequent ones (OS X 10.11.5, MMA 10.0.2.0)... – Marius Ladegård Meyer Jun 10 '16 at 15:50
• I'm pretty sure that the problem is in the argument part, i.e. the PatternSequence[ ...] | PatternSequence[ ... ] part, and that it's actually one of PatternSequence[x_, z_] or PatternSequence[{x_}, z_] that's getting converted to Pattern[1,_]. – march Jun 10 '16 at 16:14
• @march, then how can we explain the absence of errors when c_ is replaced by _ while the PatternSequence-stuff is the same? – Marius Ladegård Meyer Jun 10 '16 at 16:16
• I don't know, but if you get rid of the argument part and just do func[a | b, c_] :> ..., there's no problem. There's some strange interaction going on here. – march Jun 10 '16 at 16:17
• @MariusLadegårdMeyer. (See comment above; I forgot to ping you.) Simplified example: rule = f[c_][PatternSequence[x_, z_]] :> {c, x, z};Trace[f[a][1, 3] /. rule] then again Trace[f[a][1, 3] /. rule]. The first time it gives the error, but the second evaluation doesn't. And this error doesn't come up if f[c_] is replaced by f and f[a] is replaced by f. This verifies by the way that PatternSequence[x_, z_] is the part that is evaluating to Pattern[1,_]. – march Jun 10 '16 at 16:24

It seems like a glitch in the pattern matcher, occuring whenever named patterns appear in a head and PatternSequence appears at level 1 in the body.

Null /. f_[PatternSequence[x, y]] -> 0


Pattern::patvar : First element in pattern Pattern[1, _] is not a valid pattern name. >>

When there are multiple named patterns in the head there are additional warnings with different numbers:

Off[General::stop]

Null /. f[a_, b_, c_, b_][PatternSequence[x, y]] -> 0


Pattern::patvar : First element in pattern Pattern[1, _] is not a valid pattern name. >> Pattern::patvar : First element in pattern Pattern[2, _] is not a valid pattern name. >> Pattern::patvar : First element in pattern Pattern[3, _] is not a valid pattern name. >> Pattern::patvar : First element in pattern Pattern[2, _] is not a valid pattern name. >>

Note how the numbers in the messages follow the same sequence as the pattern names. It looks like the named patterns are internally associated with integer values and somehow the presence of PatternSequence in the body causes those integers to be processed as names.

I'm pretty sure this is unexpected behaviour and should be reported to Wolfram.

• This is really not good news, but thanks for the diagnosis. I'm observing that despite the warnings, the pattern matches as expected; would you know if this is harmless? – QuantumDot Jun 10 '16 at 20:39
• @QuantumDot, I don't know. Probably harmless as it seems to work okay despite the warnings, but I don't think I'd rely on it for anything important. Could you use a list of rules covering the different alternatives, or is it vital that the whole thing is expressed in a single rule? – Simon Woods Jun 10 '16 at 20:44
• I contacted Wolfram support [CASE:3631078], and they kindly pointed out that PatternSequence cannot be the only element of a pattern (see the documentation page, under Details). Since it is being used as only element of pattern in my original question, and in your reduced example, it cannot be expected to work correctly in those cases. I'm still thinking about whether what they say makes sense to me... – QuantumDot Jun 15 '16 at 6:17
• @QuantumDot, you should post that as an answer. It's not clear to me what exactly is meant by the "only element of a pattern", but it sounds like the result is not unexpected as far as Wolfram are concerned. – Simon Woods Jun 15 '16 at 7:47
• I noticed that OrderlessPatternSequence is documented as having the same behavior, and works without error messages if it is used in place of PatternSequence in my and your examples. I pointed this out to Wolfram support, and they have just confirmed that PatternSequence is not working as intended. Indeed this is a bug. – QuantumDot Jun 16 '16 at 6:21

In this case, the use of PatternSequence seems to be unnecessary. I think that the following achieves the desired result:

rule2 = HoldPattern[func[a | b, c_][({x_} | x_), z_]] :> {c, x, z}
func[a, 2][1, 3] /. rule2
func[a, 2][{1}, 3] /. rule2


In response to the edited question, I think the following works

rule3 = func[a | b, c_][{x__} | (x__)] :> {c, x}
func[a, 2][1, 3] /. rule3
func[a, 2][{1, 3}] /. rule3

• I noticed this just moments before you did; plz see my edit – QuantumDot Jun 10 '16 at 18:23