1. 06 Jan, 2011 6 commits
  2. 05 Jan, 2011 1 commit
  3. 05 Nov, 2010 1 commit
    • vivian's avatar
      multiline commands in GHCi #4316 · 4edbeb14
      vivian authored
      This patch adds support for multiline commands in GHCi.
      
      The first line of input is lexed.  If there is an active
      layout context once the lexer reaches the end of file, the
      user is prompted for more input.
      
      Multiline input is exited by an empty line and can be escaped 
      with a user interrupt.
      
      Multiline mode is toggled with `:set +m`
      4edbeb14
  4. 05 Jan, 2011 2 commits
  5. 19 Dec, 2010 1 commit
  6. 04 Jan, 2011 1 commit
    • Ian Lynagh's avatar
      Define cTargetArch and start to use it rather than ifdefs · f0e3d790
      Ian Lynagh authored
      Using Haskell conditionals means the compiler sees all the code, so
      there should be less rot of code specific to uncommon arches. Code
      for other platforms should still be optimised away, although if we want
      to support targetting other arches then we'll need to compile it
      for-real anyway.
      f0e3d790
  7. 19 Dec, 2010 1 commit
  8. 04 Jan, 2011 1 commit
  9. 21 Dec, 2010 1 commit
    • gwright@antiope.com's avatar
      Fix #4829 (build does not respect --with-gcc option) · 834a2186
      gwright@antiope.com authored
      This patch fixes what seems to be the last problem with the --with-gcc
      option.  On OS X, we need to pass the path to gcc to dtrace as the
      preprocessor.  (Internally, dtrace on OS X sets the default preprocessor
      to /usr/bin/gcc.)  ATM, dtrace is only supported on OS X, so we don't
      need any conditionalization.  If dtrace is ported to other platforms,
      we might need to change this. However, usage on other platforms will
      probably be similar to OS X, since many of Apple's changes are to
      use the gnu toolchain instead of the Sun toolchain.
        
      834a2186
  10. 31 Dec, 2010 1 commit
  11. 20 Dec, 2010 1 commit
  12. 24 Dec, 2010 2 commits
  13. 22 Dec, 2010 8 commits
    • simonpj@microsoft.com's avatar
      Implement fuzzy matching for the Finder · f14f1daa
      simonpj@microsoft.com authored
      ..so that you get a more helpful message when
      you mis-spell a module name in an 'import'.
      
      Validates, but not fully tested.
      
      Based on Max's patch in Trac #2442, but heavily refactored.
      f14f1daa
    • simonpj@microsoft.com's avatar
      Implement fuzzy matching for the renamer · 820ddd55
      simonpj@microsoft.com authored
      ...so that you get helpful suggestions when you mis-spell a name
      Based on Max's patch in Trac #2442, but heavily refactored.
      820ddd55
    • simonpj@microsoft.com's avatar
      Add fuzzyLookup, a variant of fuzzyMatch · b6f9d6f2
      simonpj@microsoft.com authored
      Plus, I changed quite a bit of layout to make the lines shorter.
      b6f9d6f2
    • simonpj@microsoft.com's avatar
      White space only · a677bc58
      simonpj@microsoft.com authored
      a677bc58
    • simonpj@microsoft.com's avatar
      Layout and white space only · de295725
      simonpj@microsoft.com authored
      de295725
    • simonpj@microsoft.com's avatar
      Tidy up rebindable syntax for MDo · ba05282d
      simonpj@microsoft.com authored
      For a long time an 'mdo' expression has had a SyntaxTable
      attached to it.  However, we're busy deprecating SyntaxTables
      in favour of rebindable syntax attached to individual Stmts,
      and MDoExpr was totally inconsistent with DoExpr in this
      regard.
      
      This patch tidies it all up.  Now there's no SyntaxTable on
      MDoExpr, and 'modo' is generally handled much more like 'do'.
      
      There is resulting small change in behaviour: now MonadFix is
      required only if you actually *use* recursion in mdo. This
      seems consistent with the implicit dependency analysis that
      is done for mdo.
      
      Still to do:
        * Deal with #4148 (this patch is on the way)
        * Get rid of the last remaining SyntaxTable on HsCmdTop
      ba05282d
    • simonpj@microsoft.com's avatar
      Make the occurrence analyser track preInlineUnconditionally · 16dd51fb
      simonpj@microsoft.com authored
      This fixes a somewhat obscure situation in which an
      over-optimistic use of "occurs once" led to an infinite
      sequence of simplifier iterations.  Se Note [Cascading inlines]
      for the details.
      
      This showed up when compiling rather large DPH programs, which
      run lots of iterations of the simplifier, which in turn made
      compilation take much longer than necessary.
      16dd51fb
    • simonpj@microsoft.com's avatar
      Make mkDFunUnfolding more robust · 3e0a7b9f
      simonpj@microsoft.com authored
      It now uses tcSplitDFunTy, which is designed for the purpose and
      allows arbitrary argument types to the dfun, rather than
      tcSplitSigmaTy.  This generality is used in DPH, which has
      internally-generated dfuns with impliciation-typed arguments.
      
      To do this I had to make tcSplitDFunTy return the number of
      arguments, so there are some minor knock-on effects in other
      modules.
      3e0a7b9f
  14. 21 Dec, 2010 5 commits
    • Simon Marlow's avatar
      Count allocations more accurately · db0c13a4
      Simon Marlow authored
      The allocation stats (+RTS -s etc.) used to count the slop at the end
      of each nursery block (except the last) as allocated space, now we
      count the allocated words accurately.  This should make allocation
      figures more predictable, too.
      
      This has the side effect of reducing the apparent allocations by a
      small amount (~1%), so remember to take this into account when looking
      at nofib results.
      db0c13a4
    • simonpj@microsoft.com's avatar
      Add a simple arity analyser · 1d7a3cf3
      simonpj@microsoft.com authored
      I've wanted to do this for ages, but never gotten around to
      it.  The main notes are in Note [Arity analysis] in SimplUtils.
      
      The motivating example for arity analysis is this:
      
        f = \x. let g = f (x+1)
                in \y. ...g...
      
      What arity does f have?  Really it should have arity 2, but a naive
      look at the RHS won't see that.  You need a fixpoint analysis which
      says it has arity "infinity" the first time round.
      
      This makes things more robust to the way in which you write code.  For
      example, see Trac #4474 which is fixed by this change.
      
      Not a huge difference, but worth while:
      
              Program           Size    Allocs   Runtime   Elapsed
      --------------------------------------------------------------------------------
                  Min          -0.4%     -2.2%    -10.0%    -10.0%
                  Max          +2.7%     +0.3%     +7.1%     +6.9%
       Geometric Mean          -0.3%     -0.2%     -2.1%     -2.2%
      
      I don't really believe the runtime numbers, because the machine was
      busy, but the bottom line is that not much changes, and what does
      change reliably (allocation and size) is in the right direction.
      1d7a3cf3
    • simonpj@microsoft.com's avatar
      62af0377
    • simonpj@microsoft.com's avatar
      Comments only · 05fecd15
      simonpj@microsoft.com authored
      05fecd15
    • simonpj@microsoft.com's avatar
      Single-method classes are implemented with a newtype · 3d16d9d8
      simonpj@microsoft.com authored
      This patch changes things so that such classes rely on the coercion
      mechanism for inlining (since the constructor is really just a cast)
      rather than on the dfun mechanism, therby removing some needless
      runtime indirections.
      3d16d9d8
  15. 01 Nov, 2010 1 commit
  16. 21 Dec, 2010 5 commits
  17. 16 Dec, 2010 1 commit
  18. 20 Dec, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Small improvement to CorePrep · c391db23
      simonpj@microsoft.com authored
      This change avoids unnecessary bindings. Example
      
           foo (let fn = \x.blah in
                in fn)
      
      We were generating something stupid like
      
          let fn = \x.blah in
          let fn' = \eta. fn eta
          in foo fn
      
      Now we don't.  The change is quite small.
      
      Thanks to Ben for showing me an example of this happening.
      c391db23