[GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples

[GHC]

#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