Hi,
I think creating your rules as built-in rules is a good way to go.
You could reduce the complexity somewhat by generating all n*m rules as
“normal” rules in the plugin when you see the instancs. This way, the
plugin does not have to do anything when you want the rule to actually
file (…and
Thanks for the suggestion, Joachim.
Since I'm writing a core-to-core plugin anyway, it wasn't so hard for me to
implement all of these n*m rules (for n operations and m instances) at once
via a "built-in" rewrite rule that explicitly manipulates Core expressions.
Doing so is probably also
Hi,
Now that I think about it: You can probably even generate these rules
in a core2core pass that looks for instances of C, and then adds the
rules to the mod_guts. That would solve the problem neatly, I’d say.
Greetings,
Joachim
Am Dienstag, den 03.10.2017, 08:45 -0700 schrieb Conal Elliott:
Hi Joachim. Thanks very much for the suggestions and the `-ddump-rules`
view. I wouldn't want to make people write `morph` rules for all
combinations of operations (like `(.)`) and categories, but perhaps as you
suggest those rules can be generated automatically.
Regards, - Conal
On Tue, Oct 3,
Hi,
Am Montag, den 02.10.2017, 17:03 -0700 schrieb Conal Elliott:
> My questions:
>
> * Is it feasible for GHC to combine the constraints needed LHS and RHS to
> form an applicability condition?
> * Is there any way I can make the needed constraints explicit in my rewrite
> rules?
> *
-users@haskell.org
Subject: Re: GHC rewrite rule type-checking failure
Thanks very much for the reply, Joachim.
Oops! I flubbed the example. I really `morph` to distribute over an application
of `comp`. New code below (and attached). You're right that I wouldn't want to
restrict the type of `morph`,
I believe the answer is currently no. As I understand it, the entire
instance resolution mechanism drops away after type checking and is
therefore not available to the simplifier. So if you need to add a
constraint on the RHS of a rule, I think you're mostly out of luck. The
only thing I can think
Thanks very much for the reply, Joachim.
Oops! I flubbed the example. I really `morph` to distribute over an
application of `comp`. New code below (and attached). You're right that I
wouldn't want to restrict the type of `morph`, since each `morph` *rule*
imposes its own restrictions.
My
Hi Conal,
The difference is that the LHS of the first rule is mentions the `C k`
constraint (probably unintentionally):
*RuleFail> :t morph comp
morph comp :: C k => k1 (k b c) (k a b -> k a c)
but the LHS of the second rule side does not:
*RuleFail> :t morph addC
morph addC :: Num b => k (b,
