[e-lang] MatchBindExpr wierdness

[Jon Leonard]

On Sun, Apr 30, 2006 at 10:30:40PM -0700, Mark S. Miller wrote:
> The MatchBindExpr is an odd duck. In all other circumstances *except* the 
> MatchBindExpr, match-failure causes a non-local exit, preventing control flow 
> from continuing into the scope where variable defined by the pattern would be 
> visible. This is even true for typical uses of MatchBindExpr as well, such as:
> 
>      if ([i, j] =~ [x, y :char]) {
>          ... x ... y ...
>      } else {
>          # x and y are not in scope
>      }
> 
> However, because the MatchBindExpr evaluates to a boolean, if this boolean 
> isn't immediately used by an 'if' as above, then the question arises of what 
> values should 'x' and 'y' have when the pattern match fails. Dean has 
> identified two stances to take: "incremental" binding vs. "atomic" binding.
> 
> Let's say 'i' and 'j' both currently hold integers. Integers do not 
> auto-coerce to characters, causing the above match to fail when attempting to 
> match the 'y :char' sub-pattern. The issue is, this failure occurs after the 
> 'x' pattern match has succeeded, binding 'x' to the value of 'i'. In the scope 
> following the MatchBindExpr as a whole, 'y' is bound to a broken reference. 
> But what is 'x' bound to? Incremental binding says that all variables already 
> bound stay bound. Atomic binding says that all variable bound by a failed 
> pattern match are broken in the scope following the MatchBindExpr.

My gut reaction is that atomic binding is the right way to do this.
Searching for rationalizations, I came up with:

Atomic binding is a little easier to describe and understand:  Either it
binds all the variables, or none of them.

With atomic binding, there are less situations that the affected code
might have to handle, resulting in less opportunities for a programmer
to leave a rare mishandled case.

Atomic binding constrains the implementation less:  With incremental
binding, the patterns in some sense need to be evaluated in order, while
a hypothetical optimizing compiler might derive some benefit from
reordering.

Also, it looks like it isn't that hard to get the incremental behavior
from the atomic version, by breaking it up into MatchBindExprs, but the
reverse is trickier.

Those aren't the only possible choices;  A lazy implementation might only
do the matching check when the code gets used (with peculiar semantic
consequences), and so on.  But I don't believe that any other variant is
any clearer.

Jon Leonard