GitLab

Older GHCs can't parse OPTIONS_GHC.
This also changes the URL referenced for the -w options from
WorkingConventions#Warnings to CodingStyle#Warnings for the compiler
modules.

and the subspan relation, and move it to the SrcLoc module

mapAccumL and mapAccumR are in Data.List now.
mapAccumB is unused.

Use standard isPrefixOf/isSuffixOf instead.

This tidy-up, triggered by Trac #1068, re-factors the way that 'deriving' 
happens.  It took me way longer than I had intended.  The main changes,
by far are to TcDeriv; everyting else is a minor consequence.

While I was at it, I changed the syntax for standalone deriving, so that
it goes
	derive instance Show (T a)

(instead of "derive Show for T").  However, there's still an implicit
context, generated by the deriving code, and I wonder if it shouldn't really
be
	derive instance (..) => Show (T a)
but I have left it simple for now.

I also added a function Type.substTyVars, and used it here and there, which
led to some one-line changes otherwise unrelated (sorry).

Loose ends:
  * 'deriving Typeable' for indexed data types is still not right
  * standalone deriving should be documented

Push this further along, and fix build problems in the first patch.

Addresses ticket #197, which asks for escape sequences to be supported directly (i.e.
not only in dquoted strings) on :load commands in GHCI.  Fix modifies the toArgs
function to parse its input like /bin/sh does, i.e. recognizing escapes anywhere
and treating quoted strings as atomic chunks.  Thus:
  :load a\ b c\"d e" "f
would parse with three arguments, namely 'a b', 'c"d', and 'e f'.

toArgs is used to parse arguments for both :load and :main, but doesn't appear to
be used elsewhere.  I see no harm in modifying both to be consistent -- in fact,
the functionality is probably more useful for :main than for :load.

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.

Two significant changes to the representation of types

1. Change the representation of type synonyms

    Up to now, type synonym applications have been held in
    *both* expanded *and* un-expanded form.  Unfortunately, this
    has exponential (!) behaviour when type synonyms are deeply
    nested.  E.g.
	    type P a b = (a,b)
	    f :: P a (P b (P c (P d e)))
    
    This showed up in a program of Joel Reymont, now immortalised
    as typecheck/should_compile/syn-perf.hs

    So now synonyms are held as ordinary TyConApps, and expanded
    only on demand.  

    SynNote has disappeared altogether, so the only remaining TyNote
    is a FTVNote.  I'm not sure if it's even useful.

2. Eta-reduce newtypes

    See the Note [Newtype eta] in TyCon.lhs
    
    If we have 
	    newtype T a b = MkT (S a b)
    
    then, in Core land, we would like S = T, even though the application
    of T is then not saturated. This commit eta-reduces T's RHS, and
    keeps that inside the TyCon (in nt_etad_rhs).  Result is that 
    coreEqType can be simpler, and has less need of expanding newtypes.

- Add support for the GHC_PACKAGE_PATH environment variable, which
  specifies a :-separated (;-separated on Windows) list of package
  database files.  If the list ends in : (; on Windows), then the
  normal user and global databases are added.

  GHC_PACKAGE_PATH is searched left-to-right for packages, like
  $PATH, but unlike -package-conf flags, which are searched
  right-to-left.  This isn't ideal, but it seemed the least worst to me
  (command line flags always override right-to-left (except -i),
  whereas the PATH environment variable overrides left-to-right, I chose
  to follow the environment variable convention).  I can always change
  it if there's an outcry.

- Rationalise the interpretation of --user, --global, and -f on the
  ghc-pkg command line.  The story is now this: --user and --global
  say which package database to *act upon*, they do not change the
  shape of the database stack.  -f pushes a database on the stack, and
  also requests that the specified database be the one to act upon, for
  commands that modify the database.  If a database is already on the stack,
  then -f just selects it as the one to act upon.

  This means you can have a bunch of databases in GHC_PACKAGE_PATH, and
  use -f to select the one to modify.

WARNING: this is a big commit.  You might want 
	to wait a few days before updating, in case I've 
	broken something.

	However, if any of the changes are what you wanted,
	please check it out and test!

This commit does three main things:

1. A re-organisation of the way that GHC handles bindings in HsSyn.
   This has been a bit of a mess for quite a while.  The key new
   types are

	-- Bindings for a let or where clause
	data HsLocalBinds id
	  = HsValBinds (HsValBinds id)
	  | HsIPBinds  (HsIPBinds id)
	  | EmptyLocalBinds

	-- Value bindings (not implicit parameters)
	data HsValBinds id
	  = ValBindsIn  -- Before typechecking
		(LHsBinds id) [LSig id]	-- Not dependency analysed
					-- Recursive by default

	  | ValBindsOut	-- After typechecking
		[(RecFlag, LHsBinds id)]-- Dependency analysed

2. Implement Mark Jones's idea of increasing polymoprhism
   by using type signatures to cut the strongly-connected components
   of a recursive group.  As a consequence, GHC no longer insists
   on the contexts of the type signatures of a recursive group
   being identical.

   This drove a significant change: the renamer no longer does dependency
   analysis.  Instead, it attaches a free-variable set to each binding,
   so that the type checker can do the dep anal.  Reason: the typechecker
   needs to do *two* analyses:
	one to find the true mutually-recursive groups
		(which we need so we can build the right CoreSyn)
	one to find the groups in which to typecheck, taking
		account of type signatures

