1. 08 Aug, 2006 2 commits
    • simonpj@microsoft.com's avatar
      Fix pre-subsumption and pre-matching · 3098d214
      simonpj@microsoft.com authored
      The pre-subsuption and pre-matching functions should NEVER make bogus
      bindings of type variables, although they are free to bale out and make
      too few bindings.
      
      I hadn't been thiking carefully enough about this, and there were two
      separate bugs.  
      
      - Firstly, in pre-subsumption we must ignore the 'theta'
        part of any overloaded type.  
      
      - Second, in pre-matching, we must return the empty subustition 
        on a mis-match, rather than returning the substitution so far.
      
      This bug showed up when compiling Data.Generics.Schemes.hs, and is
      imortalised in test tc206
      3098d214
    • simonpj@microsoft.com's avatar
      Improve error message · d2b27dcd
      simonpj@microsoft.com authored
      Improve a little-used error message.  Given
      	f :: a -> a
      	f x y = e
      the error says 
      
      	The equations for f have two arguments
      	but its type `a -> a' has only one
      
      (Before, it said "its type `a' has only one" which is bogus.
      d2b27dcd
  2. 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.)
      
      Simon
      
      
      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? 
      6e0c3f50
  3. 04 Aug, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Do pre-subsumption in the main subsumption check · af20907a
      simonpj@microsoft.com authored
      This patch improves the subsumption check (in TcUnify.tc_sub) so that
      it does pre-subsumption first.  The key code is in the case with
      guard (isSigmaTy actual_ty); note the new call to preSubType.
      
      Shorn of details, the question is this.  Should this hold?
      
      	forall a. a->a   <=   Int -> (forall b. Int)
      
      Really, it should; just instantiate 'a' to Int.  This is just what
      the pre-subsumption phase (which used in function applications),
      will do.
      
      I did a bit of refactoring to achieve this.
      
      Fixes Trac #821.  Test tc205 tests.
      af20907a
  4. 01 Aug, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Make unification robust to a boxy type variable meeting itself · 6493f9d3
      simonpj@microsoft.com authored
      Previously, the implicit assumption in unification is that a boxy
      type variable could never occur on both sides of the unification,
      so that we'd never find 
      	bx5 :=: bx5
      
      But the pre-subsumption stuff really means that the same variable
      can occur on both sides.  Consider
      	forall a. a->Int <= bx5->Int
      Then pre-subumption will find a->bx5; and the full subsumption step 
      will find bx5:=bx5.
      
      However, I think there is still no possiblity of a full occurs-check
      failure; that is, 
      	bx5 :=: Tree bx5
      Although I can't quite see how to prove it!  So I've added a
      DEBUG test in uMetaVar to check for this case.
      6493f9d3
  5. 28 Jul, 2006 1 commit
  6. 27 Jul, 2006 2 commits
  7. 26 Jul, 2006 1 commit
  8. 25 Jul, 2006 2 commits
    • Simon Marlow's avatar
      optimisations to newUnique · bb3dcf39
      Simon Marlow authored
      It turned out that newUnique was wasting one node of the splittable
      uniq supply per invocation: it took the current supply, split it, used
      the unique from one half and stored the other half in the monad.  In
      other words, the unique in the supply stored in the monad was never
      used.  
      
      This optimisation fixes that and adds a bit of strictness, which
      together lead to small reduction in allocations by the compiler, and
      possibly an improvement in residency (hard to tell for sure when GCs
      move around).
      bb3dcf39
    • Simon Marlow's avatar
      Generalise Package Support · 61d2625a
      Simon Marlow authored
      This patch pushes through one fundamental change: a module is now
      identified by the pair of its package and module name, whereas
      previously it was identified by its module name alone.  This means
      that now a program can contain multiple modules with the same name, as
      long as they belong to different packages.
      
      This is a language change - the Haskell report says nothing about
      packages, but it is now necessary to understand packages in order to
      understand GHC's module system.  For example, a type T from module M
      in package P is different from a type T from module M in package Q.
      Previously this wasn't an issue because there could only be a single
      module M in the program.
      
      The "module restriction" on combining packages has therefore been
      lifted, and a program can contain multiple versions of the same
      package.
      
      Note that none of the proposed syntax changes have yet been
      implemented, but the architecture is geared towards supporting import
      declarations qualified by package name, and that is probably the next
      step.
      
      It is now necessary to specify the package name when compiling a
      package, using the -package-name flag (which has been un-deprecated).
      Fortunately Cabal still uses -package-name.
      
      Certain packages are "wired in".  Currently the wired-in packages are:
      base, haskell98, template-haskell and rts, and are always referred to
      by these versionless names.  Other packages are referred to with full
      package IDs (eg. "network-1.0").  This is because the compiler needs
      to refer to entities in the wired-in packages, and we didn't want to
      bake the version of these packages into the comiler.  It's conceivable
      that someone might want to upgrade the base package independently of
      GHC.
      
      Internal changes:
      
        - There are two module-related types:
      
              ModuleName      just a FastString, the name of a module
              Module          a pair of a PackageId and ModuleName
      
          A mapping from ModuleName can be a UniqFM, but a mapping from Module
          must be a FiniteMap (we provide it as ModuleEnv).
      
        - The "HomeModules" type that was passed around the compiler is now
          gone, replaced in most cases by the current package name which is
          contained in DynFlags.  We can tell whether a Module comes from the
          current package by comparing its package name against the current
          package.
      
        - While I was here, I changed PrintUnqual to be a little more useful:
          it now returns the ModuleName that the identifier should be qualified
          with according to the current scope, rather than its original
          module.  Also, PrintUnqual tells whether to qualify module names with
          package names (currently unused).
      
      Docs to follow.
      61d2625a
  9. 04 Jul, 2006 2 commits
  10. 24 Jul, 2006 1 commit
  11. 22 Jul, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Add -fmono-pat-binds, and make it the default · 10ffe4f7
      simonpj@microsoft.com authored
      In Haskell 98, pattern bindings are generalised.  Thus in
      	(f,g) = (\x->x, \y->y)
      both f and g will get polymorphic types.  I have become convinced
      that generalisation for pattern-bound variables is just a bridge
      toof far. It is (I claim) almost never needed, and it adds significant
      complication.  (All the more so if we add bang patterns.)
      
      So the flag -fmono-pat-binds switches off generalisation for pattern
      bindings.  (A single variable is treated as a degnerate funtction
      binding.)  
      
      Furthremore, as an experiment, I'm making it the default.  I want
      to see how many progarms fail with monomorphic pattern bindings.
      
      You can recover the standard behaviour with -fno-mono-pa-binds.
      10ffe4f7
  12. 12 Jul, 2006 1 commit
  13. 23 Jun, 2006 1 commit
  14. 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)
      7f0ce617
  15. 14 Jun, 2006 1 commit
  16. 21 Jun, 2006 1 commit
  17. 12 Jun, 2006 1 commit
  18. 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) = ...
      5a8a219c
  19. 08 May, 2006 1 commit
  20. 05 May, 2006 1 commit
  21. 02 May, 2006 1 commit
  22. 05 May, 2006 2 commits
    • simonpj@microsoft.com's avatar
      Preserve type variable names during type inference · a9da016a
      simonpj@microsoft.com authored
      During unification we attempt to preserve the print-names of type variables,
      so that type error messages tend to mention type variables using the 
      programmer's vocabulary.  
      
      This had bit-rotted a bit when I added impredicative polymorphism; especially
      when unBoxing a boxy type variable we should not gratuitously lose its name.
      a9da016a
    • simonpj@microsoft.com's avatar
      Trim imports · b64c0fec
      simonpj@microsoft.com authored
      b64c0fec
  23. 04 May, 2006 2 commits
  24. 18 Apr, 2006 4 commits
  25. 14 Apr, 2006 3 commits
  26. 11 Apr, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Allow IO to be wrapped in a newtype in foreign import/export · fb0f3349
      simonpj@microsoft.com authored
      Up to now, the silent unwrapping of newtypes in foreign import/export
      has been limited to data values.  But it's useful for the IO monad
      itself:
      
      	newtype MyIO a = MIO (IO a)
      
      	foreign import foo :: Int -> MyIO Int
      
      This patch allows the IO monad to be
      wrapped too. This applies to foreign import "dynamic" and "wrapper", 
      thus
         foreign import "wrapper" foo :: MyIO () -> HisIO (FunPtr (MyIO ())) 
      
      Warning: I did on the plane, and I'm no longer sure if its 100% 
      complete, so needs more testing.  In particular the wrapper/dynamic bit.
      fb0f3349
  27. 02 Apr, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Improve newtype deriving · aa2c486e
      simonpj@microsoft.com authored
      Ross Paterson pointed out a useful generalisation of GHC's 
      newtype-deriving mechanism.  This implements it.  The idea
      is to allow
      	newtype Wrap m a = Wrap (m a) deriving (Monad, Eq)
      where the representation type doesn't start with a type
      constructor.
      
      Actually GHC already *did* implement this, but the eta-ok
      check in TcDeriv missed a case, so there was a lurking bug.
      
      This patches fixes the documentation too.  drvrun019 tests.
      
      aa2c486e
  28. 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