RULES and strictness

[Kirsten Chevalier]

>
> when performing strictness/abscence/one-shot analysis, are rule bodies
> taken into account?

No.

> like, would the following cause trouble making const
> no longer absent in its second argument?
>
> const x y = x
>
> {-# RULE "const/seq" forall a b . const a b = seq b a #-}
>
> by trouble I mean the compiler failing or producing bad code in some
> way, rather than the obvious trouble of changing the meaning of const.
>

No, because of the worker/wrapper transform. You can think of
strictness analysis as doing something like this in this case:

const x y = x
=>

const x y = constW x

constW x = let y = error "entered absent argument!" in x

(of course, strictness analysis only does the work of determining that
const is absent in its second argument, and the worker/wrapper
transform phase is a separate pass that happens later.)

So, from then on, GHC will inline const wherever possible, and the
rule "const/seq" will no longer be applicable, because it applies to
const, not constW. Note that even if const doesn't end up getting
inlined for some reason, the presence of the rule doesn't cause any
problems. It's perfectly valid to replace (const a b) with (constW a)
or with (seq b a).

> it is noted in the deforestation papers that rules can change the
> sharing properties of code and we are okay with that. I was wondering if
> they could safely change the strictness or abscence properties of code
> as well?
>

Given the example above, I think it's fairly safe to say that rules
can safely change strictness and absence properties, or at least
"safe" in the sense that it shouldn't cause the compiler to crash or
to generate code that crashes. (Since even GHC's strictness analysis
on its own, ignoring the presence of rules, hasn't been formally
proven correct yet, I'm being rather hand-wavy in saying that.) But,
it is kind of weird to have a rule that changes these properties. I
realize the example you gave is just for the sake of argument, but I
can't think of a real situation where you'd want to have a rule that
changed strictness properties (rather than expressing the strictness
you wanted in the code), though I'm open to being convinced otherwise.

Cheers,
Kirsten

-- 
Kirsten Chevalier* chevalier at alum.wellesley.edu *Often in error, never in doubt
"I flip on the television and watch sad movies / And look for sad sick people
like me" -- Tegan and Sara