Skip to content
This repository has been archived by the owner on Jul 11, 2021. It is now read-only.

OPCase proposal #78

Open
nwf opened this issue Mar 6, 2014 · 2 comments
Open

OPCase proposal #78

nwf opened this issue Mar 6, 2014 · 2 comments
Assignees

Comments

@nwf
Copy link
Owner

nwf commented Mar 6, 2014

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.

@nwf nwf self-assigned this Mar 6, 2014
@nwf
Copy link
Owner Author

nwf commented Mar 6, 2014

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.

@nwf
Copy link
Owner Author

nwf commented Mar 7, 2014

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant