[bitc-dev] Change to unions

[Jonathan S. Shapiro]

We have been looking at unions and value pattern matching, and I think
we are about to simplify them. The initial concern was that figuring out
whether a value match is complete is complicated, but the more we
thought about it the more we started to see a bigger issue: value
patterns are not syntactically robust.

Here is the main problem:

Suppose you define some union U:

  (defunion (U 'a 'b)
      (con1 'a 'b)
      ...)

Later, you write a case statement:

  (case U-instance
    ((con1 x y) ....)
    ...)

The problem here is that the pattern match is positional. If somebody
exchanges the positions of x and y in the defunion, existing code
breaks. If someone adds a field, existing code that probably doesn't
care fails to compile.

A lesser problem is syntax creep. Pattern matching a structure with 50
elements is (to be polite) exceptionally awkward.

All solutions to this require the addition of field names, so the
DEFUNION above would become:

  (defunion (U 'a 'b)
    (con1 x:'a y:'b)
    ...)

If we put in field names, then I also want to put in a non-positional
constructor syntax at some point in the future:

   (con1 [x:1 y:2])    # name:value pairs can appear in any order

No, that is not a serious syntax proposal. Just wanted to get the idea
across. One can *either* use purely positional initializers or purely
named initializers.

Once named fields are in place, there are two ways that we might resolve
the fragility of the CASE syntax:

1. Name-based pattern matching. The pattern

     (case U-instance
       ((con1 [x:1 ...]) e)
       ...)

   is taken to mean "an instance having the con1 discriminator tag,
   whose x field has the value 1 and all other fields are don't cares".

2. Drop pattern matching entirely:

     (case U-instance
       (s:#con1 e)
       ...)

   with the meaning that 'e' executes in a context where 's' has been
   bound to a *copy* of a structure that was implicitly defined by the
   case leg definition, and inside 'e' one may therefore make reference
   to 's.x' or 's.y'.

Ultimately, I think we want named fields for unions and named
initializers anyway, but in the short term I'm thinking to take option
(2) and defer the value pattern matching syntax entirely.

Does anybody find this violently objectionable?


shap