1. 14 Jul, 2008 1 commit
  2. 23 Jun, 2008 1 commit
  3. 06 Jun, 2008 2 commits
    • Ian Lynagh's avatar
      Fix warnings in TcTyClsDecls · 911dcb32
      Ian Lynagh authored
    • simonpj@microsoft.com's avatar
      Fix Trac #2334: validity checking for type families · 1c05d4fb
      simonpj@microsoft.com authored
      When we deal with a family-instance declaration (TcTyClsDecls.tcFamInstDecl)
      we must check the TyCon for validity; for example, that a newtype has exactly
      one field.  That is done all-at-once for normal declarations, and had been
      forgotten altogether for families.
      I also refactored the interface to tcFamInstDecl1 slightly.
      A slightly separate matter: if there's an error in family instances
      (e.g. overlap) we get a confusing error message cascade if we attempt to
      deal with 'deriving' clauses too; this patch bales out earlier in that case.
      Another slightly separate matter: standalone deriving for family 
      instances can legitimately have more specific types, just like normal
      data decls. For example
         data instance F [a] = ...
         deriving instance (Eq a, Eq b) => Eq (F [(a,b)])
      So tcLookupFamInstExact can a bit more forgiving than it was.
  4. 12 Apr, 2008 1 commit
  5. 29 Mar, 2008 1 commit
  6. 06 Mar, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Don't expose the unfolding of dictionary selectors without -O · 74d5597e
      simonpj@microsoft.com authored
      When compiling without -O we were getting code like this
      	f x = case GHC.Base.$f20 of
      		  :DEq eq neq -> eq x x
      But because of the -O the $f20 dictionary is not available, so exposing
      the dictionary selector was useless.  Yet it makes the code bigger!
      Better to get
      	f x = GHC.Base.== GHC.Bsae.$f20 x x
      This patch suppresses the implicit unfolding for dictionary selectors
      when compiling without -O.  We could do the same for other implicit
      Ids, but this will do for now.
      There should be no effect when compiling with -O.  Programs should
      be smaller without -O and may run a tiny bit slower.
  7. 27 Feb, 2008 1 commit
  8. 22 Feb, 2008 1 commit
  9. 17 Jan, 2008 1 commit
  10. 07 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Add -XImpredicativeTypes, and tighten up type-validity checking (cf Trac 2019) · 5e04ae34
      simonpj@microsoft.com authored
      Somehow we didn't have a separate flag for impredicativity; now we do.
      Furthermore, Trac #2019 showed up a missing test for monotypes in data
      constructor return types.  And I realised that we were even allowing
      things like
      	Num (forall a. a) => ...
      which we definitely should not.  
      This patch insists on monotypes in several places where we were (wrongly)
      too liberal before.
      Could be merged to 6.8 but no big deal.
  11. 16 Nov, 2007 2 commits
  12. 02 Nov, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Refactor error recovery slightly · b9a98f56
      simonpj@microsoft.com authored
      Mostly this patch is refacoring, but it also avoids post-tc zonking if
      the typechecker found errors.  This is good because otherwise with
      DEBUG you can get the "Inventing strangely-kinded TyCon" warning.
  13. 10 Oct, 2007 1 commit
  14. 04 Sep, 2007 1 commit
  15. 03 Sep, 2007 1 commit
  16. 01 Sep, 2007 1 commit
  17. 30 Aug, 2007 1 commit
  18. 28 Aug, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Type checking for type synonym families · 5822cb8d
      chak@cse.unsw.edu.au. authored
      This patch introduces type checking for type families of which associated
      type synonyms are a special case. E.g.
              type family Sum n m
              type instance Sum Zero n = n
              type instance Sum (Succ n) m = Succ (Sum n m)
              data Zero       -- empty type
              data Succ n     -- empty type
      In addition we support equational constraints of the form:
              ty1 ~ ty2
      (where ty1 and ty2 are arbitrary tau types) in any context where
      type class constraints are already allowed, e.g.
              data Equals a b where
                      Equals :: a ~ b => Equals a b
      The above two syntactical extensions are disabled by default. Enable
      with the -XTypeFamilies flag.
      For further documentation about the patch, see:
              * the master plan
              * the user-level documentation
      The patch is mostly backwards compatible, except for:
              * Some error messages have been changed slightly.
              * Type checking of GADTs now requires a bit more type declarations:
                not only should the type of a GADT case scrutinee be given, but also
                that of any identifiers used in the branches and the return type.
      Please report any unexpected behavior and incomprehensible error message 
      for existing code.
      Contributors (code and/or ideas):
              Tom Schrijvers
              Manuel Chakravarty
              Simon Peyton-Jones
              Martin Sulzmann 
      with special thanks to Roman Leshchinskiy
  19. 19 Aug, 2007 2 commits
  20. 04 Aug, 2007 1 commit
  21. 09 Jul, 2007 3 commits
  22. 08 Jul, 2007 4 commits
  23. 02 Jul, 2007 1 commit
  24. 29 Jun, 2007 2 commits
  25. 27 Jun, 2007 1 commit
  26. 21 Jun, 2007 1 commit
    • David Himmelstrup's avatar
      Add several new record features · 2eb04ca0
      David Himmelstrup authored
      1. Record disambiguation (-fdisambiguate-record-fields)
      In record construction and pattern matching (although not
      in record updates) it is clear which field name is intended
      even if there are several in scope.  This extension uses
      the constructor to disambiguate.  Thus
      	C { x=3 }
      uses the 'x' field from constructor C (assuming there is one)
      even if there are many x's in scope.
      2. Record punning (-frecord-puns)
      In a record construction or pattern match or update you can 
      omit the "=" part, thus
      	C { x, y }
      This is just syntactic sugar for
      	C { x=x, y=y }
      3.  Dot-dot notation for records (-frecord-dot-dot)
      In record construction or pattern match (but not update) 
      you can use ".." to mean "all the remaining fields".  So
      	C { x=v, .. }
      means to fill in the remaining fields to give
      	C { x=v, y=y }
      (assuming C has fields x and y).  This might reasonably
      considered very dodgy stuff.  For pattern-matching it brings
      into scope a bunch of things that are not explictly mentioned;
      and in record construction it just picks whatver 'y' is in
      scope for the 'y' field.   Still, Lennart Augustsson really
      wants it, and it's a feature that is extremely easy to explain.
      I thought of using the "parent" field in the GlobalRdrEnv, but
      that's really used for import/export and just isn't right for this.
      For example, for import/export a field is a subordinate of the *type
      constructor* whereas here we need to know what fields belong to a
      particular *data* constructor.
      The main thing is that we need to map a data constructor to its
      fields, and we need to do so in the renamer.   For imported modules
      it's easy: just look in the imported TypeEnv.  For the module being
      compiled, we make a new field tcg_field_env in the TcGblEnv.
      The important functions are
      There is still a significant infelicity in the way the renamer
      works on patterns, which I'll tackle next.
      I also did quite a bit of refactoring in the representation of
      record fields (mainly in HsPat).***END OF DESCRIPTION***
      Place the long patch description above the ***END OF DESCRIPTION*** marker.
      The first line of this file will be the patch name.
      This patch contains the following changes:
      M ./compiler/deSugar/Check.lhs -3 +5
      M ./compiler/deSugar/Coverage.lhs -6 +7
      M ./compiler/deSugar/DsExpr.lhs -6 +13
      M ./compiler/deSugar/DsMeta.hs -8 +8
      M ./compiler/deSugar/DsUtils.lhs -1 +1
      M ./compiler/deSugar/MatchCon.lhs -2 +2
      M ./compiler/hsSyn/Convert.lhs -3 +3
      M ./compiler/hsSyn/HsDecls.lhs -9 +25
      M ./compiler/hsSyn/HsExpr.lhs -13 +3
      M ./compiler/hsSyn/HsPat.lhs -25 +63
      M ./compiler/hsSyn/HsUtils.lhs -3 +3
      M ./compiler/main/DynFlags.hs +6
      M ./compiler/parser/Parser.y.pp -13 +17
      M ./compiler/parser/RdrHsSyn.lhs -16 +18
      M ./compiler/rename/RnBinds.lhs -2 +2
      M ./compiler/rename/RnEnv.lhs -22 +82
      M ./compiler/rename/RnExpr.lhs -34 +12
      M ./compiler/rename/RnHsSyn.lhs -3 +2
      M ./compiler/rename/RnSource.lhs -50 +78
      M ./compiler/rename/RnTypes.lhs -50 +84
      M ./compiler/typecheck/TcExpr.lhs -18 +18
      M ./compiler/typecheck/TcHsSyn.lhs -20 +21
      M ./compiler/typecheck/TcPat.lhs -8 +6
      M ./compiler/typecheck/TcRnMonad.lhs -6 +15
      M ./compiler/typecheck/TcRnTypes.lhs -2 +11
      M ./compiler/typecheck/TcTyClsDecls.lhs -3 +4
      M ./docs/users_guide/flags.xml +7
      M ./docs/users_guide/glasgow_exts.xml +42
  27. 20 Jun, 2007 1 commit
  28. 30 May, 2007 2 commits
  29. 14 May, 2007 1 commit
  30. 11 May, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Remove the distinction between data and newtype families · 6777144f
      chak@cse.unsw.edu.au. authored
      - This patch removes "newtype family" declarations.
      - "newtype instance" declarations can now be instances of data families
      - This also fixes bug #1331
        ** This patch changes the interface format.  All libraries and all of **
        ** Stage 2 & 3 need to be re-compiled from scratch.                   **