1. 16 Feb, 2012 1 commit
  2. 07 Dec, 2011 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Add new primtypes 'ArrayArray#' and 'MutableArrayArray#' · 021a0dd2
      chak@cse.unsw.edu.au. authored
      The primitive array types, such as 'ByteArray#', have kind #, but are represented by pointers. They are boxed, but unpointed types (i.e., they cannot be 'undefined').
      
      The two categories of array types —[Mutable]Array# and [Mutable]ByteArray#— are containers for unboxed (and unpointed) as well as for boxed and pointed types.  So far, we lacked support for containers for boxed, unpointed types (i.e., containers for the primitive arrays themselves).  This is what the new primtypes provide.
      
      Containers for boxed, unpointed types are crucial for the efficient implementation of scattered nested arrays, which are central to the new DPH backend library dph-lifted-vseg.  Without such containers, we cannot eliminate all unboxing from the inner loops of traversals processing scattered nested arrays.
      021a0dd2
  3. 21 Nov, 2011 1 commit
    • dreixel's avatar
      Rename ? to OpenKind and ?? to ArgKind · 18c7aea0
      dreixel authored
      The previous names were not informative at all, and now we have
      named kinds like Constraint and datatype promotion to kind, so
      we might as well name these too.
      
      I tried to update some comments to the new names, but certainly
      many references to the old names remain.
      18c7aea0
  4. 16 Nov, 2011 2 commits
  5. 11 Nov, 2011 1 commit
    • dreixel's avatar
      New kind-polymorphic core · 09015be8
      dreixel authored
      This big patch implements a kind-polymorphic core for GHC. The current
      implementation focuses on making sure that all kind-monomorphic programs still
      work in the new core; it is not yet guaranteed that kind-polymorphic programs
      (using the new -XPolyKinds flag) will work.
      
      For more information, see http://haskell.org/haskellwiki/GHC/Kinds
      09015be8
  6. 04 Nov, 2011 1 commit
  7. 22 Oct, 2011 1 commit
  8. 03 Oct, 2011 2 commits
    • Ian Lynagh's avatar
      Handle HValues slightly nicer · aff9d690
      Ian Lynagh authored
      We now have addrToAny# rather than addrToHValue#, and both addrToAny#
      and mkApUpd0# return "Any" rather than "a". This makes it a little
      easier to see what's going on, and fixes a warning in ByteCodeLink.
      aff9d690
    • Ian Lynagh's avatar
      Fix typo · 25f8f25a
      Ian Lynagh authored
      25f8f25a
  9. 27 Sep, 2011 1 commit
  10. 06 Sep, 2011 2 commits
    • 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
    • batterseapower's avatar
      6bad38a4
  11. 26 May, 2011 1 commit
    • Simon Peyton Jones's avatar
      Treat the (~) type constructor a bit specially · 3afdf90d
      Simon Peyton Jones authored
      when kind-checking in Core Lint.  It's unusual
      becuase it is poly-kinded; for example
      
      	(~) Int a
      and	(~) Maybe b
      
      are both ok.  We don't want the full generality
      of kind polymorphism (yet anyway) so these changes
      in effect give (~) its own private kinding rule.
      
      It won't work right if (~) appears un-saturated,
      and Lint now checks for that too.
      3afdf90d
  12. 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
  13. 03 Sep, 2010 1 commit
  14. 27 Jul, 2010 1 commit
  15. 01 Mar, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Tidy up AnyTyCon stuff · 6d0b77ef
      simonpj@microsoft.com authored
      If we find ourselves making up an AnyTyCon of kind '??', say, 
      then default it to liftedTypeKind.  And similarly for any sub-kind
      of LiftedTypeKind.
      
      This is just a tidy-up.
      6d0b77ef
  16. 25 Feb, 2010 1 commit
  17. 04 Jan, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Substantial improvements to coercion optimisation · b06d623b
      simonpj@microsoft.com authored
      The main purpose of this patch is to add a bunch of new rules
      to the coercion optimiser.  They are documented in the (revised)
      Appendix of the System FC paper.  
      
      Some code has moved about:
      
      - OptCoercion is now a separate module, mainly because it
        now uses tcMatchTy, which is defined in Unify, so OptCoercion
        must live higehr up in the hierarchy
      
      - Functions that manipulate Kinds has moved from 
        Type.lhs to Coercion.lhs.  Reason: the function typeKind
        now needs to call coercionKind.  And in any case, a Kind is
        a flavour of Type, so it builds on top of Type; indeed Coercions
        and Kinds are both flavours of Type.
      
        This change required fiddling with a number of imports, hence
        the one-line changes to otherwise-unrelated modules
      
      - The representation of CoTyCons in TyCon has changed.   Instead of
        an extensional representation (a kind checker) there is now an
        intensional representation (namely TyCon.CoTyConDesc).  This was
        needed for one of the new coercion optimisations.
      b06d623b
  18. 15 Oct, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #959: a long-standing bug in instantiating otherwise-unbound type variables · 388e3356
      simonpj@microsoft.com authored
          
         DO NOT MERGE TO GHC 6.12 branch
         (Reason: interface file format change.)
      
      The typechecker needs to instantiate otherwise-unconstraint type variables to
      an appropriately-kinded constant type, but we didn't have a supply of 
      arbitrarily-kinded tycons for this purpose.  Now we do.
      
      The details are described in Note [Any types] in TysPrim.  The
      fundamental change is that there is a new sort of TyCon, namely
      AnyTyCon, defined in TyCon.
      
      Ter's a small change to interface-file binary format, because the new
      AnyTyCons have to be serialised.
      
      I tided up the handling of uniques a bit too, so that mkUnique is not
      exported, so that we can see all the different name spaces in one module.
      388e3356
  19. 10 Aug, 2009 1 commit
  20. 24 Jul, 2009 1 commit
  21. 06 Jul, 2009 1 commit
  22. 31 Jul, 2008 1 commit
  23. 13 Apr, 2008 1 commit
  24. 12 Apr, 2008 1 commit
  25. 10 Apr, 2008 1 commit
    • chevalier@alum.wellesley.edu's avatar
      Another round of External Core fixes · 4c6a3f78
      chevalier@alum.wellesley.edu authored
      With this patch, GHC should now be printing External Core in a format
      that a stand-alone program can parse and typecheck. Major bug fixes:
      
      - The printer now handles qualified/unqualified declarations correctly
         (particularly data constructor declarations)
      - It prints newtype declarations with enough information to
        typecheck code that uses the induced coercions (this required a
      syntax change)
      - It expands type synonyms correctly
       
      Documentation and external tool patches will follow.
      4c6a3f78
  26. 29 Mar, 2008 1 commit
  27. 19 Nov, 2007 1 commit
  28. 04 Sep, 2007 1 commit
  29. 03 Sep, 2007 1 commit
  30. 01 Sep, 2007 1 commit
  31. 11 May, 2007 1 commit
  32. 18 Oct, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Add the primitive type Any, and use it for Dynamics · c128930d
      simonpj@microsoft.com authored
      GHC's code generator can only enter a closure if it's guaranteed
      not to be a function.  In the Dynamic module, we were using the 
      type (forall a.a) as the type to which the dynamic type was unsafely
      cast:
      	type Obj = forall a.a
      
      Gut alas this polytype was sometimes instantiated to (), something 
      like this (it only bit when profiling was enabled)
      	let y::() = dyn ()
      	in (y `cast` ..) p q
      As a result, an ASSERT in ClosureInfo fired (hooray).
      
      I've tided this up by making a new, primitive, lifted type Any, and
      arranging that Dynamic uses Any, thus:
      	type Obj = ANy
      
      While I was at it, I also arranged that when the type checker instantiates 
      un-constrained type variables, it now instantiates them to Any, not ()
      	e.g.  length Any []
      
      [There remains a Horrible Hack when we want Any-like things at arbitrary 
      kinds.  This essentially never happens, but see comments with 
      TysPrim.mkAnyPrimTyCon.]
      
      Anyway, this fixes Trac #905
      c128930d
  33. 11 Oct, 2006 2 commits
    • Simon Marlow's avatar
      Module header tidyup, phase 1 · 49c98d14
      Simon Marlow authored
      This patch is a start on removing import lists and generally tidying
      up the top of each module.  In addition to removing import lists:
      
         - Change DATA.IOREF -> Data.IORef etc.
         - Change List -> Data.List etc.
         - Remove $Id$
         - Update copyrights
         - Re-order imports to put non-GHC imports last
         - Remove some unused and duplicate imports
      49c98d14
    • 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
  34. 20 Sep, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      newtype fixes, coercions for non-recursive newtypes now optional · c94408e5
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 14:24:27 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * newtype fixes, coercions for non-recursive newtypes now optional
        Sat Aug  5 21:19:58 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * newtype fixes, coercions for non-recursive newtypes now optional
          Fri Jul  7 06:11:48 EDT 2006  kevind@bu.edu
      c94408e5
  35. 18 Sep, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Remove argument variance info of tycons · 3e0b6b25
      chak@cse.unsw.edu.au. authored
      Fri Aug 11 13:53:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Remove argument variance info of tycons
        - Following SPJ's suggestion, this patch removes the variance information from
          type constructors.  This information was computed, but never used.
        
        ** WARNING: This patch changes the format of interface files **
        **          You will need to rebuild from scratch.           **
      3e0b6b25
  36. 23 Jun, 2006 1 commit