1. 04 Oct, 2013 2 commits
  2. 15 Oct, 2012 1 commit
  3. 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
  4. 26 Jan, 2012 1 commit
  5. 04 Nov, 2011 1 commit
  6. 13 Sep, 2010 1 commit
  7. 10 Feb, 2010 2 commits
    • simonpj@microsoft.com's avatar
      Keep track of explicit kinding in HsTyVarBndr; plus fix Trac #3845 · 836b1e90
      simonpj@microsoft.com authored
      To print HsTypes correctly we should remember whether the Kind on
      a HsTyVarBndr came from type inference, or was put there by the
      user.  See Note [Printing KindedTyVars] in HsTypes.  So instead of
      changing a UserTyVar to a KindedTyVar during kind checking, we
      simply add a PostTcKind to the UserTyVar.
      
      The change was provoked by Trac #3830, although other changes
      mean that #3830 gets a diferent and better error message now.
      So this patch is simply doing the Right Thing for the future.
      
      This patch also fixes Trac #3845, which was caused by a *type splice*
      not remembering the free *term variables* mentioned in it.  Result
      was that we build a 'let' when it should have been 'letrec'.
      Hence a new FreeVars field in HsSpliceTy.
      
      While I was at it, I got rid of HsSpliceTyOut and use a PostTcKind
      on HsSpliceTy instead, just like on the UserTyVar.
      836b1e90
    • simonpj@microsoft.com's avatar
      Several TH/quasiquote changes · 6f8ff0bb
      simonpj@microsoft.com authored
      a) Added quasi-quote forms for
            declarations
            types
         e.g.   f :: [$qq| ... |]
      
      b) Allow Template Haskell pattern quotes (but not splices)
         e.g.  f x = [p| Int -> $x |]
      
      c) Improve pretty-printing for HsPat to remove superfluous
         parens.  (This isn't TH related really, but it affects
         some of the same code.)
      
      
      A consequence of (a) is that when gathering and grouping declarations
      in RnSource.findSplice, we must expand quasiquotes as we do so.
      Otherwise it's all fairly straightforward.  I did a little bit of
      refactoring in TcSplice.
      
      User-manual changes still to come.
      6f8ff0bb
  8. 27 May, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Template Haskell: allow type splices · 389cca21
      simonpj@microsoft.com authored
      At last!  Trac #1476 and #3177
      
      This patch extends Template Haskell by allowing splices in
      types.  For example
      
        f :: Int -> $(burble 3)
      
      A type splice should work anywhere a type is expected.  This feature
      has been long requested, and quite a while ago I'd re-engineered the
      type checker to make it easier, but had never got around to finishing
      the job.  With luck, this does it.
      
      There's a ToDo in the HsSpliceTy case of RnTypes.rnHsType, where I
      am not dealing properly with the used variables; but that's awaiting
      the refactoring of the way we report unused names.
      
      
      389cca21
  9. 30 Oct, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Add (a) CoreM monad, (b) new Annotations feature · 9bcd95ba
      simonpj@microsoft.com authored
      This patch, written by Max Bolingbroke,  does two things
      
      1.  It adds a new CoreM monad (defined in simplCore/CoreMonad),
          which is used as the top-level monad for all the Core-to-Core
          transformations (starting at SimplCore).  It supports
             * I/O (for debug printing)
             * Unique supply
             * Statistics gathering
             * Access to the HscEnv, RuleBase, Annotations, Module
          The patch therefore refactors the top "skin" of every Core-to-Core
          pass, but does not change their functionality.
      
      2.  It adds a completely new facility to GHC: Core "annotations".
          The idea is that you can say
             {#- ANN foo (Just "Hello") #-}
          which adds the annotation (Just "Hello") to the top level function
          foo.  These annotations can be looked up in any Core-to-Core pass,
          and are persisted into interface files.  (Hence a Core-to-Core pass
          can also query the annotations of imported things.)  Furthermore,
          a Core-to-Core pass can add new annotations (eg strictness info)
          of its own, which can be queried by importing modules.
      
      The design of the annotation system is somewhat in flux.  It's
      designed to work with the (upcoming) dynamic plug-ins mechanism,
      but is meanwhile independently useful.
      
      Do not merge to 6.10!  
      9bcd95ba
  10. 18 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Add quasi-quotation, courtesy of Geoffrey Mainland · f3399c44
      simonpj@microsoft.com authored
      This patch adds quasi-quotation, as described in
        "Nice to be Quoted: Quasiquoting for Haskell"
      	(Geoffrey Mainland, Haskell Workshop 2007)
      Implemented by Geoffrey and polished by Simon.
      
      Overview
      ~~~~~~~~
      The syntax for quasiquotation is very similar to the existing
      Template haskell syntax:
      	[$q| stuff |]
      where 'q' is the "quoter".  This syntax differs from the paper, by using
      a '$' rather than ':', to avoid clashing with parallel array comprehensions.
       
      The "quoter" is a value of type Language.Haskell.TH.Quote.QuasiQuoter, which
      contains two functions for quoting expressions and patterns, respectively.
       
           quote = Language.Haskell.TH.Quote.QuasiQuoter quoteExp quotePat
       
           quoteExp :: String -> Language.Haskell.TH.ExpQ
           quotePat :: String -> Language.Haskell.TH.PatQ
      
      TEXT is passed unmodified to the quoter. The context of the
      quasiquotation statement determines which of the two quoters is
      called: if the quasiquotation occurs in an expression context,
      quoteExp is called, and if it occurs in a pattern context, quotePat
      is called.
      
      The result of running the quoter on its arguments is spliced into
      the program using Template Haskell's existing mechanisms for
      splicing in code. Note that although Template Haskell does not
      support pattern brackets, with this patch binding occurrences of
      variables in patterns are supported. Quoters must also obey the same
      stage restrictions as Template Haskell; in particular, in this
      example quote may not be defined in the module where it is used as a
      quasiquoter, but must be imported from another module.
      
      Points to notice
      ~~~~~~~~~~~~~~~~
      * The whole thing is enabled with the flag -XQuasiQuotes
      
      * There is an accompanying patch to the template-haskell library. This
        involves one interface change:
      	currentModule :: Q String
        is replaced by
      	location :: Q Loc
        where Loc is a data type defined in TH.Syntax thus:
            data Loc
              = Loc { loc_filename :: String
      	      , loc_package  :: String
      	      , loc_module   :: String
      	      , loc_start    :: CharPos
      	      , loc_end      :: CharPos }
      
            type CharPos = (Int, Int)	-- Line and character position
       
        So you get a lot more info from 'location' than from 'currentModule'.
        The location you get is the location of the splice.
        
        This works in Template Haskell too of course, and lets a TH program
        generate much better error messages.
      
      * There's also a new module in the template-haskell package called 
        Language.Haskell.TH.Quote, which contains support code for the
        quasi-quoting feature.
      
      * Quasi-quote splices are run *in the renamer* because they can build 
        *patterns* and hence the renamer needs to see the output of running the
        splice.  This involved a bit of rejigging in the renamer, especially
        concerning the reporting of duplicate or shadowed names.
      
        (In fact I found and removed a few calls to checkDupNames in RnSource 
        that are redundant, becuase top-level duplicate decls are handled in
        RnNames.)
      
      
      f3399c44
  11. 21 Mar, 2007 1 commit
  12. 17 Aug, 2006 1 commit
  13. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  14. 25 Jan, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Simon's big boxy-type commit · ac10f840
      simonpj@microsoft.com authored
      This very large commit adds impredicativity to GHC, plus
      numerous other small things.
        
      *** WARNING: I have compiled all the libraries, and
      ***	     a stage-2 compiler, and everything seems
      ***	     fine.  But don't grab this patch if you 
      ***	     can't tolerate a hiccup if something is
      ***	     broken.
        
      The big picture is this:
      
      a) GHC handles impredicative polymorphism, as described in the
         "Boxy types: type inference for higher-rank types and
         impredicativity" paper
      
      b) GHC handles GADTs in the new simplified (and very sligtly less
         epxrssive) way described in the
         "Simple unification-based type inference for GADTs" paper
      
        
      But there are lots of smaller changes, and since it was pre-Darcs
      they are not individually recorded.
        
      Some things to watch out for:
        
      c)   The story on lexically-scoped type variables has changed, as per
           my email.  I append the story below for completeness, but I 
           am still not happy with it, and it may change again.  In particular,
           the new story does not allow a pattern-bound scoped type variable
           to be wobbly, so (\(x::[a]) -> ...) is usually rejected.  This is
           more restrictive than before, and we might loosen up again.
        
      d)   A consequence of adding impredicativity is that GHC is a bit less
           gung ho about converting automatically between
        	(ty1 -> forall a. ty2)    and    (forall a. ty1 -> ty2)
           In particular, you may need to eta-expand some functions to make
           typechecking work again.
         
           Furthermore, functions are now invariant in their argument types,
           rather than being contravariant.  Again, the main consequence is
           that you may occasionally need to eta-expand function arguments when
           using higher-rank polymorphism.
        
      
      Please test, and let me know of any hiccups
      
      
      Scoped type variables in GHC
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      	January 2006
      
      0) Terminology.
         
         A *pattern binding* is of the form
      	pat = rhs
      
         A *function binding* is of the form
      	f pat1 .. patn = rhs
      
         A binding of the formm
      	var = rhs
         is treated as a (degenerate) *function binding*.
      
      
         A *declaration type signature* is a separate type signature for a
         let-bound or where-bound variable:
      	f :: Int -> Int
      
         A *pattern type signature* is a signature in a pattern: 
      	\(x::a) -> x
      	f (x::a) = x
      
         A *result type signature* is a signature on the result of a
         function definition:
      	f :: forall a. [a] -> a
      	head (x:xs) :: a = x
      
         The form
      	x :: a = rhs
         is treated as a (degnerate) function binding with a result
         type signature, not as a pattern binding.
      
      1) The main invariants:
      
           A) A lexically-scoped type variable always names a (rigid)
       	type variable (not an arbitrary type).  THIS IS A CHANGE.
              Previously, a scoped type variable named an arbitrary *type*.
      
           B) A type signature always describes a rigid type (since
      	its free (scoped) type variables name rigid type variables).
      	This is also a change, a consequence of (A).
      
           C) Distinct lexically-scoped type variables name distinct
      	rigid type variables.  This choice is open; 
      
      2) Scoping
      
      2(a) If a declaration type signature has an explicit forall, those type
         variables are brought into scope in the right hand side of the 
         corresponding binding (plus, for function bindings, the patterns on
         the LHS).  
      	f :: forall a. a -> [a]
      	f (x::a) = [x :: a, x]
         Both occurences of 'a' in the second line are bound by 
         the 'forall a' in the first line
      
         A declaration type signature *without* an explicit top-level forall
         is implicitly quantified over all the type variables that are
         mentioned in the type but not already in scope.  GHC's current
         rule is that this implicit quantification does *not* bring into scope
         any new scoped type variables.
      	f :: a -> a
      	f x = ...('a' is not in scope here)...
         This gives compatibility with Haskell 98
      
      2(b) A pattern type signature implicitly brings into scope any type
         variables mentioned in the type that are not already into scope.
         These are called *pattern-bound type variables*.
      	g :: a -> a -> [a]
      	g (x::a) (y::a) = [y :: a, x]
         The pattern type signature (x::a) brings 'a' into scope.
         The 'a' in the pattern (y::a) is bound, as is the occurrence on 
         the RHS.  
      
         A pattern type siganture is the only way you can bring existentials 
         into scope.
      	data T where
      	  MkT :: forall a. a -> (a->Int) -> T
      
      	f x = case x of
      		MkT (x::a) f -> f (x::a)
      
      2a) QUESTION
      	class C a where
      	  op :: forall b. b->a->a
      
      	instance C (T p q) where
      	  op = <rhs>
          Clearly p,q are in scope in <rhs>, but is 'b'?  Not at the moment.
          Nor can you add a type signature for op in the instance decl.
          You'd have to say this:
      	instance C (T p q) where
      	  op = let op' :: forall b. ...
      	           op' = <rhs>
      	       in op'
      
      3) A pattern-bound type variable is allowed only if the pattern's
         expected type is rigid.  Otherwise we don't know exactly *which*
         skolem the scoped type variable should be bound to, and that means
         we can't do GADT refinement.  This is invariant (A), and it is a 
         big change from the current situation.
      
      	f (x::a) = x	-- NO; pattern type is wobbly
      	
      	g1 :: b -> b
      	g1 (x::b) = x	-- YES, because the pattern type is rigid
      
      	g2 :: b -> b
      	g2 (x::c) = x	-- YES, same reason
      
      	h :: forall b. b -> b
      	h (x::b) = x	-- YES, but the inner b is bound
      
      	k :: forall b. b -> b
      	k (x::c) = x	-- NO, it can't be both b and c
      
      3a) You cannot give different names for the same type variable in the same scope
          (Invariant (C)):
      
      	f1 :: p -> p -> p		-- NO; because 'a' and 'b' would be
      	f1 (x::a) (y::b) = (x::a)	--     bound to the same type variable
      
      	f2 :: p -> p -> p		-- OK; 'a' is bound to the type variable
      	f2 (x::a) (y::a) = (x::a)	--     over which f2 is quantified
      					-- NB: 'p' is not lexically scoped
      
      	f3 :: forall p. p -> p -> p	-- NO: 'p' is now scoped, and is bound to
      	f3 (x::a) (y::a) = (x::a)	--     to the same type varialble as 'a'
      
      	f4 :: forall p. p -> p -> p	-- OK: 'p' is now scoped, and its occurences
      	f4 (x::p) (y::p) = (x::p)	--     in the patterns are bound by the forall
      
      
      3b) You can give a different name to the same type variable in different
          disjoint scopes, just as you can (if you want) give diferent names to 
          the same value parameter
      
      	g :: a -> Bool -> Maybe a
      	g (x::p) True  = Just x  :: Maybe p
      	g (y::q) False = Nothing :: Maybe q
      
      3c) Scoped type variables respect alpha renaming. For example, 
          function f2 from (3a) above could also be written:
      	f2' :: p -> p -> p
      	f2' (x::b) (y::b) = x::b
         where the scoped type variable is called 'b' instead of 'a'.
      
      
      4) Result type signatures obey the same rules as pattern types signatures.
         In particular, they can bind a type variable only if the result type is rigid
      
      	f x :: a = x	-- NO
      
      	g :: b -> b
      	g x :: b = x	-- YES; binds b in rhs
      
      5) A *pattern type signature* in a *pattern binding* cannot bind a 
         scoped type variable
      
      	(x::a, y) = ...		-- Legal only if 'a' is already in scope
      
         Reason: in type checking, the "expected type" of the LHS pattern is
         always wobbly, so we can't bind a rigid type variable.  (The exception
         would be for an existential type variable, but existentials are not
         allowed in pattern bindings either.)
       
         Even this is illegal
      	f :: forall a. a -> a
      	f x = let ((y::b)::a, z) = ... 
      	      in 
         Here it looks as if 'b' might get a rigid binding; but you can't bind
         it to the same skolem as a.
      
      6) Explicitly-forall'd type variables in the *declaration type signature(s)*
         for a *pattern binding* do not scope AT ALL.
      
      	x :: forall a. a->a	  -- NO; the forall a does 
      	Just (x::a->a) = Just id  --     not scope at all
      
      	y :: forall a. a->a
      	Just y = Just (id :: a->a)  -- NO; same reason
      
         THIS IS A CHANGE, but one I bet that very few people will notice.
         Here's why:
      
      	strange :: forall b. (b->b,b->b)
      	strange = (id,id)
      
      	x1 :: forall a. a->a
      	y1 :: forall b. b->b
      	(x1,y1) = strange
      
          This is legal Haskell 98 (modulo the forall). If both 'a' and 'b'
          both scoped over the RHS, they'd get unified and so cannot stand
          for distinct type variables. One could *imagine* allowing this:
         
      	x2 :: forall a. a->a
      	y2 :: forall a. a->a
      	(x2,y2) = strange
      
          using the very same type variable 'a' in both signatures, so that
          a single 'a' scopes over the RHS.  That seems defensible, but odd,
          because though there are two type signatures, they introduce just
          *one* scoped type variable, a.
      
      7) Possible extension.  We might consider allowing
      	\(x :: [ _ ]) -> <expr>
          where "_" is a wild card, to mean "x has type list of something", without
          naming the something.
      ac10f840
  15. 27 Jan, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-01-27 10:44:00 by simonpj] · 508a505e
      simonpj authored
      --------------------------------------------
                Replace hi-boot files with hs-boot files
        	--------------------------------------------
      
      This major commit completely re-organises the way that recursive modules
      are dealt with.
      
        * It should have NO EFFECT if you do not use recursive modules
      
        * It is a BREAKING CHANGE if you do
      
      ====== Warning: .hi-file format has changed, so if you are
      ======		updating into an existing HEAD build, you'll
      ======		need to make clean and re-make
      
      
      The details:  [documentation still to be done]
      
      * Recursive loops are now broken with Foo.hs-boot (or Foo.lhs-boot),
        not Foo.hi-boot
      
      * An hs-boot files is a proper source file.  It is compiled just like
        a regular Haskell source file:
      	ghc Foo.hs		generates Foo.hi, Foo.o
      	ghc Foo.hs-boot		generates Foo.hi-boot, Foo.o-boot
      
      * hs-boot files are precisely a subset of Haskell. In particular:
      	- they have the same import, export, and scoping rules
      	- errors (such as kind errors) in hs-boot files are checked
        You do *not* need to mention the "original" name of something in
        an hs-boot file, any more than you do in any other Haskell module.
      
      * The Foo.hi-boot file generated by compiling Foo.hs-boot is a machine-
        generated interface file, in precisely the same format as Foo.hi
      
      * When compiling Foo.hs, its exports are checked for compatibility with
        Foo.hi-boot (previously generated by compiling Foo.hs-boot)
      
      * The dependency analyser (ghc -M) knows about Foo.hs-boot files, and
        generates appropriate dependencies.  For regular source files it
        generates
      	Foo.o : Foo.hs
      	Foo.o : Baz.hi		-- Foo.hs imports Baz
      	Foo.o : Bog.hi-boot	-- Foo.hs source-imports Bog
      
        For a hs-boot file it generates similar dependencies
      	Bog.o-boot : Bog.hs-boot
      	Bog.o-boot : Nib.hi	-- Bog.hs-boto imports Nib
      
      * ghc -M is also enhanced to use the compilation manager dependency
        chasing, so that
      	ghc -M Main
        will usually do the job.  No need to enumerate all the source files.
      
      * The -c flag is no longer a "compiler mode". It simply means "omit the
        link step", and synonymous with -no-link.
      508a505e