1. 04 Aug, 2008 1 commit
  2. 12 Apr, 2008 1 commit
  3. 07 Apr, 2008 1 commit
  4. 29 Mar, 2008 1 commit
  5. 15 Mar, 2008 1 commit
  6. 26 Jan, 2008 1 commit
  7. 07 Jan, 2008 1 commit
    • 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.
  8. 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
  9. 10 Sep, 2007 1 commit
    • Simon Marlow's avatar
      FIX #903: mkWWcpr: not a product · 3b1438a9
      Simon Marlow authored
      This fixes the long-standing bug that prevents some code with
      mutally-recursive modules from being compiled with --make and -O,
      including GHC itself.  See the comments for details.
      There are some additional cleanups that were forced/enabled by this
      patch: I removed importedSrcLoc/importedSrcSpan: it wasn't adding any
      useful information, since a Name already contains its defining Module.
      In fact when re-typechecking an interface file we were wrongly
      replacing the interesting SrcSpans in the Names with boring
      importedSrcSpans, which meant that location information could degrade
      after reloading modules.  Also, recreating all these Names was a waste
      of space/time.
  10. 04 Sep, 2007 1 commit
  11. 03 Sep, 2007 1 commit
  12. 01 Sep, 2007 1 commit
  13. 29 Jun, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Overlap check for type families · 5a3ada9c
      chak@cse.unsw.edu.au. authored
      - If two "type instance"s overlap, they right-hand sides must be syntactically
        equal under the overlap substitution.  (Ie, we admit limited overlap, but
        require the system to still be confluent.)
  14. 25 Jun, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Print infix type constructors in an infix way · b15724ad
      simonpj@microsoft.com authored
      Fixes Trac #1425.  The printer for types doesn't know about fixities.
      (It could be educated to know, but it doesn't at the moment.)  So it
      treats all infix tycons as of precedence less than application and function
      I took a slight shortcut and reused function-arrow prededence, so I think
      you may get
      	T -> T :% T
      	T -> (T :% T)
      If that becomes a problem we can fix it.
  15. 23 May, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Improve the interaction of 'seq' and associated data types · 9670d664
      simonpj@microsoft.com authored
      Roman produced programs involving associated types that did not optimise well.
      His programs were something like this:
        data family T a
        data instance T Int = MkT Bool Char
        bar :: T Int -> Int
        bar t = t `seq` loop 0
      	  loop = ...
      You'd think that the `seq` should unbox 't' outside the loop, since
      a (T Int) is just a MkT pair.  
      The most robust way to make this happen is for the simplifier to understand
      a bit about type-family instances.   See 
      	Note [Improving seq]
      in Simplify.lhs.  We use FamInstEnv.topNormaliseType to do the interesting
      To make this happen I did a bit of refactoring to the simplifier
      I'd previously done a very similar transformation in LiberateCase, but it
      was happening too late.  So this patch takes it out of LiberateCase as
      well as adding it to Simplify.
  16. 11 May, 2007 1 commit
  17. 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.
  18. 11 May, 2007 1 commit
  19. 25 Apr, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Generating synonym instance representation tycons · 13cd965d
      chak@cse.unsw.edu.au. authored
      - Type synonym instances are turned into representation synonym tycons
      - They are entered into the pool of family instances (FamInst environments)
        in the same way as data/newtype instances
      - Still missing is writing the parent tycon information into ifaces and 
        various well-formedness checks.
  20. 11 Jan, 2007 1 commit
  21. 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).
  22. 03 Jan, 2007 1 commit
  23. 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
      	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
  24. 18 Dec, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Deriving for indexed data types · 380512de
      chak@cse.unsw.edu.au. authored
      - This patch implements deriving clauses for data instance declarations
        (toplevel and associated)
      - Doesn't support standalone deriving.  This could be easily supported,
        but requires an extension of the syntax of standalone deriving clauses.
        Björn, fancy adding this?
      - We cannot derive Typeable.  This seems a problem of notation, more than 
        anything else.  Why?  For a binary vanilla data type "T a b", we would 
        generate an instance Typeable2 T; ie, the instance is for the constructor
        alone.  In the case of a family instance, such as (S [a] (Maybe b)), we
        simply have no means to denote the associated constuctor.  It appears to
        require type level lambda - something like (/\a b. S [a] (Maybe b).
      - Derivings are for *individual* family *instances*, not for entire families.
        Currently, I know of no simple translation of class instances for entire 
        families to System F_C.  This actually seems to be similar to implementing
        open data types à la Löh & Hinze.
      - This patch only covers data types, not newtypes.
  25. 12 Oct, 2006 1 commit
  26. 11 Oct, 2006 1 commit
  27. 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.		***
  28. 20 Sep, 2006 1 commit