1. 29 Dec, 2006 1 commit
  2. 28 Dec, 2006 1 commit
  3. 10 Nov, 2006 1 commit
  4. 11 Oct, 2006 1 commit
  5. 05 Oct, 2006 1 commit
  6. 20 Sep, 2006 2 commits
    • chak@cse.unsw.edu.au.'s avatar
      Extend TyCons and DataCons to represent data instance decls · 80c89b80
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:05:18 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Extend TyCons and DataCons to represent data instance decls
        Fri Aug 18 19:11:37 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Extend TyCons and DataCons to represent data instance decls
          - This is a faily involved patch, but it is not entirely complete:
            + The data con wrapper code for instance data cons needs to apply the
              coercions (which we still have to generate).
            + There are still bugs, but it doesn't seem to affect the compilation of
              code that doesn't use type families.
          ** WARNING: Yet another change of the iface format.  **
          **          Recompile everything.                    **
    • chak@cse.unsw.edu.au.'s avatar
      Massive patch for the first months work adding System FC to GHC #34 · 3e83dfb2
      chak@cse.unsw.edu.au. authored
      Fri Sep 15 18:56:58 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Massive patch for the first months work adding System FC to GHC #34
        Fri Aug  4 18:20:57 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Massive patch for the first months work adding System FC to GHC #34
          Broken up massive patch -=chak
          Original log message:  
          This is (sadly) all done in one patch to avoid Darcs bugs.
          It's not complete work... more FC stuff to come.  A compiler
          using just this patch will fail dismally.
  7. 18 Aug, 2006 1 commit
  8. 14 Aug, 2006 1 commit
  9. 10 Aug, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Egregious bug in tcLHsConResTy · e656c6e3
      simonpj@microsoft.com authored
      This terrible bug in tcLHsConTy is pretty much guaranteed to show up
      on an program involving a GADT with more than one type parameter.
      This bug isn't present in the STABLE branch.
      Manuel: it is *not* necesary to merge this patch into the FC branch; 
      just ignore it.
  10. 08 Aug, 2006 1 commit
  11. 26 Jul, 2006 1 commit
  12. 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.
  13. 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) = ... 
         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.
  14. 14 Oct, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-10-14 11:22:41 by simonpj] · 36436bc6
      simonpj authored
      Add record syntax for GADTs
      Atrijus Tang wanted to add record syntax for GADTs and existential
      types, so he and I worked on it a bit at ICFP.  This commit is the
      result.  Now you can say
       data T a where
        T1 { x :: a }           	 :: T [a]
        T2 { x :: a, y :: Int } 	 :: T [a]
        forall b. Show b =>
       	T3 { naughty :: b, ok :: Int } :: T Int
        T4 :: Eq a => a -> b -> T (a,b)
      Here the constructors are declared using record syntax.
      Still to come after this commit:
        - User manual documentation
        - More regression tests
        - Some missing cases in the parser (e.g. T3 won't parse)
      Autrijus is going to do these.
      Here's a quick summary of the rules.  (Atrijus is going to write
      proper documentation shortly.)
      Defnition: a 'vanilla' constructor has a type of the form
      	forall a1..an. t1 -> ... -> tm -> T a1 ... an
      No existentials, no context, nothing.  A constructor declared with
      Haskell-98 syntax is vanilla by construction.  A constructor declared
      with GADT-style syntax is vanilla iff its type looks like the above.
      (In the latter case, the order of the type variables does not matter.)
      * You can mix record syntax and non-record syntax in a single decl
      * All constructors that share a common field 'x' must have the
        same result type (T [a] in the example).
      * You can use field names without restriction in record construction
        and record pattern matching.
      * Record *update* only works for data types that only have 'vanilla'
      * Consider the field 'naughty', which uses a type variable that does
        not appear in the result type ('b' in the example).  You can use the
        field 'naughty' in pattern matching and construction, but NO
        SELECTOR function is generated for 'naughty'.  [An attempt to use
        'naughty' as a selector function will elicit a helpful error
      * Data types declared in GADT syntax cannot have a context. So this
      is illegal:
      	data (Monad m) => T a where
      * Constructors in GADT syntax can have a context (t.g. T3, T4 above)
        and that context is stored in the constructor and made available
        when the constructor is pattern-matched on.  WARNING: not competely
        implemented yet, but that's the plan.
      Implementation notes
      - Data constructors (even vanilla ones) no longer share the type
        variables of their parent type constructor.
      - HsDecls.ConDecl has changed quite a bit
      - TyCons don't record the field labels and type any more (doesn't
        make sense for existential fields)
      - GlobalIdDetails records which selectors are 'naughty', and hence
        don't have real code.
  15. 10 Aug, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-08-10 11:05:06 by simonpj] · e3a4d6c3
      simonpj authored
      It turned out that doing all binding dependency analysis in the typechecker
      meant that the renamer's unused-binding error messages got worse.  So now
      I've put the first dep anal back into the renamer, while the second (which
      is specific to type checking) remains in the type checker.
      I've also made the pretty printer sort the decls back into source order
      before printing them (except with -dppr-debug).
      Fixes rn041.
  16. 19 Jul, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-07-19 16:44:50 by simonpj] · a7ecdf96
      simonpj authored
      WARNING: this is a big commit.  You might want 
      	to wait a few days before updating, in case I've 
      	broken something.
      	However, if any of the changes are what you wanted,
      	please check it out and test!
      This commit does three main things:
      1. A re-organisation of the way that GHC handles bindings in HsSyn.
         This has been a bit of a mess for quite a while.  The key new
         types are
      	-- Bindings for a let or where clause
      	data HsLocalBinds id
      	  = HsValBinds (HsValBinds id)
      	  | HsIPBinds  (HsIPBinds id)
      	  | EmptyLocalBinds
      	-- Value bindings (not implicit parameters)
      	data HsValBinds id
      	  = ValBindsIn  -- Before typechecking
      		(LHsBinds id) [LSig id]	-- Not dependency analysed
      					-- Recursive by default
      	  | ValBindsOut	-- After typechecking
      		[(RecFlag, LHsBinds id)]-- Dependency analysed
      2. Implement Mark Jones's idea of increasing polymoprhism
         by using type signatures to cut the strongly-connected components
         of a recursive group.  As a consequence, GHC no longer insists
         on the contexts of the type signatures of a recursive group
         being identical.
         This drove a significant change: the renamer no longer does dependency
         analysis.  Instead, it attaches a free-variable set to each binding,
         so that the type checker can do the dep anal.  Reason: the typechecker
         needs to do *two* analyses:
      	one to find the true mutually-recursive groups
      		(which we need so we can build the right CoreSyn)
      	one to find the groups in which to typecheck, taking
      		account of type signatures
      3. Implement non-ground SPECIALISE pragmas, as promised, and as
         requested by Remi and Ross.  Certainly, this should fix the 
         current problem with GHC, namely that if you have
      	g :: Eq a => a -> b -> b
         then you can now specialise thus
      	SPECIALISE g :: Int -> b -> b
          (This didn't use to work.)
         However, it goes further than that.  For example:
      	f :: (Eq a, Ix b) => a -> b -> b
         then you can make a partial specialisation
      	SPECIALISE f :: (Eq a) => a -> Int -> Int
          In principle, you can specialise f to *any* type that is
          "less polymorphic" (in the sense of subsumption) than f's 
          actual type.  Such as
      	SPECIALISE f :: Eq a => [a] -> Int -> Int
          But I haven't tested that.
          I implemented this by doing the specialisation in the typechecker
          and desugarer, rather than leaving around the strange SpecPragmaIds,
          for the specialiser to find.  Indeed, SpecPragmaIds have vanished 
          altogether (hooray).
          Pragmas in general are handled more tidily.  There's a new
          data type HsBinds.Prag, which lives in an AbsBinds, and carries
          pragma info from the typechecker to the desugarer.
      Smaller things
      - The loop in the renamer goes via RnExpr, instead of RnSource.
        (That makes it more like the type checker.)
      - I fixed the thing that was causing 'check_tc' warnings to be 
  17. 05 May, 2005 1 commit
  18. 29 Apr, 2005 1 commit
  19. 28 Apr, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-04-28 10:09:41 by simonpj] · dd313897
      simonpj authored
      This big commit does several things at once (aeroplane hacking)
      which change the format of interface files.  
      	So you'll need to recompile your libraries!
      1. The "stupid theta" of a newtype declaration
      Retain the "stupid theta" in a newtype declaration.
      For some reason this was being discarded, and putting it
      back in meant changing TyCon and IfaceSyn slightly.
      2. Overlap flags travel with the instance
      Arrange that the ability to support overlap and incoherence
      is a property of the *instance declaration* rather than the
      module that imports the instance decl.  This allows a library
      writer to define overlapping instance decls without the
      library client having to know.  
      The implementation is that in an Instance we store the
      overlap flag, and preseve that across interface files
      3. Nuke the "instnce pool" and "rule pool"
      A major tidy-up and simplification of the way that instances
      and rules are sucked in from interface files.  Up till now
      an instance decl has been held in a "pool" until its "gates" 
      (a set of Names) are in play, when the instance is typechecked
      and added to the InstEnv in the ExternalPackageState.  
      This is complicated and error-prone; it's easy to suck in 
      too few (and miss an instance) or too many (and thereby be
      forced to suck in its type constructors, etc).
      Now, as we load an instance from an interface files, we 
      put it straight in the InstEnv... but the Instance we put in
      the InstEnv has some Names (the "rough-match" names) that 
      can be used on lookup to say "this Instance can't match".
      The detailed dfun is only read lazily, and the rough-match
      thing meansn it is'nt poked on until it has a chance of
      being needed.
      This simply continues the successful idea for Ids, whereby
      they are loaded straightaway into the TypeEnv, but their
      TyThing is a lazy thunk, not poked on until the thing is looked
      Just the same idea applies to Rules.
      On the way, I made CoreRule and Instance into full-blown records
      with lots of info, with the same kind of key status as TyCon or 
      DataCon or Class.  And got rid of IdCoreRule altogether.   
      It's all much more solid and uniform, but it meant touching
      a *lot* of modules.
      4. Allow instance decls in hs-boot files
      Allowing instance decls in hs-boot files is jolly useful, becuase
      in a big mutually-recursive bunch of data types, you want to give
      the instances with the data type declarations.  To achieve this
      * The hs-boot file makes a provisional name for the dict-fun, something
        like $fx9.
      * When checking the "mother module", we check that the instance
        declarations line up (by type) and generate bindings for the 
        boot dfuns, such as
      	$fx9 = $f2
        where $f2 is the dfun generated by the mother module
      * In doing this I decided that it's cleaner to have DFunIds get their
        final External Name at birth.  To do that they need a stable OccName,
        so I have an integer-valued dfun-name-supply in the TcM monad.
        That keeps it simple.
      This feature is hardly tested yet.
      5. Tidy up tidying, and Iface file generation
      main/TidyPgm now has two entry points:
        simpleTidyPgm is for hi-boot files, when typechecking only
        (not yet implemented), and potentially when compiling without -O.
        It ignores the bindings, and generates a nice small TypeEnv.
        optTidyPgm is the normal case: compiling with -O.  It generates a
        TypeEnv rich in IdInfo
      MkIface.mkIface now only generates a ModIface.  A separate
      procedure, MkIface.writeIfaceFile, writes the file out to disk.
  20. 16 Apr, 2005 1 commit
  21. 31 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-31 10:16:33 by simonmar] · 853e20a3
      simonmar authored
      Tweaks to get the GHC sources through Haddock.  Doesn't quite work
      yet, because Haddock complains about the recursive modules.  Haddock
      needs to understand SOURCE imports (it can probably just ignore them
      as a first attempt).
  22. 11 Mar, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-03-11 10:36:35 by simonpj] · 75649bcc
      simonpj authored
       	Fix a "class used as a type" crash
      	Merge to STABLE
      Thanks to Shae for finding this one.  tcfail134 tests.
  23. 27 Jan, 2005 2 commits
    • simonpj's avatar
      [project @ 2005-01-27 11:51:56 by simonpj] · 56f5bc18
      simonpj authored
      Import trimming
    • 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
      	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.
  24. 26 Jan, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-01-26 16:10:02 by simonpj] · 8254dcf1
      simonpj authored
      	Fixup to hoistForAllTys
      * hoistForAllTys moves from TcHsType to TcType
      hoistForAllTys was being too vigorous and breaking up type synonyms,
      even when it was entirely unnecessary to do so.
      Not only does this make error messsages less good, but it's actually
      wrong for Haskell 98, because we are meant to report under-applied
      type synonyms, and that check doesn't happen until after hoistForAllTys.
      This led to a very obscure bug, immortalised as tcfail129.
  25. 24 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-24 11:02:39 by simonpj] · 0ee11df0
      simonpj authored
      Further wibbles to the scoped-tyvar story.
      This commit tidies up the ATyVar in TcTyThing, making it
      	ATyVar Name Type
      instead of the previous misleading
      	ATyVar TyVar Type
      But the main thing is that we must take care with definitions
      like this:
      	type T a = forall b. b -> (a,b)
      	f :: forall c. T c
      	f = ...
      Here, we want only 'c' to scope over the RHS of f.  The renamer ensures
      that... but we must also take care that we freshly instantiate the 
      expanded type signature (forall c b. b -> (c,b)) before checking f's RHS,
      so that we don't get false sharing between uses of T.
  26. 22 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-22 16:58:34 by simonpj] · 20e39e0e
      simonpj authored
      	     Add more scoped type variables
      Now the top-level forall'd variables of a type signature scope
      over the right hand side of that function.
      	f :: a -> a
      	f x = ....
      The type variable 'a' is in scope in the RHS, and in f's patterns.
      It's implied by -fglasgow-exts, but can also be switched off independently
      using -fscoped-type-variables (and the -fno variant)
  27. 21 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-21 12:22:22 by simonpj] · 79a8b87c
      simonpj authored
           Improve handling of lexically scoped type variables
      If we have
      	f :: T a -> a
      	f (x :: T b) = ...
      then the lexically scoped variable 'b' should refer to the rigid
      type variable 'a', without any intervening wobbliness.  Previously
      the in-scope type variables were always mutable TyVars, which were
      instantatiated to point to the type they were bound to; but since
      the advent of GADTs the intervening mutable type variable is a bad
        * In the type environment, ATyVar now carries a type
        * The call to refineTyVars in tc_pat on SigPatIn
          finds the types by matching
        * Then tcExtendTyVarEnv3 extends the type envt appropriately
      Rater a lot of huff and puff, but it's quite natural for ATyVar
      to contain a type.
      Various other small nomenclature changes along the way.
  28. 03 Dec, 2004 1 commit
  29. 30 Sep, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-09-30 10:35:15 by simonpj] · 23f40f0e
      simonpj authored
      	Add Generalised Algebraic Data Types
      This rather big commit adds support for GADTs.  For example,
          data Term a where
       	  Lit :: Int -> Term Int
      	  App :: Term (a->b) -> Term a -> Term b
      	  If  :: Term Bool -> Term a -> Term a
          eval :: Term a -> a
          eval (Lit i) = i
          eval (App a b) = eval a (eval b)
          eval (If p q r) | eval p    = eval q
          		    | otherwise = eval r
      Lots and lots of of related changes throughout the compiler to make
      this fit nicely.
      One important change, only loosely related to GADTs, is that skolem
      constants in the typechecker are genuinely immutable and constant, so
      we often get better error messages from the type checker.  See
      There's a new module types/Unify.lhs, which has purely-functional
      unification and matching for Type. This is used both in the typechecker
      (for type refinement of GADTs) and in Core Lint (also for type refinement).
  30. 06 Apr, 2004 1 commit
  31. 05 Apr, 2004 1 commit
  32. 02 Apr, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-04-02 16:46:57 by simonpj] · 40888e1d
      simonpj authored
      Extend the "newtype deriving" feature a little bit more
      (at the request of Wolfgang Jeltsch)
      Here's the example:
          class C a b
          instance C [a] Char
          newtype T = T Char deriving( C [a] )
      Perfectly sensible, and no reason it should not work.
      Fixing this required me to generalise the abstract syntax of
      a 'deriving' item, hence the non-local effects.
  33. 12 Jan, 2004 1 commit
  34. 30 Dec, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-12-30 16:29:17 by simonpj] · f714e6b6
      simonpj authored
              Re-do kind inference (again)
         [WARNING: interface file binary representation has
         (as usual) changed slightly; recompile your libraries!]
      Inspired by the lambda-cube, for some time GHC has used
      	type Kind = Type
      That is, kinds were represented by the same data type as types.
      But GHC also supports unboxed types and unboxed tuples, and these
      complicate the kind system by requiring a sub-kind relationship.
      Notably, an unboxed tuple is acceptable as the *result* of a
      function but not as an *argument*.  So we have the following setup:
      		/ \
      	       /   \
      	      ??   (#)
      	     /  \
                  *   #
      where	*    [LiftedTypeKind]   means a lifted type
      	#    [UnliftedTypeKind] means an unlifted type
      	(#)  [UbxTupleKind]     means unboxed tuple
      	??   [ArgTypeKind]      is the lub of *,#
      	?    [OpenTypeKind]	means any type at all
      In particular:
        error :: forall a:?. String -> a
        (->)  :: ?? -> ? -> *
        (\(x::t) -> ...)	Here t::?? (i.e. not unboxed tuple)
      All this has beome rather difficult to accommodate with Kind=Type, so this
      commit splits the two.
        * Kind is a distinct type, defined in types/Kind.lhs
        * IfaceType.IfaceKind disappears: we just re-use Kind.Kind
        * TcUnify.unifyKind is a distinct unifier for kinds
        * TyCon no longer needs KindCon and SuperKindCon variants
        * TcUnify.zapExpectedType takes an expected Kind now, so that
          in TcPat.tcMonoPatBndr we can express that the bound variable
          must have an argTypeKind (??).
      The big change is really that kind inference is much more systematic and
      well behaved.  In particular, a kind variable can unify only with a
      "simple kind", which is built from * and (->).  This deals neatly
      with awkward questions about how we can combine sub-kinding with type
      Lots of small consequential changes, especially to the kind-checking
      plumbing in TcTyClsDecls.  (We played a bit fast and loose before, and
      now we have to be more honest, in particular about how kind inference
      works for type synonyms.  They can have kinds like (* -> #), so
      This cures two long-standing SourceForge bugs
      * 753777 (tcfail115.hs), which used erroneously to pass,
        but crashed in the code generator
            type T a = Int -> (# Int, Int #)
            f :: T a -> T a
            f t = \x -> case t x of r -> r
      * 753780 (tc167.hs), which used erroneously to fail
            f :: (->) Int# Int#
      Still, the result is not entirely satisfactory.  In particular
      * The error message from tcfail115 is pretty obscure
      * SourceForge bug 807249 (Instance match failure on openTypeKind)
        is not fixed.  Alas.
  35. 16 Dec, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-12-16 16:24:55 by simonpj] · cb2be98a
      simonpj authored
      	Towards type splices
      Starts the move to supporting type splices, by making
      HsExpr.HsSplice a separate type of its own, and adding
      HsSpliceTy constructor to HsType.
  36. 10 Dec, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-12-10 14:15:16 by simonmar] · 55042138
      simonmar authored
      Add accurate source location annotations to HsSyn
      Every syntactic entity in HsSyn is now annotated with a SrcSpan, which
      details the exact beginning and end points of that entity in the
      original source file.  All honest compilers should do this, and it was
      about time GHC did the right thing.
      The most obvious benefit is that we now have much more accurate error
      messages; when running GHC inside emacs for example, the cursor will
      jump to the exact location of an error, not just a line somewhere
      nearby.  We haven't put a huge amount of effort into making sure all
      the error messages are accurate yet, so there could be some tweaking
      still needed, although the majority of messages I've seen have been
      Error messages now contain a column number in addition to the line
      number, eg.
         read001.hs:25:10: Variable not in scope: `+#'
      To get the full text span info, use the new option -ferror-spans.  eg.
         read001.hs:25:10-11: Variable not in scope: `+#'
      I'm not sure whether we should do this by default.  Emacs won't
      understand the new error format, for one thing.
      In a more elaborate editor setting (eg. Visual Studio), we can arrange
      to actually highlight the subexpression containing an error.  Eventually
      this information will be used so we can find elements in the abstract
      syntax corresponding to text locations, for performing high-level editor
      functions (eg. "tell me the type of this expression I just highlighted").
      Performance of the compiler doesn't seem to be adversely affected.
      Parsing is still quicker than in 6.0.1, for example.
      This was an excrutiatingly painful change to make: both Simon P.J. and
      myself have been working on it for the last three weeks or so.  The
      basic changes are:
       - a new datatype SrcSpan, which represents a beginning and end position
         in a source file.
       - To reduce the pain as much as possible, we also defined:
            data Located e = L SrcSpan e
       - Every datatype in HsSyn has an equivalent Located version.  eg.
            type LHsExpr id = Located (HsExpr id)
         and pretty much everywhere we used to use HsExpr we now use
         LHsExpr.  Believe me, we thought about this long and hard, and
         all the other options were worse :-)
      Additional changes/cleanups we made at the same time:
        - The abstract syntax for bindings is now less arcane.  MonoBinds
          and HsBinds with their built-in list constructors have gone away,
          replaced by HsBindGroup and HsBind (see HsSyn/HsBinds.lhs).
        - The various HsSyn type synonyms have now gone away (eg. RdrNameHsExpr,
          RenamedHsExpr, and TypecheckedHsExpr are now HsExpr RdrName,
          HsExpr Name, and HsExpr Id respectively).
        - Utilities over HsSyn are now collected in a new module HsUtils.
          More stuff still needs to be moved in here.
        - MachChar now has a real Char instead of an Int.  All GHC versions that
          can compile GHC now support 32-bit Chars, so this was a simplification.
  37. 06 Nov, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-11-06 17:09:50 by simonpj] · 1f5e5580
      simonpj authored
      	Major increment for Template Haskell
      1.  New abstract data type "Name" which appears where String used to be.
          E.g. 	data Exp = VarE Name | ...
      2.  New syntax 'x and ''T, for quoting Names.  It's rather like [| x |]
          and [t| T |] respectively, except that
      	a) it's non-monadic:  'x :: Name
      	b) you get a Name not an Exp or Type
      3.  reify is an ordinary function
      	reify :: Name -> Q Info
          New data type Info which tells what TH knows about Name
      4.  Local variables work properly.  So this works now (crashed before):
      	f x = $( [| x |] )
      5.  THSyntax is split up into three modules:
        Language.Haskell.TH		TH "clients" import this
        Language.Haskell.TH.THSyntax	data type declarations and internal stuff
        Language.Haskell.TH.THLib	Support library code (all re-exported
      				by TH), including smart constructors and
      				pretty printer
      6.  Error reporting and recovery are in (not yet well tested)
      	report :: Bool {- True <=> fatal -} -> String -> Q ()
      	recover :: Q a -> Q a -> Q a
      7.  Can find current module
      	currentModule :: Q String
      Much other cleaning up, needless to say.
  38. 30 Oct, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-10-30 16:01:49 by simonpj] · 57573e7e
      simonpj authored
      This commit does a long-overdue tidy-up
      * Remove PprType (gets rid of one more bunch of hi-boot files)
      * Put pretty-printing for types in TypeRep
      * Make a specialised pretty-printer for Types, rather than
        converting to IfaceTypes and printing those