GitLab

This has been a long-standing ToDo.

- We need to keep pairs of (f, f_CC) in VectInfo as it is difficult
  to obtain Names from OccNames (of imported modules) in Core passes.
- There is a choice of keeping Names or Vars in VectInfo.  We go with Vars
  for now; mainly to avoid converting between Names and Vars repeatedly for
  the same VectInfo in other than one-shot mode.

  Again goes to the HEAD straight away to avoid conflicts down the road.

When a snapshot version number is included, opt_HiVersion tends to exceed the range of a 32bit Int.

MERGE TO STABLE

Unless we're in one-shot mode, emit an error if we attempt to
demand-load interfaces for home modules.  This can only happen in one
way (that I'm aware of): typing a qualified name at the GHCi prompt
that refers to a module that isn't loaded.  Previously you got a
cryptic message about not finding an interface file, now you get:

Prelude> Foo.a

<interactive>:1:0:
    attempting to use module `Foo' (Foo.hs) which is not loaded

Of course you can still refer to package modules like this without
loading them explicitly, only home modules are affected, and the
behaviour is exactly the same as if you try to ':browse Foo' and
Foo isn't loaded.

- Now each modules carries
  (1) a flag saying whether it contains family instance declarations and
  (2) a list of all modules further down in the import tree that contain
      family instance declarations.
  (The information is split into these two parts for the exact same reasons why
  the info about orphan modules is split, too.)
- This is the first step to *optimised* overlap checking of family instances
  coming from imported modules.

*** WARNING: This patch changes the interface file format! ***
***          Recompile libraries and stage2 from scratch!  ***

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

This large commit combines several interrelated changes:

  - IfaceSyn now contains actual Names rather than the special
    IfaceExtName type.  The binary interface file contains
    a symbol table of Names, where each entry is a (package,
    ModuleName, OccName) triple.  Names in the IfaceSyn point
    to entries in the symbol table.

    This reduces the size of interface files, which should
    hopefully improve performance (not measured yet).

    The toIfaceXXX functions now do not need to pass around
    a function from Name -> IfaceExtName, which makes that
    code simpler.

  - Names now do not point directly to their parents, and the
    nameParent operation has gone away.  It turned out to be hard to
    keep this information consistent in practice, and the parent info
    was only valid in some Names.  Instead we made the following
    changes:

    * ImportAvails contains a new field 
          imp_parent :: NameEnv AvailInfo
      which gives the family info for any Name in scope, and
      is used by the renamer when renaming export lists, amongst
      other things.  This info is thrown away after renaming.

    * The mi_ver_fn field of ModIface now maps to
      (OccName,Version) instead of just Version, where the
      OccName is the parent name.  This mapping is used when
      constructing the usage info for dependent modules.
      There may be entries in mi_ver_fn for things that are not in
      scope, whereas imp_parent only deals with in-scope things.

    * The md_exports field of ModDetails now contains
      [AvailInfo] rather than NameSet.  This gives us
      family info for the exported names of a module.

Also:

   - ifaceDeclSubBinders moved to IfaceSyn (seems like the
     right place for it).

   - heavily refactored renaming of import/export lists.

   - Unfortunately external core is now broken, as it relied on
     IfaceSyn.  It requires some attention.

- Class and type family instances just got a lot more similar.
- FamInst, like Instance, now has a rough match signature.  The idea is the
  same: if the rough match doesn't match, there is no need to pull in the while
  tycon describing the instance (from a lazily read iface).
- IfaceFamInst changes in a similar way and the list of all IFaceFamInsts is
  now written into the binary iface (as for class instances), as deriving it
  from the tycon (as before) would render the whole rough matching useless.
- As a result of this, the plumbing of class instances and type instances 
  through the various environments, ModIface, ModGuts, and ModDetails is now
  almost the same.  (The remaining difference are mostly because the dfun of a
  class instance is an Id, but type instance refer to a TyCon, not an Id.)

*** WARNING: The interface file format changed! ***
***	     Rebuild from scratch.		***

This patch fixes Trac #909.  The problem was that when compiling 
the base package, the handling of wired-in things wasn't right;
in TcIface.tcWiredInTyCon it repeatedly loaded GHC.Base.hi into the
PIT, even though that was the very module it was compiling.

The main fix is by introducing TcIface.ifCheckWiredInThing.

But I did some minor refactoring as well.

Mon Sep 18 19:50:42 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Import/export of data constructors in family instances
  Tue Sep 12 13:54:37 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Import/export of data constructors in family instances
    - Data constructors of a data/newtype family F can be exported and imported
      by writing F(..) or F(ConName).
    - This appears the most natural from a user's persepctive - although, it has a
      slightly different flavour than similar import/exports items for closed data 
      types.  The data constructors denoted by F(..) vary in dependence on the 
      visible data instances.
    - This has been non-trivial to achieve as RnNames derives its knowledge of what
      sub-binders an F(..) item exports/imports from the relation specified by 
      Name.nameParent - ie, the constructors of a data/newtype instance need to 
      have the family name (not the internal name of the representation tycon) as 
      their parent.
    
    *** WARNING: This patched changes the iface format! ***
    ***          Please re-compile from scratch!	    ***

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!          ***

Mon Sep 18 19:36:03 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * ATs are now implicitTyThings
  Tue Sep  5 21:09:54 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * ATs are now implicitTyThings

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.                ***

Mon Sep 18 19:34:38 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Fixed two bugs concerning fanilies
  Mon Sep  4 20:59:49 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Fixed two bugs concerning fanilies

Mon Sep 18 17:19:19 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Flip direction of newtype coercions, fix some comments
  Sun Aug  6 20:56:23 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Flip direction of newtype coercions, fix some comments
    Thu Aug  3 10:53:37 EDT 2006  kevind@bu.edu

Mon Aug  7 12:40:55 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Remove mi_package from moved pprModIface

Fri Aug  4 17:43:25 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Massive patch for the first months work adding System FC to GHC #20
  
  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.

In particular, if we're searching for the profiling version of a
module in another package, then suggest that perhaps it might not have
been installed.

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.

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.

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.

Make the forkM failure fail more tidily.  Interface-file inconsistencies
give rise to failures in the IfM monad.  An error message is printed, but
up to now we've also said "The impossible happened, must be a GHC bug".
That's not true, though, it could just be messed up interface files.

So this commit still makes the compiler halt, but in a tidier, less
self-accusatory way.

Still to come: when original names in interface files mention the
package Id too, the error will become clearer still.

	MERGE to STABLE

Wibble to loadHomeInterface for TH quoting; MERGE to STABLE

In the :i command for ghci, load the interface files for
the home module of every in-scope type or class. That way
we are sure to see all their instance declarations.

	MERGE TO STABLE branch

Instance for wired-in tycons wibble

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.

Significant clean-up of the handling of hi-boot files. 
Previously, when compling A.hs, we loaded A.hi-boot, and
it went into the External Package Table.  It was strange
but it worked.  This tidy up stops it going anywhere;
it's just read in, and typechecked into a ModDetails.

All this was on the way to improving the handling of
instances in hs-boot files, something Chris Ryder wanted.
I think they work quite sensibly now.  

If I've got all this right (have not had a chance to
fully test it) we can merge it into STABLE.