1. 03 Jun, 2009 2 commits
    • Simon Marlow's avatar
      fix logic for BUID_DOCBOOK_HTML · f4ec2d0c
      Simon Marlow authored
    • simonpj@microsoft.com's avatar
      Allow RULES for seq, and exploit them · 90ce88a0
      simonpj@microsoft.com authored
      Roman found situations where he had
            case (f n) of _ -> e
      where he knew that f (which was strict in n) would terminate if n did.
      Notice that the result of (f n) is discarded. So it makes sense to
      transform to
            case n of _ -> e
      Rather than attempt some general analysis to support this, I've added
      enough support that you can do this using a rewrite rule:
        RULE "f/seq" forall n.  seq (f n) e = seq n e
      You write that rule.  When GHC sees a case expression that discards
      its result, it mentally transforms it to a call to 'seq' and looks for
      a RULE.  (This is done in Simplify.rebuildCase.)  As usual, the
      correctness of the rule is up to you.
      This patch implements the extra stuff.  I have not documented it explicitly
      in the user manual yet... let's see how useful it is first.
      The patch looks bigger than it is, because
        a) Comments; see esp MkId Note [seqId magic]
        b) Some refactoring.  Notably, I moved the special desugaring for
           seq from MkCore back into DsUtils where it properly belongs.
           (It's really a desugaring thing, not a CoreSyn invariant.)
        c) Annoyingly, in a RULE left-hand side we need to be careful that
           the magical desugaring done in MkId Note [seqId magic] item (c) 
           is *not* done on the LHS of a rule. Or rather, we arrange to 
           un-do it, in DsBinds.decomposeRuleLhs.
  2. 02 Jun, 2009 11 commits
  3. 29 May, 2009 2 commits
  4. 30 May, 2009 5 commits
  5. 23 May, 2009 1 commit
  6. 29 May, 2009 7 commits
    • Ian Lynagh's avatar
    • Ian Lynagh's avatar
      Tweak mk/sub-makefile.mk · c40387ed
      Ian Lynagh authored
    • simonpj@microsoft.com's avatar
      Implement -XMonoLocalBinds: a radical new flag · 903831d5
      simonpj@microsoft.com authored
      The new flag -XMonoLocalBinds tells GHC not to generalise nested
      bindings in let or where clauses, unless there is a type signature,
      in which case we use it.  
      I'm thinking about whether this might actually be a good direction for
      Haskell go to in, although it seems pretty radical.  Anyway, the flag
      is easy to implement (look at how few lines change), and having it
      will allow us to experiement with and without.
      Just for the record, below are the changes required in the boot 
      libraries -- ie the places where.  Not quite as minimal as I'd hoped,
      but the changes fall into a few standard patterns, and most represent
      (in my opinion) sytlistic improvements.  I will not push these patches,
      == running darcs what -s --repodir libraries/base
      M ./Control/Arrow.hs -2 +4
      M ./Data/Data.hs -7 +22
      M ./System/IO/Error.hs +1
      M ./Text/ParserCombinators/ReadP.hs +1
      == running darcs what -s --repodir libraries/bytestring
      M ./Data/ByteString/Char8.hs -1 +2
      M ./Data/ByteString/Unsafe.hs +1
      == running darcs what -s --repodir libraries/Cabal
      M ./Distribution/PackageDescription.hs -2 +6
      M ./Distribution/PackageDescription/Check.hs +3
      M ./Distribution/PackageDescription/Configuration.hs -1 +3
      M ./Distribution/ParseUtils.hs -2 +4
      M ./Distribution/Simple/Command.hs -1 +4
      M ./Distribution/Simple/Setup.hs -12 +24
      M ./Distribution/Simple/UserHooks.hs -1 +5
      == running darcs what -s --repodir libraries/containers
      M ./Data/IntMap.hs -2 +2
      == running darcs what -s --repodir libraries/dph
      M ./dph-base/Data/Array/Parallel/Arr/BBArr.hs -1 +3
      M ./dph-base/Data/Array/Parallel/Arr/BUArr.hs -2 +4
      M ./dph-prim-par/Data/Array/Parallel/Unlifted/Distributed/Arrays.hs -6 +10
      M ./dph-prim-par/Data/Array/Parallel/Unlifted/Distributed/Combinators.hs -3 +6
      M ./dph-prim-seq/Data/Array/Parallel/Unlifted/Sequential/Flat/Permute.hs -2 +4
      == running darcs what -s --repodir libraries/syb
      M ./Data/Generics/Twins.hs -5 +18
    • Simon Marlow's avatar
    • Simon Marlow's avatar
    • simonpj@microsoft.com's avatar
      Make haddocking depend on the library .a file · dc249f10
      simonpj@microsoft.com authored
      You can't Haddock a library until it's built. Previously that happened
      automatically because
        Haddock itself was built with stage2
        And all the libraries were built with stage1
      But now DPH is built with stage2, so Haddock can get to work too
      This patch adds the missing dependency (thanks to Simon M)
    • simonpj@microsoft.com's avatar
      Fix Trac #3259: expose 'lazy' only after generating interface files · 0abcc755
      simonpj@microsoft.com authored
      This patch fixes an insidious and long-standing bug in the way that
      parallelism is handled in GHC.  See Note [lazyId magic] in MkId.
      Here's the diagnosis, copied from the Trac ticket.  par is defined 
      in GHC.Conc thus:
          {-# INLINE par  #-}
          par :: a -> b -> b
          par  x y = case (par# x) of { _ -> lazy y }
          -- The reason for the strange "lazy" call is that it fools the
          -- compiler into thinking that pseq and par are non-strict in
          -- their second argument (even if it inlines pseq/par at the call
          -- site).  If it thinks par is strict in "y", then it often
          -- evaluates "y" before "x", which is totally wrong.
      The function lazy is the identity function, but it is inlined only
      after strictness analysis, and (via some magic) pretends to be
      lazy. Hence par pretends to be lazy too.
      The trouble is that both par and lazy are inlined into your definition
      of parallelise, so that the unfolding for parallelise (exposed in
      Parallelise.hi) does not use lazy at all. Then when compiling Main,
      parallelise is in turn inlined (before strictness analysis), and so
      the strictness analyser sees too much.
      This was all sloppy thinking on my part. Inlining lazy after
      strictness analysis works fine for the current module, but not for
      importing modules.
      The fix implemented by this patch is to inline 'lazy' in CorePrep,
      not in WorkWrap. That way interface files never see the inlined version.
      The downside is that a little less optimisation may happen on programs
      that use 'lazy'.  And you'll only see this in the results -ddump-prep
      not in -ddump-simpl.  So KEEP AN EYE OUT (Simon and Satnam especially).
      Still, it should work properly now.  Certainly fixes #3259.
  7. 28 May, 2009 12 commits