Allowing rules to depend upon SimplCont
ben at smart-cactus.org
Sun Mar 1 21:35:47 UTC 2015
In Bug #9661, Comment #12 Simon Peyton-Jones wrote ,
> 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 . The core
of the change (as I understand it) is to add a `SimplCont` argument to
`RuleFun`  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
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
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
I'm not entirely sure which of these is the least-evil option. Thoughts?
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`
`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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 472 bytes
Desc: not available
More information about the ghc-devs