1. 15 Sep, 2006 4 commits
    • chak@cse.unsw.edu.au.'s avatar
      Cleanup (re type function parsing) · 589ba227
      chak@cse.unsw.edu.au. authored
      Mon Jul 31 17:20:56 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Cleanup (re type function parsing)
      589ba227
    • chak@cse.unsw.edu.au.'s avatar
      Parser support for assoc synonyms · 72264dbc
      chak@cse.unsw.edu.au. authored
      Fri Jul 28 21:52:46 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Parser support for assoc synonyms
      72264dbc
    • chak@cse.unsw.edu.au.'s avatar
      Fix migrated AT support · 658372b8
      chak@cse.unsw.edu.au. authored
      Wed Jul 26 18:16:25 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Fix migrated AT support
        - Make it compile
        - Successfully parses and renames simple AT declarations
        - Should not affect non-AT programs
      658372b8
    • chak@cse.unsw.edu.au.'s avatar
      Migrate cvs diff from fptools-assoc branch · afef3973
      chak@cse.unsw.edu.au. authored
      Wed Jul 26 17:46:55 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Migrate cvs diff from fptools-assoc branch
        - Syntactic support for associated types
        - Renamer support for associated types
        - ATs are only allowed with -fglasgow-exts
        - Handle ATs in the type and class declaration kinding knot-tying exercise
      afef3973
  2. 04 Aug, 2006 1 commit
  3. 02 Aug, 2006 1 commit
  4. 18 Sep, 2006 1 commit
  5. 12 Sep, 2006 2 commits
  6. 07 Sep, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Result type signatures are no longer supported (partial) · 5a552652
      simonpj@microsoft.com authored
      I had failed to remove the bit where result type signatures bind
      lexical type variables.  And now we are planning to remove them entirely.
      
      This commit therefore does a partial removal (to avoid destablising 6.6).
      It also arranges that
      	f :: sig = rhs
      means a *pattern* binding (not a function binding with no arguments 
      and a result signature), which makes sense.
      5a552652
  7. 04 Sep, 2006 1 commit
  8. 21 Aug, 2006 2 commits
  9. 10 Aug, 2006 1 commit
  10. 09 Aug, 2006 1 commit
  11. 07 Aug, 2006 1 commit
  12. 26 Jul, 2006 1 commit
  13. 25 Jul, 2006 1 commit
    • 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
  14. 24 Jul, 2006 1 commit
  15. 12 Jul, 2006 1 commit
  16. 23 Jun, 2006 1 commit
  17. 05 Jun, 2006 1 commit
  18. 01 Jun, 2006 3 commits
  19. 24 May, 2006 1 commit
  20. 19 May, 2006 2 commits
  21. 20 Apr, 2006 2 commits
  22. 14 Apr, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Allow $x, as well as $(x), at top level in TH · 6b2cf62b
      simonpj@microsoft.com authored
      Bulat pointed out that in Template Haskell
         $x
      is allowed instead of 
         $(x)
      in expressions, but not at the top level of modules.
      
      This commit fixes the omission.  Now you can say
      
      	f x = x
       	$h
      	data T = T
      
      and the $h will run Template Haskell just as you'd expect.
      6b2cf62b
  23. 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