1. 03 Sep, 2007 1 commit
  2. 01 Sep, 2007 1 commit
  3. 22 Aug, 2007 1 commit
  4. 26 Jul, 2007 1 commit
  5. 18 Jul, 2007 1 commit
  6. 16 Jul, 2007 1 commit
  7. 27 Jun, 2007 1 commit
  8. 11 May, 2007 1 commit
  9. 10 May, 2007 1 commit
  10. 01 May, 2007 1 commit
  11. 04 May, 2007 1 commit
  12. 25 Apr, 2007 1 commit
  13. 10 Jan, 2007 1 commit
  14. 29 Dec, 2006 1 commit
  15. 08 Nov, 2006 1 commit
  16. 20 Oct, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Fix processing of imports involving ATs with the new name parent code · 4f55ec2c
      chak@cse.unsw.edu.au. authored
      Associated types in import lists require special care and the new name
      parent code broke that.  What's the problem?  in the presence of ATs
      the name parent relation can have a depth of two (not just one as in H98).
      Here is an example:
      
        class GMapKey a where
          data GMap a :: * -> *
        instance GMapKey Int where
          data GMap Int v = GMapInt ...
      
      The data constructor GMapInt's parent is GMap whose parent in turn is the 
      class GMapKey; ie, GMapKey is GMapInt's grand parent.  In H98, data types 
      have no parents (which is in some places in the code represented by making 
      them their own parent).
      
      I fixed this by extending the information in filterImport's occ_env and
      taking the case of associated types explicitly in consideration when 
      processing the various forms of IE items.
      4f55ec2c
  17. 11 Oct, 2006 1 commit
    • Simon Marlow's avatar
      Module header tidyup, phase 1 · 49c98d14
      Simon Marlow authored
      This patch is a start on removing import lists and generally tidying
      up the top of each module.  In addition to removing import lists:
      
         - Change DATA.IOREF -> Data.IORef etc.
         - Change List -> Data.List etc.
         - Remove $Id$
         - Update copyrights
         - Re-order imports to put non-GHC imports last
         - Remove some unused and duplicate imports
      49c98d14
  18. 10 Oct, 2006 1 commit
  19. 20 Sep, 2006 5 commits
    • chak@cse.unsw.edu.au.'s avatar
      Fix category of representation tycon · 5043f590
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:48:00 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Fix category of representation tycon
        Mon Sep 11 16:18:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Fix category of representation tycon
      5043f590
    • chak@cse.unsw.edu.au.'s avatar
      Get of fam inst index in ifaces · 0cb269be
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:40:42 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Get of fam inst index in ifaces
        Fri Sep  8 16:31:26 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Get of fam inst index in ifaces
          - Removes the explicit index to get unique names for derived tycons for family
            instances again, following a suggestion by SPJ.
          - We now derive the coercion tycon name from the name of the representation 
            tycon, which is in the iface anyways.
          
          *** WARNING: Change of interface file format! ***
          ***          Recompile from scratch!          ***
      0cb269be
    • chak@cse.unsw.edu.au.'s avatar
      Straightened out implicit coercions for indexed types · d76c18e0
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:35:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Straightened out implicit coercions for indexed types
        Mon Sep  4 23:46:14 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Straightened out implicit coercions for indexed types
          - HscTypes.implicitTyThings and LoadIface.ifaceDeclSubBndrs now
            include the coercion of indexed data/newtypes.
          - Name generation for the internal names of indexed data/newtypes now uses
            the same counter that generates the dfun unique indexes (ie, class and type
            instances are counted with the one counter).  We could make this two 
            separate counters if that's what's preferred.
          - The unique index of a data/newtype instances needs to go into the iface, so
            that we can generate the same names on slurping in the iface as when the
            original module was generated.  This is a bit yucky, but I don't see a way
            to avoid that (other than putting the full blown internal tycon name and 
            coercion name into the iface, which IMHO would be worse).
          - The predicate for when a datacon has a wrapper didn't take GADT
            equations nor whether it comes froma  family instance into account.
          
          *** WARNING!  This patch changed the interface file format. ***
          ***           Please recompile from scratch.                ***
      d76c18e0
    • chak@cse.unsw.edu.au.'s avatar
      Pattern matching of indexed data types · 6791ad22
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:11:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Pattern matching of indexed data types
        Thu Aug 24 14:17:44 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Pattern matching of indexed data types
          - This patch is the last major puzzle piece to type check and desugar indexed 
            data types (both toplevel and associated with a class).
          - However, it needs more testing - esp wrt to accumlating CoPats - and some 
            static sanity checks for data instance declarations are still missing.
          - There are now two detailed notes in MkIds and TcPat on how the worker/wrapper
            and coercion story for indexed data types works.
      6791ad22
    • chak@cse.unsw.edu.au.'s avatar
      Introduce coercions for data instance decls · 909d2dd8
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:07:30 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Introduce coercions for data instance decls
        Tue Aug 22 20:33:46 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Introduce coercions for data instance decls
          - data instance declarations implicitly generate a coercion moving between the
            representation type and family instance type.
          - The coercion is *implicitly* generated when type checking both source and 
            ifaces.  Ie, we don't safe it in ifaces - this is really exactly as newtype 
            coercions are handled.
          - The previous addition of the instance types to DataCons has been moved to 
            the representation TyCon.  This is more efficient as it is shared between all
            constructors of one representation tycon and it also gathers everything about
            data instances (family tycon, instance types, and coercion) in one place: the
            algTcParent field of TyCon.
          - The coercion is already used in the datacon wrappers, but not yet during type
            checking pattern matching of indexed data types.
          - The code has only been lightly tested, but doesn't seem to break features not
            related to indexed types.  For indexed data types only the pattern matching
            tc code (in TcPat.tcConPat) and some well-formedness checks are still 
            missing.  And there will surely be some bugs to fix.  (newtypes still require
            some more work.)
          
          	   ** WARNING: Interface file format changed! **
          	   **          Recompile from scratch!        **
      909d2dd8
  20. 18 Sep, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Massive patch for the first months work adding System FC to GHC #1 · d5bba9ee
      chak@cse.unsw.edu.au. authored
      Fri Aug  4 15:11:01 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Massive patch for the first months work adding System FC to GHC #1
        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.
      d5bba9ee
  21. 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
  22. 08 Feb, 2006 1 commit
  23. 18 Jan, 2006 1 commit
  24. 06 Jan, 2006 1 commit
    • simonmar's avatar
      [project @ 2006-01-06 16:30:17 by simonmar] · 9d7da331
      simonmar authored
      Add support for UTF-8 source files
      
      GHC finally has support for full Unicode in source files.  Source
      files are now assumed to be UTF-8 encoded, and the full range of
      Unicode characters can be used, with classifications recognised using
      the implementation from Data.Char.  This incedentally means that only
      the stage2 compiler will recognise Unicode in source files, because I
      was too lazy to port the unicode classifier code into libcompat.
      
      Additionally, the following synonyms for keywords are now recognised:
      
        forall symbol 	(U+2200)	forall
        right arrow   	(U+2192)	->
        left arrow   		(U+2190)	<-
        horizontal ellipsis 	(U+22EF)	..
      
      there are probably more things we could add here.
      
      This will break some source files if Latin-1 characters are being used.
      In most cases this should result in a UTF-8 decoding error.  Later on
      if we want to support more encodings (perhaps with a pragma to specify
      the encoding), I plan to do it by recoding into UTF-8 before parsing.
      
      Internally, there were some pretty big changes:
      
        - FastStrings are now stored in UTF-8
      
        - 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.  To avoid Z-encoding the
          same string multiple times, the Z-encoding is cached inside the
          FastString the first time it is requested.
      
          This speeds up the compiler - I've measured some definite
          improvement in parsing at least, and I expect compilations overall
          to be faster too.  It also cleans up a lot of cruft from the
          OccName interface.  Z-encoding is nicely hidden inside the
          Outputable instance for Names & OccNames now.
      
        - StringBuffers are UTF-8 too, and are now represented as
          ForeignPtrs.
      
        - I've put together some test cases, not by any means exhaustive,
          but there are some interesting UTF-8 decoding error cases that
          aren't obvious.  Also, take a look at unicode001.hs for a demo.
      9d7da331
  25. 30 Nov, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-11-30 14:20:06 by simonpj] · 10dd2a6d
      simonpj authored
      -----------------------------------------
      	Fix 'mkName' operator in Template Haskell
      	so that it handles built-in syntax
      	-----------------------------------------
      
      	Merge to stable branch
      
      The 'mkName' function in Template Haskell wasn't dealing correctly with
      built-in syntax.  The parser generates Exact RdrNames for built-in syntax
      operators, such as ':' and '[]'; and hence so should Convert.
      
      At the same time I'm now generating a better error message in TH when
      you use a constructor as a variable or vice versa.
      10dd2a6d
  26. 12 Nov, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-11-12 21:41:12 by simonpj] · 87998beb
      simonpj authored
      Better TH -> HsSyn conversion
      
      	Merge to stable (attempt)
      
      This commit monad-ises the TH syntax -> HS syntax conversion.
      This means that error messages can be reported in a more civilised
      way.  It also ensures that the entire structure is converted eagerly.
      That means that any exceptions buried inside it are triggered 
      during conversion, and caught by the exception handler in TcSplice.
      Before, they could be triggered later, and looked like comiler
      crashes.
      87998beb
  27. 06 Oct, 2005 1 commit
  28. 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
      up.
      
      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.
      dd313897
  29. 05 Apr, 2005 1 commit
  30. 08 Mar, 2005 1 commit
  31. 28 Feb, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-02-28 12:03:12 by simonmar] · 09e2c3a1
      simonmar authored
      The type variables in the types of wired-in entities were built using
      mkVarOcc, which gives a variable name rather than a type variable
      name.  Normally the compiler doesn't care, but when tidying types for
      output to the user the tidier would consider a VarName as distinct
      from a TvName, and not give them different print names.
      
      This fix makes puts all the type variables in the TvName namespace.
      09e2c3a1
  32. 25 Feb, 2005 1 commit
    • 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
      
      Consider
      
        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.
      8e67f550
  33. 10 Sep, 2004 1 commit
  34. 02 Sep, 2004 1 commit
  35. 31 Dec, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-12-31 08:23:25 by simonpj] · 7473349e
      simonpj authored
      -----------------------------
              Improve deprecation reporting
      	-----------------------------
      
      	[PS: the 1.31 commit of basicTypes/RdrName.lhs
      	 also belongs in this commit.]
      
      Up to now, deprecated functions are only reported when imported
      from the module defining them, but not when re-exporting.  This
      seems wrong -- often a "root" module gathers exports from sub-modules.
      
      It turned out that there was a structural problem: the deprectaions
      were getting put in the GlobalRdrEnv, and it simply doesn't have
      the defining-module's interface to hand.
      
      So this commit removes gre_deprec from GRE, and moves deprecation
      reporting from the individual occurrences (RnEnv.lookupGreRn) to
      RnNames.reportUnusedNames.  In many ways this is a better place for it,
      because there we get a global view of the entire module.  For example,
      repeated use of a single deprecated thing will only give rise to one
      warning instead of multiple warnings.
      
      So here's what we now get:
      
        Foo.hs:3:0:
          Warning: Deprecated use of Variable `withObject'
      	     (imported from Foreign.Marshal, but defined in Foreign.Marshal.Utils)
      	     use `with' instead
      7473349e
  36. 06 Nov, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-11-06 17:09:50 by simonpj] · 1f5e5580
      simonpj authored
      ------------------------------------
      	Major increment for Template Haskell
      	------------------------------------
      
      1.  New abstract data type "Name" which appears where String used to be.
          E.g. 	data Exp = VarE Name | ...
      
      2.  New syntax 'x and ''T, for quoting Names.  It's rather like [| x |]
          and [t| T |] respectively, except that
      
      	a) it's non-monadic:  'x :: Name
      	b) you get a Name not an Exp or Type
      
      3.  reify is an ordinary function
      	reify :: Name -> Q Info
          New data type Info which tells what TH knows about Name
      
      4.  Local variables work properly.  So this works now (crashed before):
      	f x = $( [| x |] )
      
      5.  THSyntax is split up into three modules:
      
        Language.Haskell.TH		TH "clients" import this
      
        Language.Haskell.TH.THSyntax	data type declarations and internal stuff
      
        Language.Haskell.TH.THLib	Support library code (all re-exported
      				by TH), including smart constructors and
      				pretty printer
      
      6.  Error reporting and recovery are in (not yet well tested)
      
      	report :: Bool {- True <=> fatal -} -> String -> Q ()
      	recover :: Q a -> Q a -> Q a
      
      7.  Can find current module
      
      	currentModule :: Q String
      
      
      Much other cleaning up, needless to say.
      1f5e5580