OPCase proposal #78
Description
It's probably time that DOpAMine grew up a bit and learned how to do case analysis all by itself. In particular, this would be of utility for inlining things like for.
I would like to propose adding two opcodes to the list (which you can find in its most recent form at https://github.com/nwf/dyna/blob/qpt/src/Dyna/Analysis/DOpAMine.hs#L51 ): OPFail and OPCase:
| OPFail
| OPCase [(DOpAMine bscg, DOpAMine bscg)]
OPFail is equivalent to OPCkne X X, or, more concretely, a Python continue statement: it abandons the current prefix of a hyper-edge. OPCase semantics are a bit more involved: the list is interpreted disjunctively with a first-one-wins semantics; each pair of opcode sequences therein represent a "test" and a "body". If the test fails (either with OPFail or a failing OPCheq or so on), then the OPCase considers the next arm. However, once the test has succeeded once, the body is run under any loops induced by the test, and subsequent failures in the body or test are ignored by OPCase. The reason to permit arbitrary code in the test position is for things like OPWrap or OPPeel as well as more general guards involving calls. So, for example, using $A, $B, ... to represent arbitrary chunks of DOpAMine:
OPAsnP x (DPInt 2)
OPAsnP y (DPInt 3)
OPCase [ (OPCheq x y, $A) , (OPBloc [], $B) ]
will have the same semantics as
OPAsnP x (DPInt 2)
OPAsnP y (DPInt 3)
$B
For non-deterministic tests, like
OPCase [ (OPIter r [a] f DetNon Nothing), $A), (OPBloc [], $B) ]
we would behave as if
OPIter r [a] f DetNon Nothing
$A
when there exists some X such that f(X) returns, and
$B
otherwise. If f is DetMulti then we always behave like the former, since we are promised at least one answer and need not test.
Can I get opinions on the design? @jeisner at an API level and @timvieira for a "can our codegen do this without a lot of pain?" level.