1. 16 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      A bottoming function should have infinite arity · decb48fc
      simonpj@microsoft.com authored
      I can't think how this one escaped for so long, but
      	(error "foo") 
      should have arityType ABot, just as 'error' itself does.
      This improves eta expansion.  I spotted it when looking at the function
      in the ndp package.
  2. 10 Jan, 2008 2 commits
  3. 31 Dec, 2007 1 commit
  4. 15 Jan, 2008 1 commit
  5. 14 Jan, 2008 2 commits
  6. 15 Jan, 2008 2 commits
  7. 14 Jan, 2008 1 commit
  8. 13 Jan, 2008 12 commits
  9. 12 Jan, 2008 7 commits
  10. 10 Jan, 2008 1 commit
  11. 09 Jan, 2008 1 commit
  12. 10 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Fix 2030: make -XScopedTypeVariables imply -XRelaxedPolyRec · 493fd9df
      simonpj@microsoft.com authored
      The type checker doesn't support lexically scoped type variables 
      unless we are using the RelaxedPolyRec option.  Reasons: see
      Note [Scoped tyvars] in TcBinds.
      So I've changed DynFlags to add this implication, improved the 
      documentation, and simplified the code in TcBinds somewhat.
      (It's longer but only because of comments!)
  13. 09 Jan, 2008 4 commits
  14. 07 Jan, 2008 4 commits
    • simonpj@microsoft.com's avatar
      Fix Trac #2018: float-out was ignoring the kind of a coercion variable · e2cf518a
      simonpj@microsoft.com authored
      The float-out transformation must handle the case where a coercion
      variable is free, which in turn mentions type variables in its kind.
      Just like a term variable really.
      I did a bit of refactoring at the same time.
      Test is tc241
      MERGE to stable branch
    • simonpj@microsoft.com's avatar
      Make the treatment of equalities more uniform · 3787d987
      simonpj@microsoft.com authored
      This patch (which is part of the fix for Trac #2018) makes coercion variables
      be handled more uniformly.  Generally, they are treated like dictionaries
      in the type checker, not like type variables, but in a couple of places we
      were treating them like type variables.  Also when zonking we should use
      zonkDictBndr not zonkIdBndr.
    • simonpj@microsoft.com's avatar
      Fix Trac #2017 · 5f99dc3d
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Add -XImpredicativeTypes, and tighten up type-validity checking (cf Trac 2019) · 5e04ae34
      simonpj@microsoft.com authored
      Somehow we didn't have a separate flag for impredicativity; now we do.
      Furthermore, Trac #2019 showed up a missing test for monotypes in data
      constructor return types.  And I realised that we were even allowing
      things like
      	Num (forall a. a) => ...
      which we definitely should not.  
      This patch insists on monotypes in several places where we were (wrongly)
      too liberal before.
      Could be merged to 6.8 but no big deal.