How lose can we be with strictness

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/

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
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
-- Chris Allen Currently working on http://haskellbook.com

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/

| And I am wondering if there is a way for GHC to discriminate between
| these two options somehow…
Not that I know of.
Simon
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Joachim
| Breitner
| Sent: 20 May 2017 18:14
| To: ghc-devs@haskell.org
| Subject: 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
| >

Sent from my iPad
On May 20, 2017, at 1:13 PM, Joachim Breitner
wrote: 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…
Well, deeply force until it runs into a Float that happens to be a NaN. ;)
participants (4)
-
Christopher Allen
-
Edward Kmett
-
Joachim Breitner
-
Simon Peyton Jones