1. 04 Oct, 2006 3 commits
    • simonpj@microsoft.com's avatar
      Improve pretty printing slightly · 1f315eba
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Second bite at the rules-only idea · a35f75aa
      simonpj@microsoft.com authored
      This is part 2 of the patch that improved the interaction of RULES and
      recursion.  It's vital that all Ids that may be referred to from later in
      the module are marked 'IAmALoopBreaker' because otherwise we may do
      postInlineUnconditionally, and lose the binding altogether. 
      So I've added a boolean rules-only flag to IAmALoopBreaker.  Now we can
      do inlining for rules-only loop-breakers. 
    • simonpj@microsoft.com's avatar
      Eliminate case-of-cast · 0477b389
      simonpj@microsoft.com authored
      Note [Case of cast]
      Consider 	case (v `cast` co) of x { I# ->
      		... (case (v `cast` co) of {...}) ...
      We'd like to eliminate the inner case.  We can get this neatly by 
      arranging that inside the outer case we add the unfolding
      	v |-> x `cast` (sym co)
      to v.  Then we should inline v at the inner case, cancel the casts, 
      and away we go
      This patch does the job, fixing a performance hole reported by Roman.
  2. 03 Oct, 2006 6 commits
    • Ian Lynagh's avatar
      Fixes for the porting process for 6.6 · 08f6d461
      Ian Lynagh authored
    • simonpj@microsoft.com's avatar
      Make recursion and RULES interact better · c248518f
      simonpj@microsoft.com authored
      See Trac #683
      This patch improves the interaction of recursion and RULES; at least I
      hope it does.   The problem was that a RULE was being treated uniformly like
      an "extra RHS". This worked badly when you have a non-recursive definition
      that is made recursive only by RULE.
      This patch maeks the occurrence analyser know whether a binder is referred to
      only from RULES (the RulesOnly constructor in OccInfo).  Then we can ignore
      such edges when deciding on the order of bindings in a letrec, and when
      setting the LoopBreaker flag.
      The remaining potential problem is this:
      	rec{ f = ...g...
      	   ; g = ...f...
      	     RULE g True = ...
      The RULE for g may not be visible in f's rhs.  This is fixable, but not
    • simonpj@microsoft.com's avatar
      Warning police only · f297deab
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Fix scoped type variables for expression type signatures · 9da46390
      simonpj@microsoft.com authored
      I had forgotten to bring scoped type variables into scope at an expression
      type signature, such as
      	e :: forall s. <type>
      where 's' should scope over the expression e.
      Like everything to do with scoped type variables, fixing this took an 
      unreasonable amount of work.  I'm sure there must be a better way to 
      achitect this!
      I updated the user manual too.
      A test is tc213.
      It would be good to push this into 6.6.1
    • simonpj@microsoft.com's avatar
      Trim imports · 1bf36305
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Add error check for operators in types · 7fbb69b2
      simonpj@microsoft.com authored
      Fixes Trac #919
  3. 27 Jul, 2006 1 commit
  4. 01 Oct, 2006 1 commit
  5. 29 Sep, 2006 15 commits
  6. 28 Sep, 2006 6 commits
  7. 14 Sep, 2006 1 commit
  8. 15 Sep, 2006 1 commit
  9. 17 Sep, 2006 1 commit
    • rjmccall@gmail.com's avatar
      Modify toArgs to parse quotes/escapes like /bin/sh · 3d9f1290
      rjmccall@gmail.com authored
      Addresses ticket #197, which asks for escape sequences to be supported directly (i.e.
      not only in dquoted strings) on :load commands in GHCI.  Fix modifies the toArgs
      function to parse its input like /bin/sh does, i.e. recognizing escapes anywhere
      and treating quoted strings as atomic chunks.  Thus:
        :load a\ b c\"d e" "f
      would parse with three arguments, namely 'a b', 'c"d', and 'e f'.
      toArgs is used to parse arguments for both :load and :main, but doesn't appear to
      be used elsewhere.  I see no harm in modifying both to be consistent -- in fact,
      the functionality is probably more useful for :main than for :load.
  10. 28 Sep, 2006 1 commit
  11. 27 Sep, 2006 1 commit
  12. 02 Sep, 2006 1 commit
  13. 06 Sep, 2006 1 commit
  14. 27 Sep, 2006 1 commit