You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 11, 2021. It is now read-only.
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.
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.
The text was updated successfully, but these errors were encountered:
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. ;)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
is equivalent toOPCkne X X
, or, more concretely, a Pythoncontinue
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 withOPFail
or a failingOPCheq
or so on), then theOPCase
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 byOPCase
. The reason to permit arbitrary code in the test position is for things likeOPWrap
orOPPeel
as well as more general guards involving calls. So, for example, using $A, $B, ... to represent arbitrary chunks of DOpAMine:will have the same semantics as
For non-deterministic tests, like
we would behave as if
when there exists some
X
such thatf(X)
returns, andotherwise. If
f
isDetMulti
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.
The text was updated successfully, but these errors were encountered: