1. 02 Apr, 2012 2 commits
  2. 30 Mar, 2012 4 commits
  3. 29 Mar, 2012 6 commits
  4. 28 Mar, 2012 3 commits
  5. 22 Mar, 2012 1 commit
  6. 18 Mar, 2012 1 commit
  7. 15 Mar, 2012 1 commit
  8. 14 Mar, 2012 3 commits
    • Simon Peyton Jones's avatar
      Deal with kind variables brought into scope by a kind signature · 431c05b3
      Simon Peyton Jones authored
      This fixes Trac #5937, where a kind variable is mentioned only
      in the kind signature of a GADT
         data SMaybe :: (k -> *) -> Maybe k -> * where ...
      
      The main change is that the tcdKindSig field of TyData and TyFamily
      now has type Maybe (HsBndrSig (LHsKind name)), where the HsBndrSig
      part deals with the kind variables that the signature may bind.
      
      I also removed the now-unused PostTcKind field of UserTyVar and
      KindedTyVar.
      431c05b3
    • Simon Peyton Jones's avatar
      Deal with kind variables brought into scope by a kind signature · 54eb0301
      Simon Peyton Jones authored
      This fixes Trac #5937, where a kind variable is mentioned only
      in the kind signature of a GADT
         data SMaybe :: (k -> *) -> Maybe k -> * where ...
      
      The main change is that the tcdKindSig field of TyData and TyFamily
      now has type Maybe (HsBndrSig (LHsKind name)), where the HsBndrSig
      part deals with the kind variables that the signature may bind.
      
      I also removed the now-unused PostTcKind field of UserTyVar and
      KindedTyVar.
      54eb0301
    • Joachim Breitner's avatar
      Allow Any as an argument type to foreign prim functions · e29001c9
      Joachim Breitner authored
      Real primops can take boxed arguments, and the Cmm code will receive the
      pointer to the object on the Haskell heap, e.g. for unpackClosure#. To
      be able to implement such a function in a "foreign prim" call, this
      needs to be allowed as well. By only allowing Any here (instead of
      arbitrary types), it is clearer that the function will not receive the
      value in any marshalled form, but just the raw pointer. Haskell code
      using such functions are likely to use unsafeCoerce# to turn a haskell
      value into a value of type Any.
      e29001c9
  9. 09 Mar, 2012 3 commits
  10. 04 Mar, 2012 1 commit
    • Simon Peyton Jones's avatar
      Tidy up the handling of kind generalisation · e0c849e0
      Simon Peyton Jones authored
      In particular in forall abc. <blah> we should
      kind generalise over <blah> as well as over the
      kinds of a,b,c.
      
      This fixes bug (in Trac #5862, caught by Lint) in the handling of
        data SMaybe a where
           SNothing :: SMaybe 'Nothing
      where I didn't get a sufficiently general kind. And it's simpler.
      e0c849e0
  11. 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
  12. 01 Mar, 2012 1 commit
    • Simon Marlow's avatar
      GHCi: add :seti, for options that apply only at the prompt (#3217) · 2e55760b
      Simon Marlow authored
      GHCi now maintains two DynFlags: one that applies to whole modules
      loaded with :load, and one that applies to things typed at the prompt
      (expressions, statements, declarations, commands).
      
        The :set command modifies both DynFlags.  This is for backwards
        compatibility: users won't notice any difference.
      
        The :seti command applies only to the interactive DynFlags.
      
      Additionally, I made a few changes to ":set" (with no arguments):
      
        * Now it only prints out options that differ from the defaults,
          rather than the whole list.
      
        * There is a new variant, ":set -a" to print out all options (the
          old behaviour).
      
        * It also prints out language options.
      
      e.g.
      
      Prelude> :set
      options currently set: none.
      base language is: Haskell2010
      with the following modifiers:
        -XNoDatatypeContexts
        -XNondecreasingIndentation
      GHCi-specific dynamic flag settings:
      other dynamic, non-language, flag settings:
        -fimplicit-import-qualified
      warning settings:
      
      ":seti" (with no arguments) does the same as ":set", but for the
      interactive options.  It also has the "-a" option.
      
      The interactive DynFlags are kept in the InteractiveContext, and
      copied into the HscEnv at the appropriate points (all in HscMain).
      
      There are some new GHC API operations:
      
      -- | Set the 'DynFlags' used to evaluate interactive expressions.
      setInteractiveDynFlags :: GhcMonad m => DynFlags -> m ()
      
      -- | Get the 'DynFlags' used to evaluate interactive expressions.
      getInteractiveDynFlags :: GhcMonad m => m DynFlags
      
      -- | Sets the program 'DynFlags'.
      setProgramDynFlags :: GhcMonad m => DynFlags -> m [PackageId]
      
      -- | Returns the program 'DynFlags'.
      getProgramDynFlags :: GhcMonad m => m DynFlags
      
      Note I have not completed the whole of the plan outlined in #3217 yet:
      when in the context of a loaded module we don't take the interactive
      DynFlags from that module.  That needs some more refactoring and
      thinking about, because we'll need to save and restore the original
      interactive DynFlags.
      
      This solves the immediate problem that people are having with the new
      flag checking in 7.4.1, because now it is possible to set language
      options in ~/.ghci that do not affect loaded modules and thereby cause
      recompilation.
      2e55760b
  13. 26 Feb, 2012 2 commits
  14. 22 Feb, 2012 1 commit
  15. 21 Feb, 2012 1 commit
  16. 17 Feb, 2012 6 commits
  17. 16 Feb, 2012 3 commits