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 > <[email protected]> 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 > > [email protected] > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > ghc-devs mailing list > > [email protected] > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- Joachim Breitner [email protected] http://www.joachim-breitner.de/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
