I'm confused by the behavior of pattern matching in some cases. I'll discuss a few sets of examples involving segment patterns, then a mix of `and`, `or`, and `not` patterns.

Here is a basic segment pattern matching the entire contents of a list: > (match '(1 2 3) ((list x ...) `(result: ,x))) '(result: (1 2 3)) Let's add a prefix to the scrutinized list, and match it with a separate pattern variable: > (match '((1 2 3) 1 2 3) ((list w x ...) `(result: ,w ,x))) '(result: (1 2 3) (1 2 3)) Now let's constrain the prefix to be the same as the matched segment: > (match '((1 2 3) 1 2 3) ((list x x ...) `(result: ,x))) '(result: (1 2 3)) Everything seems fine so far. Let's make the segment pattern more interesting. This time, we'll have our segment pattern match elements that are lists of two elements: > (match '((a 1) (b 2) (c 3)) ((list (list k v) ...) `(result: ,k ,v))) '(result: (a b c) (1 2 3)) We can add a prefix as before, corresponding to the first element of each two-element list in the remaining segment, and match it with a separate pattern variable: > (match '((a b c) (a 1) (b 2) (c 3)) ((list j (list k v) ...) `(result: ,j ,k ,v))) '(result: (a b c) (a b c) (1 2 3)) So far so good. Now let's try constraining the prefix to be the same as the first element of each two-element list in the segment pattern: > (match '((a b c) (a 1) (b 2) (c 3)) ((list k (list k v) ...) `(result: ,k ,v))) ; k113: unbound identifier; ; also, no #%top syntax transformer is bound ; in: k113 ; [,bt for context] Something went wrong. Is this behavior expected? This error doesn't look like the kind you'd expect a user to see. Let's try another example with segment patterns: > (match '(1 2 3 : 1 2 3) ((list x ... ': y ...) `(result: ,x ,y))) '(result: (1 2 3) (1 2 3)) We're using : as a divider, allowing both the x and y segments to be non-empty. In this case, they are bound to the same values. What happens if we try to constrain the two segments to be identical by repeating the variable?: > (match '(1 2 3 : 1 2 3) ((list x ... ': x ...) `(result: ,x))) non-linear pattern used in `match` with ... at #<syntax:4:19 x> and #<syntax:4:10 x> '(result: (1 2 3)) It looks like we got the right result (see the next example), but it looks like an error message was printed beforehand. Is this message intended as a warning? Should it actually be raising an error instead? It almost looks like debug logging. Why might an error be the expected behavior? It seems we get the right result only coincidentally. If we remove the divider and use separate variables, we can see the greedy behavior of segment patterns: > (match '(1 2 3 1 2 3) ((list x ... y ...) `(result: ,x ,y))) '(result: (1 2 3 1 2 3) ()) When we try to constrain the segment by repeating the same variable, we get the printed warning followed by an unexpected result: > (match '(1 2 3 1 2 3) ((list x ... x ...) `(result: ,x))) non-linear pattern used in `match` with ... at #<syntax:8:16 x> and #<syntax:8:10 x> '(result: (1 2 3 1 2 3)) Is this greedy behavior expected even when the segment pattern variable is constrained in this way? It seems like we should at least get an error. Moving on, here's an example using `and` and `not` that behaves reasonably: > (match (list 1 2 3) ((and (list a _ _) (not (list _ a _))) `(result: ,a))) '(result: 1) We can see how the scrutinized list is being constrained to not repeat the same first two elements: > (match (list 1 1 3) ((and (list a _ _) (not (list _ a _))) `(result: ,a))) ; match: no matching clause for '(1 1 3) [,bt for context] If we swap the order of the sub-patterns, expecting the same behavior as the first example, we get a surprise: > (match (list 1 2 3) ((and (not (list _ a _)) (list a _ _)) `(result: ,a))) ; match: no matching clause for '(1 2 3) [,bt for context] It seems that the order of sub-patterns in an `and` pattern matters, and determines logical scoping of pattern variables. In the first pattern, we are getting the behavior of the logical proposition: (exists (a) (and (== VALUE (list a _ _)) (not (== VALUE (list _ a _))))) While in the second example, we seem to be getting the behavior of the logical proposition: (exists (a) (and (== VALUE (list a _ _)) (not (exists (a) (== VALUE (list _ a _)))))) Or, pushing the `not` inward slightly: (exists (a) (and (== VALUE (list a _ _)) (forall (a) (not (== VALUE (list _ a _)))))) Is this non-commutative behavior of `and` intended? Here's an example involving `and` and `or` that attempts to ensure that a three-element list either has identical first and second elements, or identical second and third elements: > (match (list 1 2 2) ((and (list a b c) (or (list _ a _) (list _ _ b))) 'success)) ; readline-input:2:47: match: variable not bound in all or patterns ; at: b ; in: (or (list _ a _) (list _ _ b)) ; [,bt for context] Given the binding behavior we saw with `and` in the previous example, I figured this one would work, since we're just reusing the same pattern variables. But instead we get an error about a variable not being bound in all `or` patterns. The documentation suggests something like this might be the case, "instances of an id in different or and not sub-patterns are independent. The binding for id is not available in other parts of the same pattern." But this seems inconsistent with the successful `(and ... (not ...))` example. Why does that one work, but this one not? What makes this really perplexing is that a slightly different set of examples, where we make sure to mention the same pattern variables in each disjunct, does work, this time ensuring that the first element is repeated in at least one of the other two positions: > (match (list 1 2 3) ((and (list a b c) (or (list _ a _) (list _ _ a))) 'success)) ; match: no matching clause for '(1 2 3) [,bt for context] > (match (list 1 2 1) ((and (list a b c) (or (list _ a _) (list _ _ a))) 'success)) 'success > (match (list 1 1 3) ((and (list a b c) (or (list _ a _) (list _ _ a))) 'success)) 'success Here's an example involving `not` and `or` that ensures the scrutinized three-element list does not repeat consecutive elements: > (match (list 1 2 3) ((not (or (list a a _) (list _ a a))) 'success)) 'success If we change the pattern variable in the second disjunct, the intended logical meaning is the same, but the example breaks: > (match (list 1 2 3) ((not (or (list a a _) (list _ b b))) 'success)) ; readline-input:13:34: match: variable not bound in all or patterns ; at: b ; in: (or (list a a _) (list _ b b)) ; [,bt for context] I can understand this behavior in the case of `or` appearing in a positive context (since otherwise we could introduce ambiguous bindings on the right-hand-side), but when negated, bindings for these pattern variables won't be available on the right-hand-side anyway. Is this behavior intended for simplicity of implementation? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.