1. 24 Oct, 2011 1 commit
  2. 21 Oct, 2011 1 commit
  3. 23 Sep, 2011 1 commit
    • Simon Peyton Jones's avatar
      Implement GHCi command :kind! which normalises its type · f3c7ed72
      Simon Peyton Jones authored
         type family F a
         type instance F Int = Bool
         type instance F Bool = Char
      In GHCi
         *TF> :kind (F Int, F Bool)
         (F Int, F Bool) :: *
         *TF> :kind! F Int
         (F Int, F Bool) :: *
         = (Bool, Char)
      We could call it ":normalise" but it seemed quite nice to have an
      eager version of :kind
  4. 21 Sep, 2011 2 commits
    • Simon Marlow's avatar
    • Simon Marlow's avatar
      Add support for all top-level declarations to GHCi · 3db75724
      Simon Marlow authored
        This is work mostly done by Daniel Winograd-Cort during his
        internship at MSR Cambridge, with some further refactoring by me.
      This commit adds support to GHCi for most top-level declarations that
      can be used in Haskell source files.  Class, data, newtype, type,
      instance are all supported, as are Type Family-related declarations.
      The current set of declarations are shown by :show bindings.  As with
      variable bindings, entities bound by newer declarations shadow earlier
      Tests are in testsuite/tests/ghci/scripts/ghci039--ghci054.
      Documentation to follow.
  5. 09 Sep, 2011 1 commit
    • batterseapower's avatar
      Implement associated type defaults · de8c8d68
      batterseapower authored
      Basically, now you can write:
        class Cls a where
          type Typ a
          type Typ a = Just a
      And now if an instance does not specify an explicit associated type
      instance, one will be generated afresh based on that default. So for
      example this instance:
        instance Cls Int where
      Will be equivalent to this one:
        instance Cls Int where
          type Typ Int = Just Int
  6. 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)
  7. 02 Sep, 2011 1 commit
    • Simon Peyton Jones's avatar
      Export a tiny bit more info with AbstractTyCon (fixes #5424) · de9b85fa
      Simon Peyton Jones authored
      When we compile -O0 we put type constructors in the interface file
      without their data constructors -- an AbstractTyCon.  But in a
      client module, to give good pattern-match exhaustiveness warnings,
      we need to know the difference between a data type and a newtype.
      (The latter can be coerced to another type, but a data type can't.)
      See Note [Pruning dead case alternatives] in Unify.
      Because we weren't conveying this info, we were getting bogus
      warnings about inexhaustive patterm matches with GADTs, and
      (confusingly) these warnings woudl come and go depending on
      whether you were compiling with -O.
      This patch makes AbstractTyCon carry a flag indicating whether
      the type constructor is "distinct"; two distinct TyCons cannot
      be coerced into eachother (except by unsafeCoerce, in which case
      all bets are off).
      HEADS UP: interface file format changes slightly, so you need
      to make clean.
  8. 22 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      A batch of changes related to the handling of binders in instance decls · f76f0d0e
      Simon Peyton Jones authored
      The issue is that in
          instnace C T where
            data S = ...
            f = ...
      neither S nor f is really a binder; they are *occurrences*.  Moreover
      Haskell dictates that these particular occurrences are disambiguated
      by looking at the class whose instance they occur in.
      Some of this was not handled right for associated types.  And
      RnNames.getLocalNonValBinders was a bit messhy; this patch tidies it
      (And thenM is finally gone from RnSource.)
  9. 16 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      Major improvement to pattern bindings · 49dbe605
      Simon Peyton Jones authored
      This patch makes a number of related improvements
      a) Implements the Haskell Prime semantics for pattern bindings
         (Trac #2357).  That is, a pattern binding p = e is typed
         just as if it had been written
              t = e
              f = case t of p -> f
              g = case t of p -> g
              ... etc ...
         where f,g are the variables bound by p. In paricular it's
         ok to say
            (f,g) = (\x -> x, \y -> True)
         and f and g will get propertly inferred types
            f :: a -> a
            g :: a -> Int
      b) Eliminates the MonoPatBinds flag altogether.  (For the moment
         it is deprecated and has no effect.)  Pattern bindings are now
         generalised as per (a).  Fixes Trac #2187 and #4940, in the
         way the users wanted!
      c) Improves the OutsideIn algorithm generalisation decision.
         Given a definition without a type signature (implying "infer
         the type"), the published algorithm rule is this:
            - generalise *top-level* functions, and
            - do not generalise *nested* functions
         The new rule is
            - generalise a binding whose free variables have
              Guaranteed Closed Types
            - do not generalise other bindings
         Generally, a top-level let-bound function has a Guaranteed
         Closed Type, and so does a nested function whose free vaiables
         are top-level functions, and so on. (However a top-level
         function that is bitten by the Monomorphism Restriction does
         not have a GCT.)
           f x = let { foo y = y } in ...
         Here 'foo' has no free variables, so it is generalised despite
         being nested.
      d) When inferring a type f :: ty for a definition f = e, check that
         the compiler would accept f :: ty as a type signature for that
         same definition.  The type is rejected precisely when the type
         is ambiguous.
            class Wob a b where
              to :: a -> b
              from :: b -> a
            foo x = [x, to (from x)]
         GHC 7.0 would infer the ambiguous type
            foo :: forall a b. Wob a b => b -> [b]
         but that type would give an error whenever it is called; and
         GHC 7.0 would reject that signature if given by the
         programmer.  The new type checker rejects it up front.
         Similarly, with the advent of type families, ambiguous types are
         easy to write by mistake.  See Trac #1897 and linked tickets for
         many examples.  Eg
            type family F a :: *
            f ::: F a -> Int
            f x = 3
         This is rejected because (F a ~ F b) does not imply a~b.  Previously
         GHC would *infer* the above type for f, but was unable to check it.
         Now even the inferred type is rejected -- correctly.
      The main implemenation mechanism is to generalise the abe_wrap
      field of ABExport (in HsBinds), from [TyVar] to HsWrapper. This
      beautiful generalisation turned out to make everything work nicely
      with minimal programming effort.  All the work was fiddling around
      the edges; the core change was easy!
  10. 03 Aug, 2011 1 commit
  11. 02 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      Refactor the imports of InteractiveContext · 35d213ab
      Simon Peyton Jones authored
      Instead of two fields
         ic_toplev_scope :: [Module]
         ic_imports      :: [ImportDecl RdrName]
      we now just have one
         ic_imports :: [InteractiveImport]
      with the auxiliary data type
         data InteractiveImport
          = IIDecl (ImportDecl RdrName)  -- Bring the exports of a particular module
          	   	       		   -- (filtered by an import decl) into scope
          | IIModule Module	-- Bring into scope the entire top-level envt of
          	     		-- of this module, including the things imported
      			-- into it.
      This makes lots of code less confusing.  No change in behaviour.
      It's preparatory to fixing Trac #5147.
      While I was at I also
        * Cleaned up the handling of the "implicit" Prelude import
          by adding a ideclImplicit field to ImportDecl.  This
          significantly reduces plumbing in the handling of
          the implicit Prelude import
        * Used record notation consistently for ImportDecl
  12. 27 Jul, 2011 1 commit
  13. 20 Jul, 2011 1 commit
    • Simon Marlow's avatar
      Fix #481: use a safe recompilation check when Template Haskell is · 48bc81ad
      Simon Marlow authored
      being used.
      We now track whether a module used any TH splices in the ModIface (and
      at compile time in the TcGblEnv and ModGuts).  If a module used TH
      splices last time it was compiled, then we ignore the results of the
      normal recompilation check and recompile anyway, *unless* the module
      is "stable" - that is, none of its dependencies (direct or indirect)
      have changed.  The stability test is pretty important - otherwise ghc
      --make would always recompile TH modules even if nothing at all had
      changed, but it does require some extra plumbing to get this
      information from GhcMake into HscMain.
      test in driver/recomp009
  14. 30 Jun, 2011 2 commits
  15. 04 Jun, 2011 1 commit
  16. 03 Jun, 2011 1 commit
  17. 26 May, 2011 1 commit
  18. 20 May, 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
      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.
  20. 02 May, 2011 2 commits
  21. 28 Apr, 2011 1 commit
  22. 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
  23. 12 Apr, 2011 1 commit
  24. 03 Apr, 2011 2 commits
    • Ian Lynagh's avatar
      Fix build · 99d5f763
      Ian Lynagh authored
    • batterseapower's avatar
      Use tcRnImports rather than rnImports with GHCi "import" statement: fixes #4832 · 3deca8f4
      batterseapower authored
      The bug here was that just using rnImports does not ensure that any dependent
      orphan modules are loaded, so instances declared by such modules will not be
      usable from the GHCi command line after an "import".
      This did not affect the :m syntax because it takes a different code path and
      uses getModuleExports directly, which contains its own calls to the orphan-module
      loading stuff.
  25. 20 Feb, 2011 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Added a VECTORISE pragma · f2aaae97
      chak@cse.unsw.edu.au. authored
      - Added a pragma {-# VECTORISE var = exp #-} that prevents
        the vectoriser from vectorising the definition of 'var'.
        Instead it uses the binding '$v_var = exp' to vectorise
        'var'.  The vectoriser checks that the Core type of 'exp'
        matches the vectorised Core type of 'var'.  (It would be
        quite complicated to perform that check in the type checker
        as the vectorisation of a type needs the state of the VM
      - Added parts of a related VECTORISE SCALAR pragma
      - Documented -ddump-vect
      - Added -ddump-vt-trace
      - Some clean up
  26. 26 Jan, 2011 1 commit
  27. 12 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Major refactoring of the type inference engine · 27310213
      simonpj@microsoft.com authored
      This patch embodies many, many changes to the contraint solver, which
      make it simpler, more robust, and more beautiful.  But it has taken
      me ages to get right. The forcing issue was some obscure programs
      involving recursive dictionaries, but these eventually led to a
      massive refactoring sweep.
      Main changes are:
       * No more "frozen errors" in the monad.  Instead "insoluble
         constraints" are now part of the WantedConstraints type.
       * The WantedConstraint type is a product of bags, instead of (as
         before) a bag of sums.  This eliminates a good deal of tagging and
       * This same WantedConstraints data type is used
           - As the way that constraints are gathered
           - As a field of an implication constraint
           - As both argument and result of solveWanted
           - As the argument to reportUnsolved
       * We do not generate any evidence for Derived constraints. They are
         purely there to allow "impovement" by unifying unification
       * In consequence, nothing is ever *rewritten* by a Derived
         constraint.  This removes, by construction, all the horrible
         potential recursive-dictionary loops that were making us tear our
         hair out.  No more isGoodRecEv search either. Hurrah!
       * We add the superclass Derived constraints during canonicalisation,
         after checking for duplicates.  So fewer superclass constraints
         are generated than before.
       * Skolem tc-tyvars no longer carry SkolemInfo.  Instead, the
         SkolemInfo lives in the GivenLoc of the Implication, where it
         can be tidied, zonked, and substituted nicely.  This alone is
         a major improvement.
       * Tidying is improved, so that we tend to get t1, t2, t3, rather
         than t1, t11, t111, etc
         Moreover, unification variables are always printed with a digit
         (thus a0, a1, etc), so that plain 'a' is available for a skolem
         arising from a type signature etc. In this way,
           (a) We quietly say which variables are unification variables,
               for those who know and care
           (b) Types tend to get printed as the user expects.  If he writes
                   f :: a -> a
                   f = ...blah...
               then types involving 'a' get printed with 'a', rather than
               some tidied variant.
       * There are significant improvements in error messages, notably
         in the "Cannot deduce X from Y" messages.
  28. 10 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Do dependency analysis when kind-checking type declarations · 6ea06bbf
      simonpj@microsoft.com authored
      This patch fixes Trac #4875.  The main point is to do dependency
      analysis on type and class declarations, and kind-check them in
      dependency order, so as to improve error messages.
      This patch means that a few programs that would typecheck before won't
      typecheck any more; but before we were (naughtily) going beyond
      Haskell 98 without any language-extension flags, and Trac #4875
      convinces me that doing so is a Bad Idea.
      Here's an example that won't typecheck any more
             data T a b = MkT (a b)
             type F k = T k Maybe
      If you look at T on its own you'd default 'a' to kind *->*;
      and then kind-checking would fail on F.
      But GHC currently accepts this program beause it looks at
      the *occurrences* of T.
  29. 22 Dec, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Tidy up rebindable syntax for MDo · ba05282d
      simonpj@microsoft.com authored
      For a long time an 'mdo' expression has had a SyntaxTable
      attached to it.  However, we're busy deprecating SyntaxTables
      in favour of rebindable syntax attached to individual Stmts,
      and MDoExpr was totally inconsistent with DoExpr in this
      This patch tidies it all up.  Now there's no SyntaxTable on
      MDoExpr, and 'modo' is generally handled much more like 'do'.
      There is resulting small change in behaviour: now MonadFix is
      required only if you actually *use* recursion in mdo. This
      seems consistent with the implicit dependency analysis that
      is done for mdo.
      Still to do:
        * Deal with #4148 (this patch is on the way)
        * Get rid of the last remaining SyntaxTable on HsCmdTop
  30. 08 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Beautiful new approach to the skolem-escape check and untouchable · debb7b80
      simonpj@microsoft.com authored
      Instead of keeping a *set* of untouchable variables in each
      implication contraints, we keep a *range* of uniques for the
      *touchable* variables of an implication.  This are precisely
      the ones we would call the "existentials" if we were French.
      It turns out that the code is more efficient, and vastly easier
      to get right, than the set-based approach.
      Fixes Trac #4355 among others
  31. 07 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Implement auto-specialisation of imported Ids · 92267aa2
      simonpj@microsoft.com authored
      This big-ish patch arranges that if an Id 'f' is 
        * Type-class overloaded 
             f :: Ord a => [a] -> [a]
        * Defined with an INLINABLE pragma
             {-# INLINABLE f #-}
        * Exported from its defining module 'D'
      then in any module 'U' that imports D
      1. Any call of 'f' at a fixed type will generate 
         (a) a specialised version of f in U
         (b) a RULE that rewrites unspecialised calls to the
             specialised on
        e.g. if the call is (f Int dOrdInt xs) then the 
        specialiser will generate
           $sfInt :: [Int] -> [Int]
           $sfInt = <code for f, imported from D, specialised>
           {-# RULE forall d.  f Int d = $sfInt #-}
      2. In addition, you can give an explicit {-# SPECIALISE -#}
         pragma for the imported Id
           {-# SPECIALISE f :: [Bool] -> [Bool] #-}
         This too generates a local specialised definition, 
         and the corresponding RULE 
      The new RULES are exported from module 'U', so that any module
      importing U will see the specialised versions of 'f', and will
      not re-specialise them.
      There's a flag -fwarn-auto-orphan that warns you if the auto-generated
      RULES are orphan rules. It's not in -Wall, mainly to avoid lots of
      error messages with existing packages.
      Main implementation changes
       - A new flag on a CoreRule to say if it was auto-generated.
         This is persisted across interface files, so there's a small
         change in interface file format.
       - Quite a bit of fiddling with plumbing, to get the 
         {-# SPECIALISE #-} pragmas for imported Ids.  In particular, a
         new field tgc_imp_specs in TcGblEnv, to keep the specialise
         pragmas for imported Ids between the typechecker and the desugarer.
       - Some new code (although surprisingly little) in Specialise,
         to deal with calls of imported Ids
  32. 19 Sep, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Add a flag -fwarn-missing-local-sigs, and improve -fwarn-mising-signatures · e8fa04cf
      simonpj@microsoft.com authored
      The new flag prints out a warning if you have a local,
      polymorphic binding that lacks a type signature. It's meant
      to help with the transition to the new typechecker, which
      discourages local let-generalisation.
      At the same time I moved the missing-signature code to TcHsSyn,
      where it takes place as part of zonking.  That way the 
      types are reported after all typechecking is complete,
      thereby fixing Trac #3696.  (It's even more important for
      local bindings, which is why I made the change.)
  33. 13 Sep, 2010 1 commit
  34. 31 Jul, 2010 1 commit
  35. 07 Jul, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #4127 (and hence #4173) · f87cc9cf
      simonpj@microsoft.com authored
      The change involves a little refactoring, so that the default
      method Ids are brought into scope earlier, before the value
      declarations are compiled.  (Since a value decl may contain
      an instance decl in a quote.)
      See Note [Default method Ids and Template Haskell] in
  36. 25 Jun, 2010 1 commit