#9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: simplCore/should_run/T9390 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Basically yes. Some additional thoughts: * "...To quote the docs for pseq" This seems like a complete non-sequitur when talking about `seq`, and in any case only documents `seq` in a sideways kind of way. Better to quote the (brand new) documentation for `seq`. (Add a note to say it's new if you like.) * "...If we want to be certain of the ordering, use pseq". That's the place to quote pseq's documentation. * "You might think (as I did) that we can get the same guaranteed ordering of evaluation by having a function which is only strict in one of its arguments:" This is a bit confusing, because we don't know if `(+)` here is overloaded. I assume you mean `(+)` at `Int`? If so, it's strict in both arguments, so adding the strictness annotation doesn't change anything anyway. A `!` would only have a chance of changing evaluation order if the function was lazy. And if it was lazy then the `!` would make it strict, and that ''would'' be preserved by inlining. So maybe my earlier comment about inlining was a red herring. * I think it might be helpful to articulate the baseline story for `unsafePerformIO`, namely: use it only when you don't mind which order the effects are performed in, relative to both the main I/O monad and other calls to `unsafePerformIO`. You are on thin ice if you go beyond that; and the thin ice is what this tutorial discusses. * "to understand why unsafeInterleaveIO is semantically different from return . unsafePerformIO, we need to drop down a layer of abstraction". Not really. To understand ''how'', you need to drop down. But the guarantees are perfectly well defined. Given `do { ...before...; x <- unsafeInterleaveIO (...side...); ...after...}` then: * Effects in `...side...` will happen after effects in `...before...`. * But effects in `...side...` maybe occur arbitrarily interleaved with effects in `...after...`. * I am not sure what the `lazy` in `unsafeDupablePeformIO` is either! Maybe Simon Marlow does? I think it's good enough to launch on the masses though. Thanks for doing this. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9390#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler