How lose can we be with strictness

[Simon Peyton Jones]

| 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 at haskell.org] On Behalf Of Joachim
| Breitner
| Sent: 20 May 2017 18:14
| To: ghc-devs at 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
| > <mail at joachim-breitner.de> 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 at joachim-breitner.de
| > >
| > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
| > > joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C4840
| > > 85dababa49deee5c08d49fa3a18a%7C72f988bf86f141af91ab2d7cd011db47%7C1%
| > > 7C0%7C636308972543295456&sdata=mCYy2wGpdTvnCofPEBiVsYfRggxxUd9m3SPEu
| > > fTQAJg%3D&reserved=0
| > >
| > > _______________________________________________
| > > ghc-devs mailing list
| > > ghc-devs at haskell.org
| > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail
| > > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%
| > > 7Csimonpj%40microsoft.com%7C484085dababa49deee5c08d49fa3a18a%7C72f98
| > > 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636308972543295456&sdata=XdESs
| > > wIFC2EByMcyYyhVcq40Q0SPEujNKgY8Oqv%2Ff3Q%3D&reserved=0
| > >
| >
| >
| >
| --
| Joachim Breitner
|   mail at joachim-breitner.de
| 
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
| im-
| breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C484085dababa49dee
| e5c08d49fa3a18a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636308972543
| 295456&sdata=mCYy2wGpdTvnCofPEBiVsYfRggxxUd9m3SPEufTQAJg%3D&reserved=0