On Fri, Dec 8, 2017 at 9:18 AM, Neil Mayhew < neil_mayhew@users.sourceforge.net> wrote:
Good point. Having great optimization isn’t a justification for complete mental laziness on the part of the programmer! However, I did find the behaviour in this case surprising and unintuitive, given ghc’s usual ability to optimize things, and having it change on me when I enabled profiling left me wondering where to go next. The code I presented here is considerably simplified from the original program, and represents a lot of work already expended trying to get to the root of the problem.
This is actually why I (and likely SPJ) am inclined to consider it a bug; while it might be arguable as Sven does, the counterintuitive effect when you turn on profiling suggests that it's not intended or expected. (Although maybe it should be; the intuition is "profiling disables optimization" but what it really does is a bit more subtle than that overly simplistic notion.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net