1. 20 Sep, 2006 3 commits
    • chak@cse.unsw.edu.au.'s avatar
      Complete the evidence generation for GADTs · 15cb792d
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 14:43:22 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Complete the evidence generation for GADTs
        Sat Aug  5 21:39:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Complete the evidence generation for GADTs
          Thu Jul 13 17:18:07 EDT 2006  simonpj@microsoft.com
            This patch completes FC evidence generation for GADTs.
            It doesn't work properly yet, because part of the compiler thinks
            	(t1 :=: t2) => t3
            is represented with FunTy/PredTy, while the rest thinks it's represented
            using ForAllTy.  Once that's done things should start to work.
    • chak@cse.unsw.edu.au.'s avatar
      some bug-fixes, newtype deriving might work now · 44ba24dc
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 14:33:01 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * some bug-fixes, newtype deriving might work now
        Sat Aug  5 21:29:28 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * some bug-fixes, newtype deriving might work now
          Tue Jul 11 12:16:13 EDT 2006  kevind@bu.edu
    • 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.
  2. 26 Jul, 2006 1 commit
  3. 18 Sep, 2006 1 commit
  4. 11 Aug, 2006 1 commit
  5. 07 Aug, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Add -fextended-default-rules and -fmono-pat-binds · 6e0c3f50
      simonpj@microsoft.com authored
      Add -fextended-deafult-rules (in response to Don Stewart's message below),
      and document them.
      Also doucument -fmono-pat-binds/-fno-mono-pat-binds, which has been in 
      GHC a few weeks now. 
      (The two are in one patch because the diffs were so close together
      that Darcs combined them.)
      From: Donald Bruce Stewart [mailto:dons@cse.unsw.edu.au] 
      Sent: 07 August 2006 10:52
      While we're thinking about defaulting, I have a question..
      ghci uses an extended defaulting system, to allow things like:
              Prelude> reverse []
      to work, and to have the right instance of Show found. The manual says:
          "..it is tiresome for the user to have to specify the type, so GHCi extends
          Haskell's type-defaulting rules (Section 4.3.4 of the Haskell 98 Report
          (Revised)) as follows. If the expression yields a set of type constraints
          that are all from standard classes (Num, Eq etc.), and at least one is
          either a numeric class or the Show, Eq, or Ord class, GHCi will try to use
          one of the default types, just as described in the Report. The standard
          defaulting rules require that one of the classes is numeric; the difference
          here is that defaulting is also triggered at least one is Show, Eq, or Ord."
      Currently, there is no way to get at this "extended" defaulting for compiled
      modules. However, I have a use case for in fact doing this.
      With runtime evaluated Haskell, embedding 'interpreters' (over hs-plugins) is
      easy. lambdabot, for example, implements a sandboxed haskell eval system. But
      it doesn't have access to the defaulting mechanism of ghci, so we have:
          dons:: > reverse []
          lambdabot:: Add a type signature
          dons:: > reverse [] :: [()]
          lambdabot:: []
      Which is annoying -- newbies wonder why they have to add these extra
      constraints to get a Show instance.
      I'm wondering, since the extended defaulting mechanisms are already
      implemented, could they be made available to compiled modules as well,
      perhaps using a flag, -fextended-defaulting? 
  6. 27 Jul, 2006 1 commit
  7. 26 Jun, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Improve consistency checking for derived instances · 7f0ce617
      simonpj@microsoft.com authored
      This patch arranges that derived instances use the same instance-decl
      checking code as user-defined instances.  That gives greater consistency
      in error messages.
      Furthermore, the error description if this consistency check fails is now
      much more explicit.  For example, drvfail003 now says
           Variable occurs more often in a constraint than in the instance head
             in the constraint: Show (v (v a))
           (Use -fallow-undecidable-instances to permit this)
           In the derived instance
             instance (Show (v (v a))) => Show (Square_ v w a)
  8. 19 May, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Improved RULE lhs typechecking; less dictionary sharing · 5a8a219c
      simonpj@microsoft.com authored
      See long comment with Simplify.tcSimplifyRuleLhs.
      Here's the key example:
        RULE "g"  forall x y z. g (x == y) (y == z) = ...
      Here, the two dictionaries are *identical*, but we do NOT WANT to
      generate the rule
      RULE	forall x::a, y::a, z::a, d1::Eq a
      	  f ((==) d1 x y) ((>) d1 y z) = ...
      Instead we want
      RULE	forall x::a, y::a, z::a, d1::Eq a, d2:Eq a
      	  f ((==) d1 x y) ((>) d2 y z) = ...
  9. 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.
  10. 23 Feb, 2006 1 commit
  11. 13 Feb, 2006 1 commit
  12. 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.
  13. 18 Jan, 2006 1 commit
  14. 16 Nov, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-11-16 12:55:58 by simonpj] · cdea9949
      simonpj authored
      Two significant changes to the representation of types
      1. Change the representation of type synonyms
          Up to now, type synonym applications have been held in
          *both* expanded *and* un-expanded form.  Unfortunately, this
          has exponential (!) behaviour when type synonyms are deeply
          nested.  E.g.
      	    type P a b = (a,b)
      	    f :: P a (P b (P c (P d e)))
          This showed up in a program of Joel Reymont, now immortalised
          as typecheck/should_compile/syn-perf.hs
          So now synonyms are held as ordinary TyConApps, and expanded
          only on demand.  
          SynNote has disappeared altogether, so the only remaining TyNote
          is a FTVNote.  I'm not sure if it's even useful.
      2. Eta-reduce newtypes
          See the Note [Newtype eta] in TyCon.lhs
          If we have 
      	    newtype T a b = MkT (S a b)
          then, in Core land, we would like S = T, even though the application
          of T is then not saturated. This commit eta-reduces T's RHS, and
          keeps that inside the TyCon (in nt_etad_rhs).  Result is that 
          coreEqType can be simpler, and has less need of expanding newtypes.
  15. 12 Jul, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-07-12 14:50:10 by simonpj] · dc442241
      simonpj authored
      An earlier commit, liberalising the defaulting rules for ghci,
      messed up the handling of defaulting at the top level.  This
      commit fixes it.
      The current story is that if there's an ambiguous top-level
      multi-parameter constraint (C a b), then a,b won't be defaulted,
      regardless of how a,b are used otherwise.  A type variable is
      defaulted only if it's constrained by single-parameter type classes,
      even in the more-liberal GHCi.
      tcfail142 tests this case.
  16. 11 Jul, 2005 1 commit
  17. 10 Jun, 2005 1 commit
  18. 20 May, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-05-20 11:32:03 by simonpj] · 40d3a06b
      simonpj authored
      Liberalise the defaulting rules for GHCi
      		Merge to STABLE?
      The H98 defaulting rules are these.  Group constraints of the form (C v),
      for some particular type variable v. Then default v if
      a) v appears only in this group (no implicit params or D [v])
      b) at least one of the C's is numeric
      c) all the C's are standard
      GHCi changed rules (b) to
      (b') at least one of the C's is numeric, or Eq,Ord,Show
      This commit further liberalises GHCi to change (c):
      (c') any of the C's are standard
      Otherwise the existence of a non-standard class (e.g. Random) is enough
      to kill defaulting altogether.
  19. 19 May, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-05-19 11:15:40 by simonpj] · 4a587049
      simonpj authored
      Tune up the reporting of unused imports
      		Merge to STABLE
      	(I think the earlier change made it across)
      	(PS: the commit also does some trimming of
      	redundant imports.  If they don't merge, just
      	discard them.)
      My earlier fixes to the reporting of unused imports still missed
      some obscure cases, some of which are now fixed by this commit.
      I had to make the import-provenance data type yet richer, but in
      fact it has more sharing now, so it may be cheaper on space.
      There's still one infelicity. Consider
      		import M( x )
      		imoprt N( x )
      where the same underlying 'x' is involved in both cases.  Currently we
      don't report a redundant import, because dropping either import would
      change the qualified names in scope (M.x, N.x). But if the qualified
      names aren't used, the import is indeed redundant. Sadly we don't know
      that, because we only know what Names are used.  Left for the future!
      There's a comment in RnNames.warnDuplicateImports
      This commit also trims quite a few redundant imports disovered
      by the new setup.
  20. 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.
  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. 18 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-18 13:37:27 by simonmar] · d1c1b7d0
      simonmar authored
      Flags cleanup.
      Basically the purpose of this commit is to move more of the compiler's
      global state into DynFlags, which is moving in the direction we need
      to go for the GHC API which can have multiple active sessions
      supported by a single GHC instance.
      $ grep 'global_var' */*hs | wc -l
      $ grep 'global_var' */*hs | wc -l
      Well, it's an improvement.  Most of what's left won't really affect
      our ability to host multiple sessions.
      Lots of static flags have become dynamic flags (yay!).  Notably lots
      of flags that we used to think of as "driver" flags, like -I and -L,
      are now dynamic.  The most notable static flags left behind are the
      "way" flags, eg. -prof.  It would be nice to fix this, but it isn't
      On the way, lots of cleanup has happened.  Everything related to
      static and dynamic flags lives in StaticFlags and DynFlags
      respectively, and they share a common command-line parser library in
      CmdLineParser.  The flags related to modes (--makde, --interactive
      etc.) are now private to the front end: in fact private to Main
      itself, for now.
  23. 09 Mar, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-03-09 14:26:56 by simonpj] · aca101dd
      simonpj authored
      Fix the superclass translation for instance decls
      			Merge to STABLE
      There is a long-standing difficulty whereby it's surprisingly easy 
      to accidentally generate an entirely-bogus recursive dictionary when 
      generating the definitions for the superclasses of an instance decl.
      The problem arises because the default story is that whenever we
      add a constraint to our pile of solved constraints, we automatically
      add all its superclasses.  But that is simply wrong when we are trying
      to generate superclasses. 
      Solution: do no auto-superclass addition when solving the superclass
      constraints of an instance declaration.  I think should fix it once and
      for all.  
      	tcrun021, tcrun033 are test cases
      tcrun033 showed up the bug; thanks to Simon Foster and Ralf Laemmel.
  24. 25 Feb, 2005 4 commits
    • simonpj's avatar
      [project @ 2005-02-25 14:15:53 by simonpj] · 9ced2b59
      simonpj authored
      	Improve ambiguity reporting in TcSimplify
      	Merge to STABLE
      The test for ambiguity in tcSimplifyTop caused us to say thing like
      	No instance for (Show c)
      which is a bit confusing -- and in fact exposed a separate buglet in
      the fix-reporting code.
      This commit deals with the origial problem.  tcfail133 tests it.
    • simonpj's avatar
      [project @ 2005-02-25 13:57:05 by simonpj] · 57983d16
      simonpj authored
      Wibble to last commit
    • simonpj's avatar
      [project @ 2005-02-25 13:54:41 by simonpj] · a42ead96
      simonpj authored
      Prevent a crash; reason the situation arises in the first place is still unclear
    • simonpj's avatar
      [project @ 2005-02-25 13:06:31 by simonpj] · 8e67f550
      simonpj authored
      Type signatures are no longer instantiated with skolem constants
      	Merge to STABLE
        p :: a
        q :: b
        (p,q,r) = (r,r,p)
      Here, 'a' and 'b' end up being the same, because they are both bound
      to the type for 'r', which is just a meta type variable.  So 'a' and 'b'
      can't be skolems.
      Sigh.  This commit goes back to an earlier way of doing things, by
      arranging that type signatures get instantiated with *meta* type
      variables; then at the end we must check that they have not been
      unified with types, nor with each other.
      This is a real bore.  I had to do quite a bit of related fiddling around
      to make error messages come out right.  Improved one or two.
      Also a small unrelated fix to make
      	:i (:+)
      print with parens in ghci.  Sorry this got mixed up in the same commit.
  25. 09 Feb, 2005 1 commit
  26. 04 Feb, 2005 2 commits
    • simonpj's avatar
      [project @ 2005-02-04 17:36:47 by simonpj] · b8802cd2
      simonpj authored
      Wibble to message
    • simonpj's avatar
      [project @ 2005-02-04 17:24:01 by simonpj] · c36a2f9b
      simonpj authored
      	Report top-level implicit parameter errors more nicely
          module Main where
      	main = let ?x = 5 in print foo
      	foo = woggle 3
      	woggle :: (?x :: Int) => Int -> Int
      	woggle y = ?x + y
      GHC's current rules say that 'foo' is monomorphic, so we get
      	foo :: Int
      but we also get an unbound top-level constraint (?x::Int).  GHC 6.2 emits a
      message like:
           Unbound implicit parameter (?x::Int)
           arising from use of `woggle' at ...
      because we don't have a top-level binding form for implicit parameters.
      So it's stupid for 'foo' to be monomorphic.
      This commit improves matters by giving a much nicer error message:
           Implicit parameters escape from the monomorphic top-level binding(s) of `foo':
             ?x::Int arising from use of `woggle' at tcfail130.hs:10:6-11
           Probably fix: add type signatures for the top-level binding(s)
           When generalising the type(s) for `foo'
  27. 06 Jan, 2005 2 commits
  28. 21 Dec, 2004 1 commit
  29. 20 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-20 17:16:24 by simonpj] · c45a0ac5
      simonpj authored
      	Deal properly with dual-renaming
      When comparing types and terms, and during matching, we are faced
      	\x.e1	~   \y.e2
      There are many pitfalls here, and GHC has never done the job properly.
      Now, at last it does, using a new abstraction VarEnv.RnEnv2.  See
      comments there for how it works.
      There are lots of consequential changes to use the new stuff, especially
      	types/Type (type comparison), 
      	types/Unify (matching on types)
      	coreSyn/CoreUtils (equality on expressions), 
      	specialise/Rules (matching).
      I'm not 100% certain of that I've covered all the bases, so let me
      know if something unexpected happens after you update.  Maybe wait until
      a nightly build has worked ok first!
  30. 06 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-06 10:51:36 by simonpj] · f6f3819f
      simonpj authored
      	Bug in loop detection in TcSimplify
      The type-class context simplifier has been able to 
      build recursive dictionaries for some time: co-induction.
      That is, you can build a proof for constraint C by assuming
      that C holds when proving the preconditions of C.
      You need to be in -fallow-undecidable-instances land to 
      make use of this: see comments with [RECURSIVE DICTIONARIES]
      in TcSimplify.lhs.
      Anyway, this is all fine, but I'd implemented it wrong!  You need
      to be very careful with superclasses, or you can make a bogus
      loop by mistake.  This commit fixes it; tests LoopOfTheDay{1,2,3}
      will test it (thanks Ralf Laemmel).
  31. 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).
  32. 26 Aug, 2004 1 commit
  33. 18 Aug, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-08-18 09:33:03 by simonpj] · 370765b2
      simonpj authored
      		Fix a fundep bug
      Big thank-you to Martin Sulzmann for finding this functional dependency bug.
      The new defn of FunDeps.Equation is:
      	type Equation = (TyVarSet, [(Type, Type)])
      Before it was (TyVarSet, Type, Type), so each pair of types was separately
      quantified (wrong).
      It's important that we have a *list* of pairs of types.  Consider
       	class C a b c | a -> b c where ...
      	instance C Int x x where ...
      Then, given the constraint (C Int Bool v) we should improve v to Bool,
      via the equation ({x}, [(Bool,x), (v,x)])
      This would not happen if the class had looked like
      	class C a b c | a -> b, a -> c
      Test in typecheck/should_compile/tc180