1. 05 Sep, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Fix up the instance-declaration re-engineering story · 4f597914
      simonpj@microsoft.com authored
      This patch deals with a rather complicated situation involving
      overlapping instances.  It's all explained in the commments
         Note [Subtle interaction of recursion and overlap]
      
      The absence of this case make DoCon and regex-base fail with
      an error about overlapping instances.  Now they work properly 
      again.
      
      4f597914
  2. 03 Sep, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Major change in compilation of instance declarations (fix Trac #955, #2328) · f16dbbbe
      simonpj@microsoft.com authored
      This patch makes an important change to the way that dictionary
      functions are handled.  Before, they were unconditionally marked
      INLIINE, but all the code written by the user in the instance
      was inside that unconditionally-inlined function.  Result: massive
      code bloat in programs that use complicated instances.
      
      This patch make instances behave rather as if all the methods
      were written in separate definitions.  That dramatically reduces
      bloat.  The new plan is described in TcInstDcls
      	Note [How instance declarations are translated]
      
      Everything validates.  The major code-bloat bug is squashed: in particular
      DoCon is fine now (Trac #2328) and I believe that #955 is also better.
      
      Nofib results:
      
      Binary sizes
              -1 s.d.      +2.5%
              +1 s.d.      +3.1%
              Average      +2.8%
      
      Allocations
              -1 s.d.      -6.4%
              +1 s.d.      +2.5%
              Average      -2.0%
      
      Note that 2% improvement.  Some programs improve by 20% (rewrite)!
      Two get slightly worse: pic (2.1%), and gameteb (3.2%), but all others
      improve or stay the same.
      
      I am not absolutely 100% certain that all the corners are correct; for
      example, when default methods are marked INLINE, are they inlined?  But
      overall it's better.
      
      It's nice that the patch also removes a lot of code.  I deleted some
      out of date comments, but there's something like 100 fewer lines of
      code in the new version!  (In the line counts below, there are a lot
      of new comments.)
      f16dbbbe
  3. 27 Aug, 2008 1 commit
  4. 31 Jul, 2008 1 commit
  5. 21 Jul, 2008 1 commit
  6. 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.
      9319fbaf
  7. 06 Jun, 2008 2 commits
    • Ian Lynagh's avatar
      Fix warnings in TcInstDcls · 030ecd78
      Ian Lynagh authored
      030ecd78
    • 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.
       
      1c05d4fb
  8. 21 May, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #1061: refactor handling of default methods · 24f3ffda
      simonpj@microsoft.com authored
      In an instance declaration, omitted methods get a definition that
      uses the default method.  We used to generate source code and feed it
      to the type checker.  But tc199 shows that is a bad idea -- see
      Note [Default methods in instances] in TcClassDcl.
      
      So this patch refactors to insteadl all us to generate the 
      *post* typechecked code directly for default methods.
      24f3ffda
  9. 04 May, 2008 1 commit
  10. 12 Apr, 2008 1 commit
  11. 22 Apr, 2008 1 commit
  12. 17 Jan, 2008 1 commit
  13. 27 Oct, 2007 1 commit
    • simonpj@microsoft.com's avatar
      In an AbsBinds, the 'dicts' can include EqInsts · 6bb65108
      simonpj@microsoft.com authored
      An AbsBinds abstrats over evidence, and the evidence can be both
      Dicts (class constraints, implicit parameters) and EqInsts (equality
      constraints).  So we need to
        - use varType rather than idType
        - use instToVar rather than instToId
        - use zonkDictBndr rather than zonkIdBndr in zonking
      
      It actually all worked before, but gave warnings.
      
      6bb65108
  14. 15 Sep, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Overhaul of the rewrite rules · 6d2b0ae3
      chak@cse.unsw.edu.au. authored
      - Cleaned up and simplified rules
      - Added many missing cases
      - The rules OccursCheck and swap have been eliminated and integrate with
        the other rules; ie, Subst and Unify perform the occurs check themselves
        and they can deal with left-to-right and right-to-left oriented rewrites.
        This makes the code simpler and more efficient.
      - Also added comments.
      6d2b0ae3
  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.
      25f84fa7
  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)
      
      where
      
              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
                http://hackage.haskell.org/trac/ghc/wiki/TypeFunctions
      
              * the user-level documentation
                http://haskell.org/haskellwiki/GHC/Indexed_types
      
      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
      5822cb8d
  20. 27 Jun, 2007 1 commit
  21. 11 May, 2007 1 commit
  22. 22 Apr, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Fix corner case of useless constraint in SPECIALISE pragma · e5ca7e6e
      simonpj@microsoft.com authored
      	MERGE TO STABLE
      
      This patch fixes Trac #1287.  
      
      The problem is described in Note [Unused spec binders] in DsBinds.
      
      At the same time I realised that the error messages in DsBinds.dsPrag
      were being given the location of the *binding* not the *pragma*.
      So I've fixed that too.
      e5ca7e6e
  23. 05 Jan, 2007 1 commit
  24. 03 Jan, 2007 1 commit
  25. 02 Jan, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Big tidy-up of deriving code · 84923cc7
      simonpj@microsoft.com authored
      This tidy-up, triggered by Trac #1068, re-factors the way that 'deriving' 
      happens.  It took me way longer than I had intended.  The main changes,
      by far are to TcDeriv; everyting else is a minor consequence.
      
      While I was at it, I changed the syntax for standalone deriving, so that
      it goes
      	derive instance Show (T a)
      
      (instead of "derive Show for T").  However, there's still an implicit
      context, generated by the deriving code, and I wonder if it shouldn't really
      be
      	derive instance (..) => Show (T a)
      but I have left it simple for now.
      
      I also added a function Type.substTyVars, and used it here and there, which
      led to some one-line changes otherwise unrelated (sorry).
      
      Loose ends:
        * 'deriving Typeable' for indexed data types is still not right
        * standalone deriving should be documented
      84923cc7
  26. 29 Dec, 2006 1 commit
  27. 10 Nov, 2006 2 commits
  28. 11 Oct, 2006 1 commit
  29. 10 Oct, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Rough matches for family instances · 2a8cdc3a
      chak@cse.unsw.edu.au. authored
      - Class and type family instances just got a lot more similar.
      - FamInst, like Instance, now has a rough match signature.  The idea is the
        same: if the rough match doesn't match, there is no need to pull in the while
        tycon describing the instance (from a lazily read iface).
      - IfaceFamInst changes in a similar way and the list of all IFaceFamInsts is
        now written into the binary iface (as for class instances), as deriving it
        from the tycon (as before) would render the whole rough matching useless.
      - As a result of this, the plumbing of class instances and type instances 
        through the various environments, ModIface, ModGuts, and ModDetails is now
        almost the same.  (The remaining difference are mostly because the dfun of a
        class instance is an Id, but type instance refer to a TyCon, not an Id.)
      
      *** WARNING: The interface file format changed! ***
      ***	     Rebuild from scratch.		***
      2a8cdc3a
  30. 20 Sep, 2006 1 commit
  31. 18 Sep, 2006 1 commit
  32. 29 Sep, 2006 1 commit
  33. 26 Sep, 2006 1 commit
  34. 25 Sep, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Fix newtype deriving properly (un-doing Audreys patch) · 171d4582
      simonpj@microsoft.com authored
      The newtype-deriving mechanism generates a HsSyn case expression looking
      like this
      	case (d `cast` co) of { ... }
      That is, the case expression scrutinises a dictionary.  This is 
      otherwise never seen in HsSyn, and it made the desugarer
      (Check.get_unused_cons) crash in tcTyConAppTyCon.
      
      It would really be better to generate Core in TcInstDecls (the newtype
      deriving part) but I'm not going to do that today.  Instead, I made
      Check.get_unused_cons a bit more robust.
      
      Audrey tried to fix this over the weekend, but her fix was, alas, utterly
      bogus, which caused mysterious failures later.  I completely undid this
      change.
      
      Anyway it should work now!
      171d4582
  35. 23 Sep, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Re-work the newtype-deriving support · 2ce87c70
      simonpj@microsoft.com authored
      The newtype deriving mechanism is much trickier to support than it
      seems at first.  Kevin didn't get it quite right when moving to FC,
      and I ended up re-writing quite a bit of it.  
      
      I think it's right now, but I have not yet tested it thoroughly.
      2ce87c70
  36. 20 Sep, 2006 3 commits
    • chak@cse.unsw.edu.au.'s avatar
      Basic set up for global family instance environment · 138b885a
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:52:34 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Basic set up for global family instance environment
        Fri Sep 15 15:20:44 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Basic set up for global family instance environment
      138b885a
    • chak@cse.unsw.edu.au.'s avatar
      Straightened out implicit coercions for indexed types · d76c18e0
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:35:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Straightened out implicit coercions for indexed types
        Mon Sep  4 23:46:14 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Straightened out implicit coercions for indexed types
          - HscTypes.implicitTyThings and LoadIface.ifaceDeclSubBndrs now
            include the coercion of indexed data/newtypes.
          - Name generation for the internal names of indexed data/newtypes now uses
            the same counter that generates the dfun unique indexes (ie, class and type
            instances are counted with the one counter).  We could make this two 
            separate counters if that's what's preferred.
          - The unique index of a data/newtype instances needs to go into the iface, so
            that we can generate the same names on slurping in the iface as when the
            original module was generated.  This is a bit yucky, but I don't see a way
            to avoid that (other than putting the full blown internal tycon name and 
            coercion name into the iface, which IMHO would be worse).
          - The predicate for when a datacon has a wrapper didn't take GADT
            equations nor whether it comes froma  family instance into account.
          
          *** WARNING!  This patch changed the interface file format. ***
          ***           Please recompile from scratch.                ***
      d76c18e0
    • chak@cse.unsw.edu.au.'s avatar
      Better error message for indexes that must be variables · b5d068a2
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:19:10 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Better error message for indexes that must be variables
        Wed Aug 30 20:21:33 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Better error message for indexes that must be variables
      b5d068a2