[GHC] #12620: Allow the user to prevent floating and CSE

[GHC]

#12620: Allow the user to prevent floating and CSE
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #9520, #8457      |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 I'm beginning to get glimmers of understanding about this no-update thing.
 Consider
 {{{
   t1 = [1..n]
 vs
   t2 = \_ -> [1..n]
 vs
   t3 = let x = [1..n] in \_ -> x
 }}}
 Note that

 * If we use `t1` in a shared context like `sum t1 / length t1`, we'll end
 up materialising the whole list.
 * For `t2`, we'd get `sum (t2 ()) / length (t2 ())`, and now the list is
 computed twice rather than duplicated.  Note that `t1` and `t2` have
 different types of course.
 * Then `t3` is the result of applying the full laziness transformation to
 `t2`, and its space behaviour is back to that of `t1`.

 Reflections:

 * I think that this "noupdate" pragma is intended to achieve an effect
 like `t2`, but more conveniently, without changing types.  Correct?

 * I think (but am not sure) that you intend to use this only for one-shot
 thunks, where (unlike the sum/count example) the thunk is evaluated only
 once.   In which case it would often be discarded after being evaluated,
 in which case where does the leak come from.  A small, concrete example
 would be jolly useful.

 * Notice how important it is that in `t2` the lambda ''syntactically
 encloses'' the leaky computation.  Otherwise you get `t3`.  My conclusion
 from this is that if you want a pragma on a data constructor, that the
 pragma only guarantees to affect the syntactic argument.  Thus
 {{{
   let x = <expression> in Yield o x
 vs
   Yield o <expression>
 }}}
 The latter would "work" (i.e. `<expression>` would be wrapped in a non-
 updatable thunk); but the former might not.

 I say "might not" rather "would not" because cardinality analysis might
 propagate the one-shot info to `x`.  But that would be a "best-efforts"
 thing on which one might not like to rely.

 Would syntactic enclosure be enough in your application?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12620#comment:19>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler