Allowing rules to depend upon SimplCont

[Ben Gamari]

In Bug #9661, Comment #12 Simon Peyton-Jones wrote [1],

> Annoyingly, the `CoreSyn.RuleFun` API for built-in rules does not give
> access to the context of an application (the `SimplCont`), but it
> would not be hard to make it do so.
> 
> So if that is the right rewrite, then it'd be another useful project
> for someone.

I started taking a look at this over the weekend, hoping for a
weekend-ish project. Unfortunately it's not as easy as it initially
looked.  The current state of my work can be found here [2].  The core
of the change (as I understand it) is to add a `SimplCont` argument to
`RuleFun` [3] although things are in actuality a bit more complicated

While it was easy to pipe through the `SimplCont` in the simplifier
itself (as it was already keeping track of the `SimplCont` context),
`ruleCheck` in `Rules.hs` does not know anything about the simplifier or
`SimplCont`.

Currently `ruleCheck` is quite simple: It traverses the program
examining function applications, looking for rules which apply to the
applied function and match a user-specified predicate. It then produces
a human-readable message in the event that the rule would not
fire. Unfortunately, to evaluate whether the rule will fire we actually
need to try calling the `RuleFun`, which now requires having a
`SimplCont`.

As far as I can tell there are three ways to address this,

 1. Pass a dummy `SimplCont` (probably a `Stop`) to the `RuleFun`. This
    is by far the easiest option but will result in discrepancies
    between the rule check and the rules actually fired by simplifier.
    
 2. Replicate the simplifier's logic to produce a `SimplCont` in the
    rule check. This seems like it will result in a great deal of
    unnecessary (and non-trivial) code duplication.

 3. Fold the rule check into the simplifier. It seems like this folds
    what is currently quite simple code into the already rather complex
    simplifier.

I'm not entirely sure which of these is the least-evil option. Thoughts?

Cheers,

- Ben


P.S. There is also the matter of cyclic module imports. To address these
     I've split up `SimplUtils.hs` into `SimplCont.hs` and
     `SimplInline.hs`. Given these two have no cross-dependencies this
     seems like a reasonable split even independent of the `RuleFun`
     rework.

     `Rules.hs` can then import `SimplCont.hs` (although it
     needs an hs-boot file to satisfy references in `LoadIface.hs`,
     `HscTypes.hs`, `MkId.hs`). I'll probably reevaluate the need for
     hs-boot files later.

     If anyone sees a better restructuring let me know.



[1] https://ghc.haskell.org/trac/ghc/ticket/9661#comment:12
[2] https://github.com/ghc/ghc/compare/ghc-7.10...bgamari:wip/rule-context
[3] https://github.com/ghc/ghc/commit/a978a4766ebf692820c3b491522b2dd6c642005f
[4] https://github.com/bgamari/ghc/blob/c71fb84b8c9ec9c1e279df8c75ceb8a537801aa1/compiler/specialise/Rules.hs#L1125
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150301/151f6405/attachment.sig>