1. 01 Oct, 2013 1 commit
  2. 13 Sep, 2013 1 commit
    • Iavor S. Diatchki's avatar
      Add support for evaluation of type-level natural numbers. · 1f77a534
      Iavor S. Diatchki authored
      This patch implements some simple evaluation of type-level expressions
      featuring natural numbers.  We can evaluate *concrete* expressions that
      use the built-in type families (+), (*), (^), and (<=?), declared in
      GHC.TypeLits.   We can also do some type inference involving these
      functions.  For example, if we encounter a constraint such as `(2 + x) ~ 5`
      we can infer that `x` must be 3.  Note, however, this is used only to
      resolve unification variables (i.e., as a form of a constraint improvement)
      and not to generate new facts.  This is similar to how functional
      dependencies work in GHC.
      
      The patch adds a new form of coercion, `AxiomRuleCo`, which makes use
      of a new form of axiom called `CoAxiomRule`.  This is the form of evidence
      generate when we solve a constraint, such as `(1 + 2) ~ 3`.
      
      The patch also adds support for built-in type-families, by adding a new
      form of TyCon rhs: `BuiltInSynFamTyCon`.  such built-in type-family
      constructors contain a record with functions that are used by the
      constraint solver to simplify and improve constraints involving the
      built-in function (see `TcInteract`).  The record in defined in `FamInst`.
      
      The type constructors and rules for evaluating the type-level functions
      are in a new module called `TcTypeNats`.
      1f77a534
  3. 05 Aug, 2013 1 commit
  4. 21 Jun, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Revise implementation of overlapping type family instances. · 569b2652
      eir@cis.upenn.edu authored
      This commit changes the syntax and story around overlapping type
      family instances. Before, we had "unbranched" instances and
      "branched" instances. Now, we have closed type families and
      open ones.
      
      The behavior of open families is completely unchanged. In particular,
      coincident overlap of open type family instances still works, despite
      emails to the contrary.
      
      A closed type family is declared like this:
      > type family F a where
      >   F Int = Bool
      >   F a   = Char
      The equations are tried in order, from top to bottom, subject to
      certain constraints, as described in the user manual. It is not
      allowed to declare an instance of a closed family.
      569b2652
  5. 28 May, 2013 1 commit
  6. 03 May, 2013 1 commit
  7. 21 Apr, 2013 1 commit
  8. 28 Jan, 2013 1 commit
    • Simon Peyton Jones's avatar
      Pure refactoring · f1fa6eb2
      Simon Peyton Jones authored
      * Move tidyType and friends from TcType to TypeRep
        (It was always wrong to have it in TcType.)
      
      * Move mkCoAxBranch and friends from FamInst to Coercion
      
      * Move pprCoAxBranch and friends from FamInstEnv to Coercion
      
      No change in functionality, though there might be a little
      wibble in error message output, because I combined two different
      functions both called pprCoAxBranch!
      f1fa6eb2
  9. 22 Jan, 2013 1 commit
  10. 14 Jan, 2013 1 commit
    • Simon Peyton Jones's avatar
      Be willing to parse {-# UNPACK #-} without '!' · deec5b74
      Simon Peyton Jones authored
      This change gives a more helpful error message when the
      user says    data T = MkT {-# UNPACK #-} Int
      which should have a strictness '!' as well. Rather than
      just a parse error, we get
      
        T7562.hs:3:14: Warning:
          UNPACK pragma lacks '!' on the first argument of `MkT'
      
      Fixes Trac #7562
      deec5b74
  11. 23 Dec, 2012 1 commit
    • Simon Peyton Jones's avatar
      Make {-# UNPACK #-} work for type/data family invocations · 1ee1cd41
      Simon Peyton Jones authored
      This fixes most of Trac #3990.  Consider
        data family D a
        data instance D Double = CD Int Int
        data T = T {-# UNPACK #-} !(D Double)
      Then we want the (D Double unpacked).
      
      To do this we need to construct a suitable coercion, and it's much
      safer to record that coercion in the interface file, lest the in-scope
      instances differ somehow.  That in turn means elaborating the HsBang
      type to include a coercion.
      
      To do that I moved HsBang from BasicTypes to DataCon, which caused
      quite a few minor knock-on changes.
      
      Interface-file format has changed!
      
      Still to do: need to do knot-tying to allow instances to take effect
      within the same module.
      1ee1cd41
  12. 19 Dec, 2012 1 commit
  13. 18 Sep, 2012 1 commit
    • Simon Peyton Jones's avatar
      Make a start towards eta-rules and injective families · 58470fb7
      Simon Peyton Jones authored
      * Make Any into a type family (which it should always have been)
        This is to support the future introduction of eta rules for
        product types (see email on ghc-users title "PolyKind issue"
        early Sept 2012)
      
      * Add the *internal* data type support for
          (a) closed type families [so that you can't give
              type instance for 'Any']
          (b) injective type families [because Any is really
              injective]
        This amounts to two boolean flags on the SynFamilyTyCon
        constructor of TyCon.SynTyConRhs.
      
      There is some knock-on effect, but all of a routine nature.
      
      It remains to offer source syntax for either closed or
      injective families.
      58470fb7
  14. 04 Nov, 2011 1 commit
  15. 06 Sep, 2011 1 commit
    • batterseapower's avatar
      Implement -XConstraintKind · 9729fe7c
      batterseapower authored
      Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact,
      this patch adds a new kind Constraint such that:
      
        Show :: * -> Constraint
        (?x::Int) :: Constraint
        (Int ~ a) :: Constraint
      
      And you can write *any* type with kind Constraint to the left of (=>):
      even if that type is a type synonym, type variable, indexed type or so on.
      
      The following (somewhat related) changes are also made:
       1. We now box equality evidence. This is required because we want
          to give (Int ~ a) the *lifted* kind Constraint
       2. For similar reasons, implicit parameters can now only be of
          a lifted kind. (?x::Int#) => ty is now ruled out
       3. Implicit parameter constraints are now allowed in superclasses
          and instance contexts (this just falls out as OK with the new
          constraint solver)
      
      Internally the following major changes were made:
       1. There is now no PredTy in the Type data type. Instead
          GHC checks the kind of a type to figure out if it is a predicate
       2. There is now no AClass TyThing: we represent classes as TyThings
          just as a ATyCon (classes had TyCons anyway)
       3. What used to be (~) is now pretty-printed as (~#). The box
          constructor EqBox :: (a ~# b) -> (a ~ b)
       4. The type LCoercion is used internally in the constraint solver
          and type checker to represent coercions with free variables
          of type (a ~ b) rather than (a ~# b)
      9729fe7c
  16. 02 Sep, 2011 1 commit
    • Simon Peyton Jones's avatar
      Some minor wibbling in printing source locations · 0ccf2c3b
      Simon Peyton Jones authored
      I found that an imported instance was getting printed with <no
      location info>.  Fixing this pushed me into a bit more refactoring
      than I intended, but it's all small aesthetic stuff, nothing
      fundamental.  Caused some error message to change as a result.
      
      I removed pprDefnLoc from the GHC API because it doesn't seem to be
      used.  Name.pprNamedefnLoc and pprDefinedAt are probably more useful
      anyway.
      0ccf2c3b
  17. 23 Aug, 2011 1 commit
  18. 22 Aug, 2011 1 commit
  19. 12 May, 2011 1 commit
    • Simon Peyton Jones's avatar
      The final batch of changes for the new coercion representation · c8c2f6bb
      Simon Peyton Jones authored
      * Fix bugs in the packing and unpacking of data
        constructors with equality predicates in their types
      
      * Remove PredCo altogether; instead, coercions between predicated
        types (like  (Eq a, [a]~b) => blah) are treated as if they
        were precisely their underlying representation type
             Eq a -> ((~) [a] b) -> blah
        in this case
      
      * Similarly, Type.coreView no longer treats equality
        predciates specially.
      
      * Implement the cast-of-coercion optimisation in
        Simplify.simplCoercionF
      
      Numerous other small bug-fixes and refactorings.
      
      Annoyingly, OptCoercion had Windows line endings, and this
      patch switches to Unix, so it looks as if every line has changed.
      c8c2f6bb
  20. 19 Apr, 2011 1 commit
    • Simon Peyton Jones's avatar
      This BIG PATCH contains most of the work for the New Coercion Representation · fdf86568
      Simon Peyton Jones authored
      See the paper "Practical aspects of evidence based compilation in System FC"
      
      * Coercion becomes a data type, distinct from Type
      
      * Coercions become value-level things, rather than type-level things,
        (although the value is zero bits wide, like the State token)
        A consequence is that a coerion abstraction increases the arity by 1
        (just like a dictionary abstraction)
      
      * There is a new constructor in CoreExpr, namely Coercion, to inject
        coercions into terms
      fdf86568
  21. 13 Sep, 2010 1 commit
  22. 25 May, 2010 2 commits
  23. 06 May, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3966: warn about useless UNPACK pragmas · 215ce9f1
      simonpj@microsoft.com authored
      Warning about useless UNPACK pragmas wasn't as easy as I thought.
      I did quite a bit of refactoring, which improved the code by refining
      the types somewhat.  In particular notice that in DataCon, we have
      
          dcStrictMarks   :: [HsBang]
          dcRepStrictness :: [StrictnessMarks]
      
      The former relates to the *source-code* annotation, the latter to
      GHC's representation choice.
      215ce9f1
  24. 07 Jul, 2009 1 commit
  25. 04 Aug, 2008 1 commit
  26. 12 Apr, 2008 1 commit
  27. 29 Mar, 2008 1 commit
  28. 26 Mar, 2008 1 commit
  29. 25 Mar, 2008 1 commit
  30. 06 Mar, 2008 1 commit
  31. 19 Feb, 2008 1 commit
  32. 21 Sep, 2007 1 commit
  33. 11 Sep, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Define and use PprTyThing.pprTypeForUser · 046feb1e
      simonpj@microsoft.com authored
      When printing types for the user, the interactive UI often wants to
      leave foralls implicit.  But then (as Claus points out) we need to be
      careful about name capture. For example with this source program
      
      	class C a b where
      	  op :: forall a. a -> b
      
      we were erroneously displaying the class in GHCi (with suppressed
      foralls) thus:
      
      	class C a b where
      	  op :: a -> b
      
      which is utterly wrong. 
      
      This patch fixes the problem, removes GHC.dropForAlls (which is dangerous),
      and instead supplies PprTyThing.pprTypeForUser, which does the right thing.
      
      046feb1e
  34. 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.
      3b1438a9
  35. 04 Sep, 2007 1 commit
  36. 03 Sep, 2007 1 commit
  37. 01 Sep, 2007 1 commit
  38. 09 Jul, 2007 1 commit
  39. 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
      arrrow.
      
      I took a slight shortcut and reused function-arrow prededence, so I think
      you may get
      	T -> T :% T
      meaning
      	T -> (T :% T)
      
      If that becomes a problem we can fix it.
      b15724ad