1. 14 Jul, 2012 3 commits
    • Ian Lynagh's avatar
      Add a separate FastZString type · 509d2ad2
      Ian Lynagh authored
      FastStrings are now always UTF8-encoded.
      
      There's no StringTable for FastZString, but I don't think one is needed.
      We only ever make a FastZString by running zEncodeFS on a FastString,
      and the FastStrings are shared via the FastString StringTable, so we get
      the same FastZString from the IORef.
      509d2ad2
    • Ian Lynagh's avatar
      Implement FastBytes, and use it for MachStr · 7ae1bec5
      Ian Lynagh authored
      This is a first step on the way to refactoring the FastString type.
      
      FastBytes currently has no unique, mainly because there isn't currently
      a nice way to produce them in Binary.
      
      Also, we don't currently do the "Dictionary" thing with FastBytes in
      Binary. I'm not sure whether this is important.
      
      We can change both decisions later, but in the meantime this gets the
      refactoring underway.
      7ae1bec5
    • Ian Lynagh's avatar
      Whitespace only in Unique · c8c56579
      Ian Lynagh authored
      c8c56579
  2. 27 Jun, 2012 2 commits
    • Ian Lynagh's avatar
      Add some more Integer rules; fixes #6111 · c7a8941b
      Ian Lynagh authored
      c7a8941b
    • Simon Peyton Jones's avatar
      Add silent superclass parameters (again) · aa1e0976
      Simon Peyton Jones authored
      Silent superclass parameters solve the problem that
      the superclasses of a dicionary construction can easily
      turn out to be (wrongly) bottom.  The problem and solution
      are described in
         Note [Silent superclass arguments] in TcInstDcls
      
      I first implemented this fix (with Dimitrios) in Dec 2010, but removed
      it again in Jun 2011 becuase we thought it wasn't necessary any
      more. (The reason we thought it wasn't necessary is that we'd stopped
      generating derived superclass constraints for *wanteds*.  But we were
      wrong; that didn't solve the superclass-loop problem.)
      
      So we have to re-implement it.  It's not hard.  Main features:
      
        * The IdDetails for a DFunId says how many silent arguments it has
      
        * A DFunUnfolding describes which dictionary args are
          just parameters (DFunLamArg) and which are a function to apply
          to the parameters (DFunPolyArg).  This adds the DFunArg type
          to CoreSyn
      
        * Consequential changes to IfaceSyn.  (Binary hi file format changes
          slightly.)
      
        * TcInstDcls changes to generate the right dfuns
      
        * CoreSubst.exprIsConApp_maybe handles the new DFunUnfolding
      
      The thing taht is *not* done yet is to alter the vectoriser to
      pass the relevant extra argument when building a PA dictionary.
      aa1e0976
  3. 22 Jun, 2012 1 commit
    • Ian Lynagh's avatar
      Remove some uses of sortLe · 0043f07a
      Ian Lynagh authored
      Technically the behaviour of sortWith has changed, as it used
          x `le` y = get_key x < get_key y
      (note "<" rather than "<="), but I assume that that was just a mistake.
      0043f07a
  4. 21 Jun, 2012 1 commit
    • jpm@cs.ox.ac.uk's avatar
      Allow deriving Generic1 · 156ec95a
      jpm@cs.ox.ac.uk authored
      This completes the support for generic programming introduced
      in GHC 7.2. Generic1 allows defining generic functions that
      operate on type containers, such as `fmap`, for instance.
      
      Along the way we have fixed #5936 and #5939, allowing
      deriving Generic/Generic1 for data families, and disallowing
      deriving Generic/Generic1 for instantiated types.
      
      Most of this patch is Nicolas Frisby's work.
      156ec95a
  5. 18 Jun, 2012 1 commit
  6. 13 Jun, 2012 2 commits
    • Ian Lynagh's avatar
      b522d3a3
    • Simon Peyton Jones's avatar
      Simplify the implementation of Implicit Parameters · 5a8ac0f8
      Simon Peyton Jones authored
      This patch re-implements implicit parameters via a class
      with a functional dependency:
      
          class IP (n::Symbol) a | n -> a where
            ip :: a
      
      This definition is in the library module GHC.IP. Notice
      how it use a type-literal, so we can have constraints like
         IP "x" Int
      Now all the functional dependency machinery works right to make
      implicit parameters behave as they should.
      
      Much special-case processing for implicit parameters can be removed
      entirely. One particularly nice thing is not having a dedicated
      "original-name cache" for implicit parameters (the nsNames field of
      NameCache).  But many other cases disappear:
      
        * BasicTypes.IPName
        * IPTyCon constructor in Tycon.TyCon
        * CIPCan constructor  in TcRnTypes.Ct
        * IPPred constructor  in Types.PredTree
      
      Implicit parameters remain special in a few ways:
      
       * Special syntax.  Eg the constraint (IP "x" Int) is parsed
         and printed as (?x::Int).  And we still have local bindings
         for implicit parameters, and occurrences thereof.
      
       * A implicit-parameter binding  (let ?x = True in e) amounts
         to a local instance declaration, which we have not had before.
         It just generates an implication contraint (easy), but when
         going under it we must purge any existing bindings for
         ?x in the inert set.  See Note [Shadowing of Implicit Parameters]
         in TcSimplify
      
       * TcMType.sizePred classifies implicit parameter constraints as size-0,
         as before the change
      
      There are accompanying patches to libraries 'base' and 'haddock'
      
      All the work was done by Iavor Diatchki
      5a8ac0f8
  7. 12 Jun, 2012 6 commits
  8. 11 Jun, 2012 2 commits
  9. 07 Jun, 2012 1 commit
  10. 06 Jun, 2012 2 commits
  11. 05 Jun, 2012 1 commit
  12. 15 May, 2012 1 commit
    • batterseapower's avatar
      Support code generation for unboxed-tuple function arguments · 09987de4
      batterseapower authored
      This is done by a 'unarisation' pre-pass at the STG level which
      translates away all (live) binders binding something of unboxed
      tuple type.
      
      This has the following knock-on effects:
        * The subkind hierarchy is vastly simplified (no UbxTupleKind or ArgKind)
        * Various relaxed type checks in typechecker, 'foreign import prim' etc
        * All case binders may be live at the Core level
      09987de4
  13. 20 Apr, 2012 1 commit
    • Simon Peyton Jones's avatar
      Do SCC on instance declarations (fixes Trac #5715) · fa9fdc28
      Simon Peyton Jones authored
      The trouble here is that given
      
          {-# LANGUAGE DataKinds, TypeFamilies #-}
          data instance Foo a = Bar (Bar a)
      
      we want to get a sensible message that we can't use the promoted 'Bar'
      constructor until after its definition; it's a staging error.  Bud the
      staging mechanism that we use for vanilla data declarations don't work
      here.
      
      Solution is to perform strongly-connected component analysis on the
      instance declarations. But that in turn means that we need to track
      free-variable information on more HsSyn declarations, which is why
      so many files are touched.  All the changes are boiler-platey except
      the ones in TcInstDcls.
      fa9fdc28
  14. 05 Apr, 2012 1 commit
  15. 30 Mar, 2012 1 commit
  16. 28 Mar, 2012 1 commit
  17. 24 Mar, 2012 1 commit
  18. 02 Mar, 2012 1 commit
    • Simon Peyton Jones's avatar
      Hurrah! This major commit adds support for scoped kind variables, · 3bf54e78
      Simon Peyton Jones authored
      which (finally) fills out the functionality of polymorphic kinds.
      It also fixes numerous bugs.
      
      Main changes are:
      
      Renaming stuff
      ~~~~~~~~~~~~~~
      * New type in HsTypes:
           data HsBndrSig sig = HsBSig sig [Name]
        which is used for type signatures in patterns, and kind signatures
        in types.  So when you say
             f (x :: [a]) = x ++ x
        or
             data T (f :: k -> *) (x :: *) = MkT (f x)
        the signatures in both cases are a HsBndrSig.
      
      * The [Name] in HsBndrSig records the variables bound by the
        pattern, that is 'a' in the first example, 'k' in the second,
        and nothing in the third.  The renamer initialises the field.
      
      * As a result I was able to get rid of
           RnHsSyn.extractHsTyNames :: LHsType Name -> NameSet
        and its friends altogether.  Deleted the entire module!
        This led to some knock-on refactoring; in particular the
        type renamer now returns the free variables just like the
        term renamer.
      
      Kind-checking types: mainly TcHsType
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      A major change is that instead of kind-checking types in two
      passes, we now do one. Under the old scheme, the first pass did
      kind-checking and (hackily) annotated the HsType with the
      inferred kinds; and the second pass desugared the HsType to a
      Type.  But now that we have kind variables inside types, the
      first pass (TcHsType.tc_hs_type) can go straight to Type, and
      zonking will squeeze out any kind unification variables later.
      
      This is much nicer, but it was much more fiddly than I had expected.
      
      The nastiest corner is this: it's very important that tc_hs_type
      uses lazy constructors to build the returned type. See
      Note [Zonking inside the knot] in TcHsType.
      
      Type-checking type and class declarations: mainly TcTyClsDecls
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      I did tons of refactoring in TcTyClsDecls.  Simpler and nicer now.
      
      Typechecking bindings: mainly TcBinds
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      I rejigged (yet again) the handling of type signatures in TcBinds.
      It's a bit simpler now.  The main change is that tcTySigs goes
      right through to a TcSigInfo in one step; previously it was split
      into two, part here and part later.
      
      Unsafe coercions
      ~~~~~~~~~~~~~~~~
      Usually equality coercions have exactly the same kind on both
      sides.  But we do allow an *unsafe* coercion between Int# and Bool,
      say, used in
          case error Bool "flah" of { True -> 3#; False -> 0# }
      -->
          (error Bool "flah") |> unsafeCoerce Bool Int#
      
      So what is the instantiation of (~#) here?
         unsafeCoerce Bool Int# :: (~#) ??? Bool Int#
      I'm using OpenKind here for now, but it's un-satisfying that
      the lhs and rhs of the ~ don't have precisely the same kind.
      
      More minor
      ~~~~~~~~~~
      * HsDecl.TySynonym has its free variables attached, which makes
        the cycle computation in TcTyDecls.mkSynEdges easier.
      
      * Fixed a nasty reversed-comparison bug in FamInstEnv:
        @@ -490,7 +490,7 @@ lookup_fam_inst_env' match_fun one_sided ie fam tys
           n_tys = length tys
           extra_tys = drop arity tys
           (match_tys, add_extra_tys)
      -       | arity > n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
      +       | arity < n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
              | otherwise     = (tys,            \res_tys -> res_tys)
      3bf54e78
  19. 17 Feb, 2012 2 commits
  20. 16 Feb, 2012 1 commit
  21. 06 Feb, 2012 1 commit
  22. 13 Jan, 2012 1 commit
  23. 09 Jan, 2012 1 commit
    • Iavor S. Diatchki's avatar
      Change -XTypeOperators to treat all type-operators as type-constructors. · 85926ae6
      Iavor S. Diatchki authored
      Previously, only type operators starting with ":" were type constructors,
      and writing "+" in a type resulted in a type variable.  Now, type
      variables are always ordinary identifiers, and all operators are treated
      as constructors.  One can still write type variables in infix form though,
      for example, "a `fun` b" is a type expression with 3 type variables: "a",
      "fun", and "b".
      
      Writing (+) in an import/export list always refers to the value (+)
      and not the type.   To refer to the type one can write either "type (+)",
      or provide an explicit suobrdinate list (e.g., "(+)()").  For clarity,
      one can also combine the two, for example "type (+)(A,B,C)" is also
      accepted and means the same thing as "(+)(A,B,C)" (i.e., export the type
      (+), with the constructors A,B,and C).
      85926ae6
  24. 03 Jan, 2012 2 commits
    • Simon Peyton Jones's avatar
      Be less verbose when printing out Vars · b2223682
      Simon Peyton Jones authored
      For some reason we were printing every occurrence with its type
      and that is far too much.
      b2223682
    • Simon Peyton Jones's avatar
      Major refactoring of CoAxioms · 98a642cf
      Simon Peyton Jones authored
      This patch should have no user-visible effect.  It implements a
      significant internal refactoring of the way that FC axioms are
      handled.  The ultimate goal is to put us in a position to implement
      "pattern-matching axioms".  But the changes here are only does
      refactoring; there is no change in functionality.
      
      Specifically:
      
       * We now treat data/type family instance declarations very,
         very similarly to types class instance declarations:
      
         - Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with
           FamInstEnv.FamInst.  This change does affect the GHC API, but
           for the better I think.
      
         - Previously, each family type/data instance declaration gave rise
           to a *TyCon*; typechecking a type/data instance decl produced
           that TyCon.  Now, each type/data instance gives rise to
           a *FamInst*, by direct analogy with each class instance
           declaration giving rise to a ClsInst.
      
         - Just as each ClsInst contains its evidence, a DFunId, so each FamInst
           contains its evidence, a CoAxiom.  See Note [FamInsts and CoAxioms]
           in FamInstEnv.  The CoAxiom is a System-FC thing, and can relate any
           two types, whereas the FamInst relates directly to the Haskell source
           language construct, and always has a function (F tys) on the LHS.
      
         - Just as a DFunId has its own declaration in an interface file, so now
           do CoAxioms (see IfaceSyn.IfaceAxiom).
      
         These changes give rise to almost all the refactoring.
      
       * We used to have a hack whereby a type family instance produced a dummy
         type synonym, thus
            type instance F Int = Bool -> Bool
         translated to
            axiom FInt :: F Int ~ R:FInt
            type R:FInt = Bool -> Bool
         This was always a hack, and now it's gone.  Instead the type instance
         declaration produces a FamInst, whose axiom has kind
            axiom FInt :: F Int ~ Bool -> Bool
         just as you'd expect.
      
       * Newtypes are done just as before; they generate a CoAxiom. These
         CoAxioms are "implicit" (do not generate an IfaceAxiom declaration),
         unlike the ones coming from family instance declarations.  See
         Note [Implicit axioms] in TyCon
      
      On the whole the code gets significantly nicer.  There were consequential
      tidy-ups in the vectoriser, but I think I got them right.
      98a642cf
  25. 23 Dec, 2011 1 commit
  26. 19 Dec, 2011 1 commit
    • Simon Peyton Jones's avatar
      Tidy up pretty-printing for variables · c492e50b
      Simon Peyton Jones authored
      We already have a class OutputableBndr; this patch adds
      methods pprInfixOcc and pprPrefixOcc, so that we can get
      rid of the hideous hack (the old) Outputable.pprHsVar.
      
      The hack was exposed by Trac #5657, which is thereby fixed.
      c492e50b
  27. 05 Dec, 2011 1 commit