Unexpected multi receive matching & match variable binding behaviors

Description

While investigating pattern-matching for receives with multiple binds/listens, we found several questionable outputs from RNode.

This code suggests that the pattern-matching mechanism is not as robust as it should be.

So we have the name variable `chan1` binding to `@"B"` and the name variable `chan2` binding to `@"A"`. This seems unsatisfactory considering that in the to-be-matched receive `for( @x1 <- chan1 ; y1 <- chan2 ) { x1 }` the information obtained from channel `chan1` is used in the continuation, but in the candidate receive `for( @x <- @"A" ; @y <- @"B" ) { x }`, the information obtained from channel `@"A"` is used in the continuation. This should not be the case. The usage of `x1` in the to-be-matched receive's continuation and `x` in the candidate receive's continuation should constrain `chan1` to bind to `@"A"` and `chan2` to bind to `@"B"` to preserve the flow of information.

However, no comm occurs in the following code.

After discovering this pattern-matching peculiarity, we discovered other peculiarities in the `match` construct.

This should be behaviorally equivalent to our first test, according to which the output should be `("chan1", "B", "chan2", "A")` (even though this isn't desirable as explained above). This suggests there are also some inconsistencies in the pattern matching.

No trouble binding the free variable `yy` since it appears in the channel of first bind after ordering.

But trouble binding the free variable `xx` since it appears in the channel of the second bind after ordering.

Environment

None

Status

Assignee

Unassigned

Reporter

Isaac DeFrain

Priority

Medium

Affects versions

Components

Sprint

Epic Link

None

Labels

Fix versions

Configure