1. 04 Aug, 2008 2 commits
  2. 01 Jul, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Several fixes to 'deriving' including Trac #2378 · 9319fbaf
      simonpj@microsoft.com authored
      This patch collects several related things together.
      * Refactor TcDeriv so that the InstInfo and the method bindings are renamed
        together.  This was messy before, and is cleaner now.  Fixes a bug caused 
        by interaction between the "auxiliary bindings" (which were given 
        Original names before), and stand-alone deriving (which meant that those
        Original names came from a different module). Now the names are purely
        local an ordinary.
        To do this, InstInfo is parameterised like much else HsSyn stuff.
      * Improve the location info in a dfun, which in turn improves location 
        info for error messages, e.g. overlapping instances
      * Make sure that newtype-deriving isn't used for Typeable1 and friends.
        (Typeable was rightly taken care of, but not Typeable1,2, etc.)
      * Check for data types in deriving Data, so that you can't do, say,
       	deriving instance Data (IO a)
      * Decorate the derived binding with location info from the *instance* 
        rather than from the *tycon*.  Again, this really only matters with
        standalone deriving, but it makes a huge difference there.
      I think that's it.  Quite a few error messages change slightly.
      If we release 6.8.4, this should go in if possible.
  3. 25 Jun, 2008 1 commit
  4. 16 Jun, 2008 1 commit
    • Ian Lynagh's avatar
      More commandline flag improvements · 0f5e104c
      Ian Lynagh authored
      * Allow -ffoo flags to be deprecated
      * Mark some -ffoo flags as deprecated
      * Avoid using deprecated flags in error messages, in the build system, etc
      * Add a flag to en/disable the deprecated flag warning
  5. 06 Jun, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #2334: validity checking for type families · 1c05d4fb
      simonpj@microsoft.com authored
      When we deal with a family-instance declaration (TcTyClsDecls.tcFamInstDecl)
      we must check the TyCon for validity; for example, that a newtype has exactly
      one field.  That is done all-at-once for normal declarations, and had been
      forgotten altogether for families.
      I also refactored the interface to tcFamInstDecl1 slightly.
      A slightly separate matter: if there's an error in family instances
      (e.g. overlap) we get a confusing error message cascade if we attempt to
      deal with 'deriving' clauses too; this patch bales out earlier in that case.
      Another slightly separate matter: standalone deriving for family 
      instances can legitimately have more specific types, just like normal
      data decls. For example
         data instance F [a] = ...
         deriving instance (Eq a, Eq b) => Eq (F [(a,b)])
      So tcLookupFamInstExact can a bit more forgiving than it was.
  6. 12 Apr, 2008 1 commit
  7. 29 Mar, 2008 1 commit
  8. 17 Jan, 2008 2 commits
  9. 21 Dec, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Improve handling of newtypes (fixes Trac 1495) · 219f900f
      simonpj@microsoft.com authored
      In a few places we want to "look through" newtypes to get to the
      representation type.  But we need to be careful that  we don't fall 
      into an ininite loop with e.g.
      	newtype T = MkT T
      The old mechansim for doing this was to have a field nt_rep, inside 
      a newtype TyCon, that gave the "ultimate representation" of the type.
      But that failed for Trac 1495, which looked like this:
         newtype Fix a = Fix (a (Fix a))
         data I a = I a
      Then, expanding the type (Fix I) went on for ever.
      The right thing to do seems to be to check for loops when epxanding
      the *type*, rather than in the *tycon*.  This patch does that, 
      	- Removes nt_rep from TyCon
      	- Make Type.repType check for loops
      See Note [Expanding newtypes] in Type.lhs.
      At the same time I also fixed a bug for Roman, where newtypes were not
      being expanded properly in FamInstEnv.topNormaliseType.  This function
      and Type.repType share a common structure.
      	Ian, see if this merges easily to the branch
      	If not, I don't think it's essential to fix 6.8
  10. 28 Nov, 2007 1 commit
  11. 21 Nov, 2007 1 commit
  12. 20 Nov, 2007 1 commit
    • 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
  13. 12 Nov, 2007 1 commit
  14. 06 Nov, 2007 1 commit
  15. 05 Sep, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Refactor, improve, and document the deriving mechanism · 25f84fa7
      simonpj@microsoft.com authored
      This patch does a fairly major clean-up of the code that implements 'deriving.
      * The big changes are in TcDeriv, which is dramatically cleaned up.
        In particular, there is a clear split into
      	a) inference of instance contexts for deriving clauses
      	b) generation of the derived code, given a context 
        Step (a) is skipped for standalone instance decls, which 
        have an explicitly provided context.
      * The handling of "taggery", which is cooperative between TcDeriv and
        TcGenDeriv, is cleaned up a lot
      * I have added documentation for standalone deriving (which was 
        previously wrong).
      * The Haskell report is vague on exactly when a deriving clause should
        succeed.  Prodded by Conal I have loosened the rules slightly, thereyb
        making drv015 work again, and documented the rules in the user manual.
      I believe this patch validates ok (once I've update the test suite)
      and can go into the 6.8 branch.
  16. 04 Sep, 2007 1 commit
  17. 03 Sep, 2007 1 commit
  18. 01 Sep, 2007 1 commit
  19. 28 Aug, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Type checking for type synonym families · 5822cb8d
      chak@cse.unsw.edu.au. authored
      This patch introduces type checking for type families of which associated
      type synonyms are a special case. E.g.
              type family Sum n m
              type instance Sum Zero n = n
              type instance Sum (Succ n) m = Succ (Sum n m)
              data Zero       -- empty type
              data Succ n     -- empty type
      In addition we support equational constraints of the form:
              ty1 ~ ty2
      (where ty1 and ty2 are arbitrary tau types) in any context where
      type class constraints are already allowed, e.g.
              data Equals a b where
                      Equals :: a ~ b => Equals a b
      The above two syntactical extensions are disabled by default. Enable
      with the -XTypeFamilies flag.
      For further documentation about the patch, see:
              * the master plan
              * the user-level documentation
      The patch is mostly backwards compatible, except for:
              * Some error messages have been changed slightly.
              * Type checking of GADTs now requires a bit more type declarations:
                not only should the type of a GADT case scrutinee be given, but also
                that of any identifiers used in the branches and the return type.
      Please report any unexpected behavior and incomprehensible error message 
      for existing code.
      Contributors (code and/or ideas):
              Tom Schrijvers
              Manuel Chakravarty
              Simon Peyton-Jones
              Martin Sulzmann 
      with special thanks to Roman Leshchinskiy
  20. 10 Aug, 2007 1 commit
  21. 10 Jul, 2007 3 commits
  22. 08 Jul, 2007 1 commit
  23. 27 Jun, 2007 1 commit
  24. 07 Jun, 2007 1 commit
    • David Himmelstrup's avatar
      Fix a bug in MatchCon, and clarify what dataConInstOrigArgTys does · 00b6d256
      David Himmelstrup authored
      There was an outright bug in MatchCon.matchOneCon, in the construction
      of arg_tys.  Easily fixed.  It never showed up becuase the arg_tys are
      only used in WildPats, and they in turn seldom have their types looked
      (except by hsPatType).  So I can't make a test case for htis.
      While I was investigating, I added a bit of clarifation and
      invariant-checking to dataConInstOrigArgTys and dataConInstArgTys
  25. 20 Jun, 2007 1 commit
  26. 08 Jun, 2007 1 commit
  27. 14 May, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Revised signature of tcLookupFamInst and lookupFamInstEnv · 4899cc82
      chak@cse.unsw.edu.au. authored
      - This changes the signature of FamInstEnv.lookupFamInstEnv and
        FamInstEnv.lookupFamInstEnvUnify in a manner similar to SPJ's
        previous patch for InstEnv.llokupInstEnv
      - tcLookupFamInst now permits the lookup of instances that are more
        general than the type instance requested.
  28. 11 May, 2007 2 commits
  29. 02 May, 2007 1 commit
  30. 22 Apr, 2007 1 commit
  31. 16 Mar, 2007 1 commit
  32. 21 Feb, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Fix a deriving bug, arising from recent refactoring · 66f73ee4
      simonpj@microsoft.com authored
      This one is a hangover from something I did a month or two ago, but
      didn't get quite right.  tcSimplifyDefault should not check for no-instances;
      instead the checkValidInstance in TcDeriv does so.
      Conal's DeepArrow needs this fix.  Test is drv015.
  33. 07 Feb, 2007 1 commit
  34. 11 Jan, 2007 1 commit
  35. 04 Jan, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Fix and improve deriving for indexed data types · 3548802d
      chak@cse.unsw.edu.au. authored
      - The test for being able to derive the requested classes needs to be made
        with the representation tycon (not the family tycon).
      - Standalone deriving for indexed types requires the instance types in the
        derive clause to match a data/newtype instance exactly (modulo alpha).