dyna
dyna copied to clipboard
OPCase proposal
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.
Hm. When I say "failures are ignored by OPCase
" after a successful test what I mean is that OPCase
is transparent to failures, not that it catches and suppresses them.
After discussions with @timvieira today, we've opted for a simpler 'OPDisj' which is just disjunction. We'll probably use it in the case where it's the last opcode in a sequence and all disjuncts end in OPEmit, but more generally OPDisj acts a lot like Prolog's semicolon. For details, see the code once it gets pushed. ;)