1. 21 Nov, 2007 2 commits
    • rl@cse.unsw.edu.au's avatar
      Vectorise polyexprs with notes · 77281075
      rl@cse.unsw.edu.au authored
    • simonpj@microsoft.com's avatar
      Make rebindable do-notation behave as advertised · 1d1c3c72
      simonpj@microsoft.com authored
      Adopt Trac #1537.  The patch ended up a bit bigger than I expected,
      so I suggest we do not merge this into the 6.8 branch.  But there
      is no funadamental reason why not.
      With this patch, rebindable do-notation really does type as if you
      had written the original (>>) and (>>=) operations in desguared form.
      I ended up refactoring some of the (rather complicated) error-context
      stuff in TcUnify, by pushing an InstOrigin into tcSubExp and its
      various calls. That means we could get rid of tcFunResTy, and the
      SubCtxt type.  This should improve error messages slightly
      in complicated situations, because we have an Origin to hand
      to instCall (in the (isSigmaTy actual_ty) case of tc_sub1).
      Thanks to Pepe for the first draft of the patch.
  2. 16 Nov, 2007 1 commit
  3. 05 Nov, 2007 1 commit
  4. 21 Nov, 2007 1 commit
  5. 20 Nov, 2007 5 commits
    • simonpj@microsoft.com's avatar
    • Simon Marlow's avatar
      Move file locking into the RTS, fixing #629, #1109 · 1d026619
      Simon Marlow authored
      File locking (of the Haskell 98 variety) was previously done using a
      static table with linear search, which had two problems: the array had
      a fixed size and was sometimes too small (#1109), and performance of
      lockFile/unlockFile was suboptimal due to the linear search.
      Also the algorithm failed to count readers as required by Haskell 98
      Now it's done using a hash table (provided by the RTS).  Furthermore I
      avoided the extra fstat() for every open file by passing the dev_t and
      ino_t into lockFile.  This and the improvements to the locking
      algorithm result in a healthy 20% or so performance increase for
      opening/closing files (see openFile008 test).
    • simonpj@microsoft.com's avatar
      FIX Trac #1825: standalone deriving Typeable · f22f248b
      simonpj@microsoft.com authored
      Standalone deriving of typeable now requires you to say
      	instance Typeable1 Maybe
      which is exactly the shape of instance decl that is generated
      by a 'deriving( Typeable )' clause on the data type decl.
      This is a bit horrid, but it's the only consistent way, at least
      for now.  If you say something else, the error messages are helpful.
      MERGE to 6.8 branch
    • simonpj@microsoft.com's avatar
      FIX #1715: egregious bug in ifaceDeclSubBndrs · d5659c2d
      simonpj@microsoft.com authored
      ifaceDeclSubBndrs didn't have an IfaceSyn case; but with type
      families an IfaceSyn can introduce subordinate binders.  Result:
      The fix is easy though.  Merge to 6.8 branch.
    • Simon Marlow's avatar
      Always do 'setup makefile' before building each library · 5ca2e94e
      Simon Marlow authored
      This forces preprocessing to happen, which is necessary if any of the
      .hsc files have been modified.  Without this change, a 'setup
      makefile' would be required by hand after a .hsc file changed.
      Fortunately 'setup makefile' isn't much extra work, and I've made it
      not overwrite GNUmakefile if it hasn't changed, which avoids
      recalculating the dependencies each time.
  6. 08 Nov, 2007 1 commit
  7. 20 Nov, 2007 2 commits
  8. 19 Nov, 2007 4 commits
  9. 18 Nov, 2007 8 commits
  10. 17 Nov, 2007 5 commits
  11. 16 Nov, 2007 5 commits
  12. 19 Nov, 2007 3 commits
  13. 17 Nov, 2007 1 commit
  14. 16 Nov, 2007 1 commit
    • Simon Marlow's avatar
      Attempt at fixing #1873, #1360 · 037aa382
      Simon Marlow authored
      I think I figured out a reasonable way to manage the GHCi context,
      comments welcome.
      Rule 1: external package modules in the context are persistent.  That
      is, when you say 'import Data.Maybe' it survives over :load, :add,
      :reload and :cd.
      Rule 2: :load and :add remove all home-package modules from the
      context and add the rightmost target, as a *-module if possible.  This
      is as before, and makes sense for :load because we're starting a new
      program; the old home-package modules don't make sense any more.  For
      :add, it usually does what you want, because the new target will
      become the context.
      Rule 3: any modules from the context that fail to load during a
      :reload are remembered, and re-added to the context at the next
      successful :reload.
      Claus' suggestion about adding the "remembered" modules to the prompt
      prefixed with a ! is implemented but commented out.  I couldn't
      decide whether it was useful or confusing.
      One difference that people might notice is that after a :reload where
      there were errors, GHCi would previously dump you in the most recent
      module that it loaded.  Now it dumps you in whatever subset of the
      current context still makes sense, and in the common case that will
      probably be {Prelude}.