3. Implement non-ground SPECIALISE pragmas, as promised, and as
   requested by Remi and Ross.  Certainly, this should fix the 
   current problem with GHC, namely that if you have
	g :: Eq a => a -> b -> b
   then you can now specialise thus
	SPECIALISE g :: Int -> b -> b
    (This didn't use to work.)

   However, it goes further than that.  For example:
	f :: (Eq a, Ix b) => a -> b -> b
   then you can make a partial specialisation
	SPECIALISE f :: (Eq a) => a -> Int -> Int

    In principle, you can specialise f to *any* type that is
    "less polymorphic" (in the sense of subsumption) than f's 
    actual type.  Such as
	SPECIALISE f :: Eq a => [a] -> Int -> Int
    But I haven't tested that.

    I implemented this by doing the specialisation in the typechecker
    and desugarer, rather than leaving around the strange SpecPragmaIds,
    for the specialiser to find.  Indeed, SpecPragmaIds have vanished 
    altogether (hooray).

    Pragmas in general are handled more tidily.  There's a new
    data type HsBinds.Prag, which lives in an AbsBinds, and carries
    pragma info from the typechecker to the desugarer.


Smaller things

- The loop in the renamer goes via RnExpr, instead of RnSource.
  (That makes it more like the type checker.)

- I fixed the thing that was causing 'check_tc' warnings to be 
  emitted.

Clarify code for splitLongestPrefix; no effect on behaviour

remove duplicate export

Further tweaks to the filename handling.

Rationalise the filename handling in a few places, taking some bits
from the defunct System.FilePath library.  Also fixes a bug I recently
introduced in replaceFilenameDirectory.

replaceFilenameSuffix: fix

Implement -x <suffix> flag to override the suffix of a filename for
the purposes of determinig how it should be compiled.  The usage is
similar to gcc, except that we just use a suffix rather than a name
for the language. eg.

   ghc -c -x hs hello.blah

will pretend hello.blah is a .hs file.  Another possible use is -x
hspp, which skips preprocessing.

This works for one-shot compilation, --make, GHCi, and ghc -e.  The
original idea was to make it possible to use runghc on a file that
doesn't end in .hs, so changes to runghc will follow.

Also, I made it possible to specify .c files and other kinds of files
on the --make command line; these will be compiled to objects as
normal and linked into the final executable.

GHC API change: I had to extend the Target type to include an optional
start phase, and also GHC.guessTarget now takes a (Maybe Phase) argument.

I thought this would be half an hour, in fact it took half a day, and
I still haven't documented it.  Sigh.

This commit combines three overlapping things:

1.  Make rebindable syntax work for do-notation. The idea
    here is that, in particular, (>>=) can have a type that
    has class constraints on its argument types, e.g.
       (>>=) :: (Foo m, Baz a) => m a -> (a -> m b) -> m b
    The consequence is that a BindStmt and ExprStmt must have
    individual evidence attached -- previously it was one
    batch of evidence for the entire Do
    
    Sadly, we can't do this for MDo, because we use bind at
    a polymorphic type (to tie the knot), so we still use one
    blob of evidence (now in the HsStmtContext) for MDo.
    
    For arrow syntax, the evidence is in the HsCmd.
    
    For list comprehensions, it's all built-in anyway.
    
    So the evidence on a BindStmt is only used for ordinary
    do-notation.

2.  Tidy up HsSyn.  In particular:

	- Eliminate a few "Out" forms, which we can manage
	without (e.g. 

	- It ought to be the case that the type checker only
	decorates the syntax tree, but doesn't change one
	construct into another.  That wasn't true for NPat,
	LitPat, NPlusKPat, so I've fixed that.

	- Eliminate ResultStmts from Stmt.  They always had
	to be the last Stmt, which led to awkward pattern
	matching in some places; and the benefits didn't seem
	to outweigh the costs.  Now each construct that uses
	[Stmt] has a result expression too (e.g. GRHS).


3.  Make 'deriving( Ix )' generate a binding for unsafeIndex,
    rather than for index.  This is loads more efficient.

    (This item only affects TcGenDeriv, but some of point (2)
    also affects TcGenDeriv, so it has to be in one commit.)

Cleanup the upsweep strategy in GHC.load.

Now it's hopefully clearer how we decide what modules to recompile,
and which are "stable" (not even looked at) during a reload.  See the
comments for details.

Also, I've taken some trouble to explicitly prune out things that
aren't required before a reload, which should reduce the memory
requirements for :reload in GHCi.  Currently I believe it keeps most
of the old program until the reload is complete, now it shouldn't
require any extra memory.

Complete the transition of -split-objs into a dynamic flag (looks like I
half-finished it in the last commit).

Also: complete the transition of -tmpdir into a dynamic flag, which
involves some rearrangement of code from SysTools into DynFlags.

Someday, initSysTools should move wholesale into initDynFlags, because
most of the state that it initialises is now part of the DynFlags
structure, and the rest could be moved in easily.

Flags cleanup.

Basically the purpose of this commit is to move more of the compiler's
global state into DynFlags, which is moving in the direction we need
to go for the GHC API which can have multiple active sessions
supported by a single GHC instance.

Before:

$ grep 'global_var' */*hs | wc -l
     78

After:

$ grep 'global_var' */*hs | wc -l
     27

Well, it's an improvement.  Most of what's left won't really affect
our ability to host multiple sessions.

Lots of static flags have become dynamic flags (yay!).  Notably lots
of flags that we used to think of as "driver" flags, like -I and -L,
are now dynamic.  The most notable static flags left behind are the
"way" flags, eg. -prof.  It would be nice to fix this, but it isn't
urgent.

On the way, lots of cleanup has happened.  Everything related to
static and dynamic flags lives in StaticFlags and DynFlags
respectively, and they share a common command-line parser library in
CmdLineParser.  The flags related to modes (--makde, --interactive
etc.) are now private to the front end: in fact private to Main
itself, for now.

Rationalise the BUILD,HOST,TARGET defines.

Recall that:

  - build is the platform we're building on
  - host is the platform we're running on
  - target is the platform we're generating code for

The change is that now we take these definitions as applying from the
point of view of the particular source code being built, rather than
the point of view of the whole build tree.

For example, in RTS and library code, we were previously testing the
TARGET platform.  But under the new rule, the platform on which this
code is going to run is the HOST platform.  TARGET only makes sense in
the compiler sources.

In practical terms, this means that the values of BUILD, HOST & TARGET
may vary depending on which part of the build tree we are in.

Actual changes:

 - new file: includes/ghcplatform.h contains platform defines for
   the RTS and library code.

 - new file: includes/ghcautoconf.h contains the autoconf settings
   only (HAVE_BLAH).  This is so that we can get hold of these
   settings independently of the platform defines when necessary
   (eg. in GHC).

 - ghcconfig.h now #includes both ghcplatform.h and ghcautoconf.h.

 - MachRegs.h, which is included into both the compiler and the RTS,
   now has to cope with the fact that it might need to test either
   _TARGET_ or _HOST_ depending on the context.

 - the compiler's Makefile now generates
     stage{1,2,3}/ghc_boot_platform.h
   which contains platform defines for the compiler.  These differ
   depending on the stage, of course: in stage2, the HOST is the
   TARGET of stage1.  This was wrong before.

 - The compiler doesn't get platform info from Config.hs any more.
   Previously it did (sometimes), but unless we want to generate
   a new Config.hs for each stage we can't do this.

 - GHC now helpfully defines *_{BUILD,HOST}_{OS,ARCH} automatically
   in CPP'd Haskell source.

 - ghcplatform.h defines *_TARGET_* for backwards compatibility
   (ghcplatform.h is included by ghcconfig.h, which is included by
   config.h, so code which still #includes config.h will get the TARGET
   settings as before).

 - The Users's Guide is updated to mention *_HOST_* rather than
   *_TARGET_*.

 - coding-style.html in the commentary now contains a section on
   platform defines.  There are further doc updates to come.

Thanks to Wolfgang Thaller for pointing me in the right direction.

----------------------------------------
     New Core invariant: keep case alternatives in sorted order
	----------------------------------------

We now keep the alternatives of a Case in the Core language in sorted
order.  Sorted, that is,
	by constructor tag	for DataAlt
	by literal		for LitAlt

The main reason is that it makes matching and equality testing more robust.
But in fact some lines of code vanished from SimplUtils.mkAlts.


WARNING: no change to interface file formats, but you'll need to recompile
your libraries so that they generate interface files that respect the
invariant.

--------------------------------
	Deal properly with dual-renaming
	--------------------------------

When comparing types and terms, and during matching, we are faced
with 
	\x.e1	~   \y.e2

There are many pitfalls here, and GHC has never done the job properly.
Now, at last it does, using a new abstraction VarEnv.RnEnv2.  See
comments there for how it works.

There are lots of consequential changes to use the new stuff, especially
in 
	types/Type (type comparison), 
	types/Unify (matching on types)
	coreSyn/CoreUtils (equality on expressions), 
	specialise/Rules (matching).

I'm not 100% certain of that I've covered all the bases, so let me
know if something unexpected happens after you update.  Maybe wait until
a nightly build has worked ok first!

------------------------------------
	Simplify the treatment of newtypes
	Complete hi-boot file consistency checking
	------------------------------------

In the representation of types, newtypes used to have a special constructor
all to themselves, very like TyConApp, called NewTcApp.    The trouble is
that means we have to *know* when a newtype is a newtype, and in an hi-boot
context we may not -- the data type might be declared as
	data T
in the hi-boot file, but as
	newtype T = ...
in the source file.  In GHCi, which accumulates stuff from multiple compiles,
this makes a difference.

So I've nuked NewTcApp.  Newtypes are represented using TyConApps again. This
turned out to reduce the total amount of code, and simplify the Type data type,
which is all to the good.


This commit also fixes a few things in the hi-boot consistency checking
stuff.