Re: How lose can we be with strictness

Hi, yes, of course. What GHC is doing now is correct, safe and what an (exprienced) programmer expects. Especially if he is using `x==x` to deeply force x… But then I presume that there are many uses of code like this where the effect of `==` forcing its arguments is a necessary side effect of deciding the equality, and if the compiler finds a different way of deciding the equality, e.g. statically, the programmer would be happy to have `n` as dead code, with all the advantages this provides. And I am wondering if there is a way for GHC to discriminate between these two options somehow… Joachim Am Samstag, den 20.05.2017, 12:07 -0500 schrieb Christopher Allen:

Correct me if I'm wrong here, but it's preserving the effect of (==) forcing its arguments. This makes the optimization less surprising, in my opinion.

Is there a benefit to not doing this?

On Sat, May 20, 2017 at 11:56 AM, Joachim Breitner wrote:

...

Hi,

I just observed that GHC optimizes

fun (n::Int) = n == 0 + n

to essentially

fun (n::Int) = n `seq` True

I am wondering under what circumstances we would be happy to transform this further to

fun _ = True

Clearly, we do not want to drop `seq`s in general. But is there some commonly accepted rule about which strictness we generally allow the compiler to get rid of, if it turns out that the compiler can do without? Or are all such transformations out of bounds for GHC?

Greetings, Joachim

-- Joachim Breitner   mail@joachim-breitner.de   http://www.joachim-breitner.de/

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/