[GHC] #5129: "evaluate" optimized away

Don Stewart dons00 at gmail.com
Wed May 4 05:49:20 CEST 2011


That's a very common idiom. Interestingly, we have:

-- | Strict (call-by-value) application, defined in terms of 'seq'.
($!)    :: (a -> b) -> a -> b
#ifdef __GLASGOW_HASKELL__
f $! x  = let !vx = x in f vx  -- see #2273
#elif !defined(__HUGS__)
f $! x  = x `seq` f x


On Tue, May 3, 2011 at 5:13 PM, GHC <cvs-ghc at haskell.org> wrote:
> #5129: "evaluate" optimized away
> ---------------------------------+------------------------------------------
>    Reporter:  dons              |        Owner:  simonmar
>        Type:  bug               |       Status:  new
>    Priority:  normal            |    Milestone:
>   Component:  Compiler          |      Version:  7.0.3
>    Keywords:  seq, evaluate     |     Testcase:
>   Blockedby:                    |   Difficulty:
>          Os:  Unknown/Multiple  |     Blocking:
> Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
> ---------------------------------+------------------------------------------
>
> Comment(by ezyang):
>
>  One rather user-visible result of this ticket is that we should now
>  discourage the use of the idiom
>
>  {{{
>  x `seq` return ()
>  }}}
>
>  I can see a few instances of this in `base`
>
>  {{{
>  ezyang at javelin:~/Dev/ghc-master/libraries/base$ grep -R '`seq` return ()'
>  .
>  ./Foreign/C/String.hs:        go [] n     = n `seq` return () -- make it
>  strict in n
>  ./Foreign/C/String.hs:        go [] n     = n `seq` return () -- make it
>  strict in n
>  ./GHC/IO/Handle/Text.hs:    c `seq` return ()
>  ./GHC/Conc/Windows.hs:  r `seq` return () -- avoid space leak
>  }}}
>
>  and there are probably more elsewhere.
>
> --
> Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5129#comment:6>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
>
> _______________________________________________
> Glasgow-haskell-bugs mailing list
> Glasgow-haskell-bugs at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
>



More information about the Glasgow-haskell-bugs mailing list