1. 08 May, 2006 5 commits
    • simonpj@microsoft.com's avatar
      Do not put wired-in things in interface files · ef61cbbc
      simonpj@microsoft.com authored
      There is no need for wired-in things to go into interface files; the compiler
      knows about them anyway.  Worse, it turns ou that if they are in an interface
      file, they may get read in with not-quite-right type info (e.g. GHC.Err.error),
      and the not-quite-right thing gets into the type envt.  Than it gets used 
      instead of the wired in thing.
      Best all round never to put them into interface files.  This is the way
      it used to be, but it looks as if it rotted away some time ago.
      (I noticed this when fixing unsafePerformIO stuff, becuase 'lazy' was getting
      an unfolding when it shouldn't.)
    • simonpj@microsoft.com's avatar
      Remove NOINLINE strictness hack · 302265d5
      simonpj@microsoft.com authored
      The stricteness analyser used to have a HACK which ensured that NOINLNE things
      were not strictness-analysed.  The reason was unsafePerformIO. Left to itself,
      the strictness analyser would discover this strictness for unsafePerformIO:
      	unsafePerformIO:  C(U(AV))
      But then consider this sub-expression
      	unsafePerformIO (\s -> let r = f x in 
      			       case writeIORef v r s of (# s1, _ #) ->
      			       (# s1, r #)
      The strictness analyser will now find that r is sure to be eval'd,
      and may then hoist it out.  This makes tests/lib/should_run/memo002
      Solving this by making all NOINLINE things have no strictness info is overkill.
      In particular, it's overkill for runST, which is perfectly respectable.
      	f x = runST (return x)
      This should be strict in x.
      So the new plan is to define unsafePerformIO using the 'lazy' combinator:
      	unsafePerformIO (IO m) = lazy (case m realWorld# of (# _, r #) -> r)
      Remember, 'lazy' is a wired-in identity-function Id, of type a->a, which is 
      magically NON-STRICT, and is inlined after strictness analysis.  So
      unsafePerformIO will look non-strict, and that's what we want.
      Now we don't need the hack in the strictness analyser.
    • simonpj@microsoft.com's avatar
      Trim imports · 36b27193
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Trim imports · bbf41467
      simonpj@microsoft.com authored
    • Simon Marlow's avatar
      GHC_MANGLER-->MANGLER · 02de51da
      Simon Marlow authored
  2. 05 May, 2006 1 commit
  3. 02 May, 2006 1 commit
  4. 05 May, 2006 9 commits
  5. 04 May, 2006 8 commits
  6. 03 May, 2006 2 commits
  7. 26 Apr, 2006 1 commit
  8. 02 May, 2006 5 commits
  9. 01 May, 2006 1 commit
  10. 26 Apr, 2006 1 commit
  11. 28 Apr, 2006 2 commits
  12. 27 Apr, 2006 1 commit
  13. 26 Apr, 2006 1 commit
  14. 25 Apr, 2006 2 commits