MLton

MatchCompile is a translation pass, agnostic in the IntermediateLanguages between which it translates.

Description

Match compilation converts a case expression with nested patterns into a case expression with flat patterns.

Implementation

Details and Notes

val matchCompile:
   {caseType: Type.t, (* type of entire expression *)
    cases: (NestedPat.t * ((Var.t -> Var.t) -> Exp.t)) vector,
    conTycon: Con.t -> Tycon.t,
    region: Region.t,
    test: Var.t,
    testType: Type.t,
    tyconCons: Tycon.t -> {con: Con.t, hasArg: bool} vector}
   -> Exp.t * (unit -> ((Layout.t * {isOnlyExns: bool}) vector) vector)

matchCompile is complicated by the desire for modularity between the match compiler and its caller. Its caller is responsible for building the right hand side of a rule p => e. On the other hand, the match compiler is responsible for destructing the test and binding new variables to the components. In order to connect the new variables created by the match compiler with the variables in the pattern p, the match compiler passes an environment back to its caller that maps each variable in p to the corresponding variable introduced by the match compiler.

The match compiler builds a tree of n-way case expressions by working from outside to inside and left to right in the patterns. For example,

case x of
  (_, C1 a) => e1
| (C2 b, C3 c) => e2

is translated to

let
   fun f1 a = e1
   fun f2 (b, c) = e2
in
  case x of
     (x1, x2) =>
       (case x1 of
          C2 b' => (case x2 of
                      C1 a' => f1 a'
                    | C3 c' => f2(b',c')
                    | _ => raise Match)
        | _ => (case x2 of
                  C1 a_ => f1 a_
                | _ => raise Match))
end

Here you can see the necessity of abstracting out the ride hand sides of the cases in order to avoid code duplication. Right hand sides are always abstracted. The simplifier cleans things up. You can also see the new (primed) variables introduced by the match compiler and how the renaming works. Finally, you can see how the match compiler introduces the necessary default clauses in order to make a match exhaustive, i.e. cover all the cases.

The match compiler uses numCons and tyconCons to determine the exhaustivity of matches against constructors.