Interface with user-defined match monad?
if there's a __match
in scope, we use this as the match strategy, assuming it conforms to MatchStrategy as defined below:
Interface with user-defined match monad?
if there's a __match
in scope, we use this as the match strategy, assuming it conforms to MatchStrategy as defined below:
type Matcher[P[_], M[+_], A] = { def flatMap[B](f: P[A] => M[B]): M[B] def orElse[B >: A](alternative: => M[B]): M[B] } abstract class MatchStrategy[P[_], M[+_]] { // runs the matcher on the given input def runOrElse[T, U](in: P[T])(matcher: P[T] => M[U]): P[U] def zero: M[Nothing] def one[T](x: P[T]): M[T] def guard[T](cond: P[Boolean], then: => P[T]): M[T] }
P and M are derived from one's signature (def one[T](x: P[T]): M[T]
)
if no __match
is found, we assume the following implementation (and generate optimized code accordingly)
object __match extends MatchStrategy[({type Id[x] = x})#Id, Option] { def zero = None def one[T](x: T) = Some(x) // NOTE: guard's return type must be of the shape M[T], where M is the monad in which the pattern match should be interpreted def guard[T](cond: Boolean, then: => T): Option[T] = if(cond) Some(then) else None def runOrElse[T, U](x: T)(f: T => Option[U]): U = f(x) getOrElse (throw new MatchError(x)) }
Translate our IR (TreeMakers) into actual Scala Trees using the factory methods in MatchCodeGen.
The IR is mostly concerned with sequencing, substitution, and rendering all necessary conditions, mostly agnostic to whether we're in optimized/pure (virtualized) mode.