1. 25 Jul, 2006 5 commits
    • Simon Marlow's avatar
      Make a SplitUniqSupply contain an Int# rather than an Int · 39a2bccc
      Simon Marlow authored
      The I# constructor is always removed when we make a unique later
      anyway, so this just saves a bit of time and allocation.
    • Simon Marlow's avatar
    • Simon Marlow's avatar
      Remove most of the conflict checking and auto-hiding · b93ff3a3
      Simon Marlow authored
      Now that the module restriction has been lifted, the auto-hiding is
      mostly not required.  GHC itself automatically hides old versions of a
    • 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
      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
      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
      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
        - 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.
    • Simon Marlow's avatar
      comment formatting · b93eb0c2
      Simon Marlow authored
  2. 06 Jul, 2006 2 commits
  3. 04 Jul, 2006 7 commits
  4. 24 Jul, 2006 1 commit
  5. 22 Jul, 2006 2 commits
    • 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
      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.
    • simonpj@microsoft.com's avatar
      Fix RULES lossage · 4fbd341b
      simonpj@microsoft.com authored
      Don Stewart and Duncan Coutts encountered the following situation.
      	f = <rhs>
      	{-# RULES f ... #-}
      where f is not exported, but appears in the inlinings of other
      functions that are exported.  Then what happened was that the desugarer
      produced this:
      	M.f = f
      	f = <rhs>
      where the rules get attached to the M.f. But since M.f's RHS is trivial
      (just f) it was unconditionally inlinined at all its call sites, 
      thereby losing the RULES attached to it.
      This *is* a fragile aspect of rules. However this fix solves the 
      problem by instead generating
      	f = M.f
      	M.f = <rhs>
      A pretty small chanage to the desugarer does the job.  It still feels
      a little fragile, bt it's certainly more robust than before.
  6. 21 Jul, 2006 2 commits
  7. 19 Jul, 2006 1 commit
  8. 17 Jul, 2006 1 commit
  9. 14 Jul, 2006 2 commits
  10. 12 Jul, 2006 4 commits
    • simonpj@microsoft.com's avatar
      Comments and import trimming · 6bca92c3
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Experimental flag -fdicts-cheap · e1231b2b
      simonpj@microsoft.com authored
      This experimental flag, -fdicts-cheap, makes a let-binding that bind a
      value of dictionary type look cheap.  That in turn leads to more
      eta expansion.  Instead of
      	f = /\a. \(d1:Ord a). let d2:Ord [a] = dfOrd a d1 in
                       \(x:a). <stuff>
      which has arity 1, you get
      	f = /\a. \(d1:Ord a). \(x:a).
      	         let d2:Ord [a] = dfOrd a d1 in <stuff>
      Now f has arity 2.
      This can cretainly waste dictionary-construction work, if f is
      partially applied to its dictionary argument.  However it has knock-on
      effects.  Because f has arity 2, we won't float (f Int d) out of
      	\x. h (f Int d)
      Floating f out of this lambda makes it impossible for an h/f fusion
      rule to fire; and this unexpected loss of RULE application was the
      immediate reason for implementing this flag. (Roman Leshchinskiy came
      across this when working on array fusion.)
      I've implemented the change only in CoreUtils.arityType, which
      only affects eta expansion.  I thought of putting the change in
      exprIsCheap, which is a more systematic place (the former calls
      the latter) but
      	a) I wanted this under flag control, and the flags 
      	are not readily available to all callers of exprIsCheap
      	b) I'm not 100% convinced that this change is a good
      	idea, so it's reasonable to do the narrowest change
      	that solves the immediate problem.
    • Malcolm.Wallace@cs.york.ac.uk's avatar
    • Simon Marlow's avatar
  11. 06 Jul, 2006 1 commit
  12. 10 Jul, 2006 1 commit
    • Simon Marlow's avatar
      re-add -fvia-C · ab27a311
      Simon Marlow authored
      There are still some fixes required to get the threaded RTS compilable
      with the NCG, and apparently there are problems on 32-bit archs too.
  13. 24 Jun, 2006 1 commit
  14. 02 Jul, 2006 2 commits
    • Jan Rochel's avatar
      Z-Encode external-core output · 202712d3
      Jan Rochel authored
      HEAD doesn't z-encode external-core output (unlike 6.4). I suppose, that
      this is unwanted behaviour. It probably results from this patch:
      Fri Jan  6 17:30:19 CET 2006  simonmar
        * [project @ 2006-01-06 16:30:17 by simonmar]
        Add support for UTF-8 source files
      Z-encoding has been moved right to the back end.  Previously we
      used to Z-encode every identifier on the way in for simplicity,
      and only decode when we needed to show something to the user.
      Instead, we now keep every string in its UTF-8 encoding, and
      Z-encode right before printing it out.
    • Jan Rochel's avatar
      Add %local-tag to external core output · 99bab7d8
      Jan Rochel authored
      Hello, this is my first patch contributed to GHC. If there are any
      inadequacies about it (maybe like this introductory disclaimer), please
      let me know about it.
      So, the need for this patch arose, while I was involved with processing
      hcr files (external core output) and I noticed, that the output didn't
      fully conform to the specification [1].
      No %local-tags were used, which turned out to be a real nuisance as it
      was not possible to determine which VDEFs can be erased in a further
      optimization process and which ones are exported by the module.
      Since the specification does not define the meaning of the %local-tag, I
      assume, it makes sense, that it tags all functions, that are not
      exported by the module.
      The patch does not fully comply to the specification, as in my
      implementation a local tag may appear before a VDEF but not before a
      [1] An External Representation for the GHC Core Language
          (DRAFT for GHC5.02), page 3, line 1
  15. 03 Jul, 2006 1 commit
  16. 04 Jul, 2006 1 commit
  17. 03 Jul, 2006 1 commit
    • simonpj@microsoft.com's avatar
      The dict-bindings in an IPBinds need not be in dependency order · 5c9c3660
      simonpj@microsoft.com authored
      This appears to be a long-standing bug, discovered by BlueSpec 
      (ravi@bluespec.com), Trac bug #795
      The problem was that in an IP binding group, the dict bindings
      aren't necessarily in dependency order; and if they aren't 
      we get a core-lint error.
      Test tc203 checks this case.  (Though whether it shows up at
      all depends a bit on accidental factors of binding ordering.)
  18. 04 Jul, 2006 1 commit
  19. 29 Jun, 2006 4 commits