1. 16 Dec, 2009 3 commits
  2. 11 Dec, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Use full equality for CSE · 21eeb926
      simonpj@microsoft.com authored
      In CSE we were getting lots of apprarently-unequal expressions with
      the same hash code.  In fact they were perfectly equal -- but we were
      using a cheap-and-cheerful equality tests for CoreExpr that said False
      for any lambda expression!
      
      This patch adds a proper equality test for Core, with alpha-renaming.
      It's easy to do, and will avoid silly cases of CSE failing to fire.
      
      We should get less of this:
        WARNING: file compiler/simplCore/CSE.lhs line 326
        extendCSEnv: long list, length 18
      from a compiler built with -DDEBUG
      21eeb926
  3. 12 Nov, 2009 1 commit
    • simonpj@microsoft.com's avatar
      A radical overhaul of the coercion infrastucture · cd0e2c0c
      simonpj@microsoft.com authored
      * Core Lint now does full checking of kinds and coercion terms
        which picks up kind errors in coercions that were previously
        simply not checked for
      
      * Coercion.lhs now provides optCoercion which optimises coercion
        terms.  It implements all of Dimitrios's rules
      
      * The constructors for coercion terms now make no attempt to be
        "smart"; instead we rely solely on the coercion optimiser
      
      * CoercionTyCons in TyCon.lhs always had a "custom" kinding rule
        (the coKindFun field of CoercionTyCon) but its type was not 
        clever enough to do both 
           (a) *figure out the result kind*, assuming the whole thing
               is well-kinded in the first place
           (b) *check* the kinds of everything, failing gracefully if
               they aren't right. 
        We need (b) for the new CoreLint stuff. The field now has type
              CoTyConKindChecker
        which does the job nicely.
      cd0e2c0c
  4. 08 Nov, 2009 1 commit
  5. 06 Nov, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Tidy up coercions, and implement csel1, csel2, cselR · bcadca67
      simonpj@microsoft.com authored
      In preparation for implementing the PushC rule for coercion-swizzling
      in the Simplifier, I had to inmplement the three new decomposition
      operators for coercions, which I've called csel1, csel2, and cselR.
      
           co :: ((s1~t1) => r1) ~ ((s2~t2) => r2)
           ---------------------------------------
                    csel1 co :: s1~s2
      
      and similarly csel2, cselR.
      
      On the way I fixed the coercionKind function for types of form
                (s1~t2) => r2
      which currently are expressed as a forall type.  
      
      And I refactored quite a bit to help myself understand what is
      going on.
      bcadca67
  6. 30 Oct, 2009 1 commit
  7. 28 Oct, 2009 1 commit
  8. 26 Oct, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Add a coercion optimiser, to reduce the size of coercion terms · 48196c3c
      simonpj@microsoft.com authored
      Coercion terms can get big (see Trac #2859 for example), so this
      patch puts the infrastructure in place to optimise them:
      
        * Adds Coercion.optCoercion :: Coercion -> Coercion
      
        * Calls optCoercion in Simplify.lhs
      
      The optimiser doesn't work right at the moment, so it is 
      commented out, but Tom is going to work on it.
      48196c3c
  9. 06 Jul, 2009 1 commit
  10. 15 Mar, 2009 1 commit
  11. 13 Jan, 2009 1 commit
  12. 29 Oct, 2008 1 commit
  13. 20 Sep, 2008 1 commit
  14. 31 Jul, 2008 1 commit
  15. 12 Apr, 2008 1 commit
  16. 29 Mar, 2008 1 commit
  17. 15 Mar, 2008 1 commit
  18. 06 Feb, 2008 1 commit
    • rl@cse.unsw.edu.au's avatar
      Teach cheapEqExpr about casts · a4835b8b
      rl@cse.unsw.edu.au authored
      Previously, cheapEqExpr would always return False if it encountered a cast.
      This was bad for two reasons. Firstly, CSE (which uses cheapEqExpr to compare
      expressions) never eliminated expressions which contained casts and secondly,
      it was inconsistent with exprIsBig. This patch fixes this.
      a4835b8b
  19. 26 Jan, 2008 1 commit
  20. 03 Oct, 2007 1 commit
  21. 29 Sep, 2007 1 commit
  22. 10 Sep, 2007 1 commit
  23. 04 Sep, 2007 1 commit
  24. 03 Sep, 2007 1 commit
  25. 01 Sep, 2007 1 commit
  26. 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
  27. 09 Aug, 2007 1 commit
  28. 23 May, 2007 1 commit
  29. 11 May, 2007 1 commit
  30. 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.
      13cd965d
  31. 05 Feb, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Improve simplification of coercions · 77241a03
      simonpj@microsoft.com authored
      At the moment GHC really does very little simplification of coercions.
      This patch improves matters, but it's still not great, especially when
      you have chains linked together with 'trans'. 
      
      I'm also concerned that I have not yet implemented the 'leftc' and 'rightc'
      coercions we added to the paper. 
      
      But at least things are better than they were.  In particular
      	g `trans` sym g
      now cancels to give the identity.
      
      77241a03
  32. 11 Jan, 2007 1 commit
  33. 13 Oct, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Add assertion checks for mkCoVar/mkTyVar · ac704fca
      simonpj@microsoft.com authored
      A type variable has a flag saying whether it is a *type* variable or
      a *coercion* variable.  This patch adds assertions to check the flag.
      
      And it adds fixes to places which were Wrong (and hence fired the
      assertion)! 
      
      Also removed isCoVar from Coercion, since it's done by Var.isCoVar.
      
      
      ac704fca
  34. 11 Oct, 2006 2 commits
    • Simon Marlow's avatar
      ab22f4e6
    • Simon Marlow's avatar
      Interface file optimisation and removal of nameParent · b00b5bc0
      Simon Marlow authored
      This large commit combines several interrelated changes:
      
        - IfaceSyn now contains actual Names rather than the special
          IfaceExtName type.  The binary interface file contains
          a symbol table of Names, where each entry is a (package,
          ModuleName, OccName) triple.  Names in the IfaceSyn point
          to entries in the symbol table.
      
          This reduces the size of interface files, which should
          hopefully improve performance (not measured yet).
      
          The toIfaceXXX functions now do not need to pass around
          a function from Name -> IfaceExtName, which makes that
          code simpler.
      
        - Names now do not point directly to their parents, and the
          nameParent operation has gone away.  It turned out to be hard to
          keep this information consistent in practice, and the parent info
          was only valid in some Names.  Instead we made the following
          changes:
      
          * ImportAvails contains a new field 
                imp_parent :: NameEnv AvailInfo
            which gives the family info for any Name in scope, and
            is used by the renamer when renaming export lists, amongst
            other things.  This info is thrown away after renaming.
      
          * The mi_ver_fn field of ModIface now maps to
            (OccName,Version) instead of just Version, where the
            OccName is the parent name.  This mapping is used when
            constructing the usage info for dependent modules.
            There may be entries in mi_ver_fn for things that are not in
            scope, whereas imp_parent only deals with in-scope things.
      
          * The md_exports field of ModDetails now contains
            [AvailInfo] rather than NameSet.  This gives us
            family info for the exported names of a module.
      
      Also:
      
         - ifaceDeclSubBinders moved to IfaceSyn (seems like the
           right place for it).
      
         - heavily refactored renaming of import/export lists.
      
         - Unfortunately external core is now broken, as it relied on
           IfaceSyn.  It requires some attention.
      b00b5bc0
  35. 29 Sep, 2006 1 commit
  36. 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
  37. 20 Sep, 2006 1 commit
    • 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