GitLab

Work around various problems caused by some of the monadification patches
not being applied.

Remove the now-redundant "const-dicts" field in SpecPrag

In dsBinds, abstract over constant dictionaries in the RULE.
This avoids the creation of a redundant, duplicate, rule later
in the Specialise pass, which was happening before.

There should be no effect on performance either way, just less
duplicated code, and the compiler gets a little simpler.

re-recording to avoid new conflicts was too hard, so I just put it
all in one big patch :-(  (besides, some of the changes depended on
each other.)  Here are what the component patches were:

Fri Dec 28 11:02:55 EST 2007  Isaac Dupree <id@isaac.cedarswampstudios.org>
  * document BreakArray better

Fri Dec 28 11:39:22 EST 2007  Isaac Dupree <id@isaac.cedarswampstudios.org>
  * properly ifdef BreakArray for GHCI

Fri Jan  4 13:50:41 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
  * change ifs on __GLASGOW_HASKELL__ to account for... (#1405)
  for it not being defined. I assume it being undefined implies
  a compiler with relatively modern libraries but without most
  unportable glasgow extensions.

Fri Jan  4 14:21:21 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
  * MyEither-->EitherString to allow Haskell98 instance

Fri Jan  4 16:13:29 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
  * re-portabilize Pretty, and corresponding changes

Fri Jan  4 17:19:55 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
  * Augment FastTypes to be much more complete

Fri Jan  4 20:14:19 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
  * use FastFunctions, cleanup FastString slightly

Fri Jan  4 21:00:22 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
  * Massive de-"#", mostly Int# --> FastInt (#1405)

Fri Jan  4 21:02:49 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
  * miscellaneous unnecessary-extension-removal

Sat Jan  5 19:30:13 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
  * add FastFunctions

This patch (which is part of the fix for Trac #2018) makes coercion variables
be handled more uniformly.  Generally, they are treated like dictionaries
in the type checker, not like type variables, but in a couple of places we
were treating them like type variables.  Also when zonking we should use
zonkDictBndr not zonkIdBndr.

  This patch implements generalised list comprehensions, as described in 
  the paper "Comprehensive comprehensions" (Peyton Jones & Wadler, Haskell
  Workshop 2007).  If you don't use the new comprehensions, nothing
  should change.
  
  The syntax is not exactly as in the paper; see the user manual entry 
  for details.
  
  You need an accompanying patch to the base library for this stuff 
  to work.
  
  The patch is the work of Max Bolingbroke [batterseapower@hotmail.com], 
  with some advice from Simon PJ.
  
  The related GHC Wiki page is 
    http://hackage.haskell.org/trac/ghc/wiki/SQLLikeComprehensions 

This doesn't fix the root cause of the bug, but it makes the report
more civilised, and points to further info.

This patch fixes Trac #1643, where Lennart found that GHC was generating
code with unnecessary dictionaries.  The reason was that we were getting
an implication constraint floated out of an INLINE (actually an instance
decl), and the implication constraint therefore wasn't inlined even 
though it was used only once (but inside the INLINE).  Thus we were 
getting:

	ic = \d -> <stuff>
	foo = _inline_me_ (...ic...)

Then 'foo' gets inlined in lots of places, but 'ic' now looks a bit 
big.  

But implication constraints should *always* be inlined; they are just
artefacts of the constraint simplifier.

This patch solves the problem, by adding a WpInline form to the HsWrap
type. 

An AbsBinds abstrats over evidence, and the evidence can be both
Dicts (class constraints, implicit parameters) and EqInsts (equality
constraints).  So we need to
  - use varType rather than idType
  - use instToVar rather than instToId
  - use zonkDictBndr rather than zonkIdBndr in zonking

It actually all worked before, but gave warnings.

This patch implements three new features:
* view patterns (syntax: expression -> pat in a pattern)
* working versions of record wildcards and record puns
See the manual for detailed descriptions.

Other minor observable changes:
* There is a check prohibiting local fixity declarations
  when the variable being fixed is not defined in the same let
* The warn-unused-binds option now reports warnings for do and mdo stmts

Implementation notes: 

* The pattern renamer is now in its own module, RnPat, and the
implementation is now in a CPS style so that the correct context is
delivered to pattern expressions.

* These features required a fairly major upheaval to the renamer.
Whereas the old version used to collect up all the bindings from a let
(or top-level, or recursive do statement, ...) and put them into scope
before renaming anything, the new version does the collection as it
renames.  This allows us to do the right thing with record wildcard
patterns (which need to be expanded to see what names should be
collected), and it allows us to implement the desired semantics for view
patterns in lets.  This change had a bunch of domino effects brought on
by fiddling with the top-level renaming.

* Prior to this patch, there was a tricky bug in mkRecordSelId in HEAD,
which did not maintain the invariant necessary for loadDecl.  See note
[Tricky iface loop] for details.

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.

1. Record disambiguation (-fdisambiguate-record-fields)

In record construction and pattern matching (although not
in record updates) it is clear which field name is intended
even if there are several in scope.  This extension uses
the constructor to disambiguate.  Thus
	C { x=3 }
uses the 'x' field from constructor C (assuming there is one)
even if there are many x's in scope.


2. Record punning (-frecord-puns)

In a record construction or pattern match or update you can 
omit the "=" part, thus
	C { x, y }
This is just syntactic sugar for
	C { x=x, y=y }


3.  Dot-dot notation for records (-frecord-dot-dot)

In record construction or pattern match (but not update) 
you can use ".." to mean "all the remaining fields".  So

	C { x=v, .. }

means to fill in the remaining fields to give

	C { x=v, y=y }

(assuming C has fields x and y).  This might reasonably
considered very dodgy stuff.  For pattern-matching it brings
into scope a bunch of things that are not explictly mentioned;
and in record construction it just picks whatver 'y' is in
scope for the 'y' field.   Still, Lennart Augustsson really
wants it, and it's a feature that is extremely easy to explain.


Implementation
~~~~~~~~~~~~~~
I thought of using the "parent" field in the GlobalRdrEnv, but
that's really used for import/export and just isn't right for this.
For example, for import/export a field is a subordinate of the *type
constructor* whereas here we need to know what fields belong to a
particular *data* constructor.

The main thing is that we need to map a data constructor to its
fields, and we need to do so in the renamer.   For imported modules
it's easy: just look in the imported TypeEnv.  For the module being
compiled, we make a new field tcg_field_env in the TcGblEnv.
The important functions are
	RnEnv.lookupRecordBndr
	RnEnv.lookupConstructorFields

There is still a significant infelicity in the way the renamer
works on patterns, which I'll tackle next.


I also did quite a bit of refactoring in the representation of
record fields (mainly in HsPat).***END OF DESCRIPTION***

Place the long patch description above the ***END OF DESCRIPTION*** marker.
The first line of this file will be the patch name.


This patch contains the following changes:

M ./compiler/deSugar/Check.lhs -3 +5
M ./compiler/deSugar/Coverage.lhs -6 +7
M ./compiler/deSugar/DsExpr.lhs -6 +13
M ./compiler/deSugar/DsMeta.hs -8 +8
M ./compiler/deSugar/DsUtils.lhs -1 +1
M ./compiler/deSugar/MatchCon.lhs -2 +2
M ./compiler/hsSyn/Convert.lhs -3 +3
M ./compiler/hsSyn/HsDecls.lhs -9 +25
M ./compiler/hsSyn/HsExpr.lhs -13 +3
M ./compiler/hsSyn/HsPat.lhs -25 +63
M ./compiler/hsSyn/HsUtils.lhs -3 +3
M ./compiler/main/DynFlags.hs +6
M ./compiler/parser/Parser.y.pp -13 +17
M ./compiler/parser/RdrHsSyn.lhs -16 +18
M ./compiler/rename/RnBinds.lhs -2 +2
M ./compiler/rename/RnEnv.lhs -22 +82
M ./compiler/rename/RnExpr.lhs -34 +12
M ./compiler/rename/RnHsSyn.lhs -3 +2
M ./compiler/rename/RnSource.lhs -50 +78
M ./compiler/rename/RnTypes.lhs -50 +84
M ./compiler/typecheck/TcExpr.lhs -18 +18
M ./compiler/typecheck/TcHsSyn.lhs -20 +21
M ./compiler/typecheck/TcPat.lhs -8 +6
M ./compiler/typecheck/TcRnMonad.lhs -6 +15
M ./compiler/typecheck/TcRnTypes.lhs -2 +11
M ./compiler/typecheck/TcTyClsDecls.lhs -3 +4
M ./docs/users_guide/flags.xml +7
M ./docs/users_guide/glasgow_exts.xml +42

This fixes Trac #1204.  There's quite a delicate interaction of
GADTs, type families, records, and in particular record updates.

Test is indexed-types/should_compile/Records.hs

	MERGE TO STABLE

This patch fixes Trac #1287.  

The problem is described in Note [Unused spec binders] in DsBinds.

At the same time I realised that the error messages in DsBinds.dsPrag
were being given the location of the *binding* not the *pragma*.
So I've fixed that too.

The class is named IsString with the single method fromString.
Overloaded strings work the same way as overloaded numeric literals.
In expressions a string literals gets a fromString applied to it.
In a pattern there will be an equality comparison with the fromString:ed literal.

Use -foverloaded-strings to enable this extension.
 

Adding a {-# GENERATED "SourceFile" SourceSpan #-} <expr> pragma.
This will be used to generate coverage for tool generated (or quoted) code.
The pragma states the the expression was generated/quoted from the stated
source file and source span.

GHC's code generator can only enter a closure if it's guaranteed
not to be a function.  In the Dynamic module, we were using the 
type (forall a.a) as the type to which the dynamic type was unsafely
cast:
	type Obj = forall a.a

Gut alas this polytype was sometimes instantiated to (), something 
like this (it only bit when profiling was enabled)
	let y::() = dyn ()
	in (y `cast` ..) p q
As a result, an ASSERT in ClosureInfo fired (hooray).

I've tided this up by making a new, primitive, lifted type Any, and
arranging that Dynamic uses Any, thus:
	type Obj = ANy

While I was at it, I also arranged that when the type checker instantiates 
un-constrained type variables, it now instantiates them to Any, not ()
	e.g.  length Any []

[There remains a Horrible Hack when we want Any-like things at arbitrary 
kinds.  This essentially never happens, but see comments with 
TysPrim.mkAnyPrimTyCon.]

Anyway, this fixes Trac #905

Linear implicit parameters have been in GHC quite a while,
but we decided they were a mis-feature and scheduled them for
removal.  This patch does the job.

Mon Sep 18 14:43:22 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Complete the evidence generation for GADTs
  Sat Aug  5 21:39:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Complete the evidence generation for GADTs
    Thu Jul 13 17:18:07 EDT 2006  simonpj@microsoft.com
      
      This patch completes FC evidence generation for GADTs.
      
      It doesn't work properly yet, because part of the compiler thinks
      	(t1 :=: t2) => t3
      is represented with FunTy/PredTy, while the rest thinks it's represented
      using ForAllTy.  Once that's done things should start to work.

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

Fri Aug 11 13:53:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Remove argument variance info of tycons
  - Following SPJ's suggestion, this patch removes the variance information from
    type constructors.  This information was computed, but never used.
  
  ** WARNING: This patch changes the format of interface files **
  **          You will need to rebuild from scratch.           **

Wed Jul 19 09:55:27 EDT 2006  kevind@bu.edu

This is a long-standing bug really (Trac #900).  The poly_id passed
to tcSpecPrag should be zonked, else it calls tcSubExp with a non-zonked
type; but that contradicts the latter's invariant.

I ended up doing a bit of refactoring too.  The extra lines are 
comments I think; the code line count is reduced.

Test is tc212.hs

See #815

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.

This patch is a slightly-unsatisfactory fix to desugaring unboxed
tuples; it fixes ds057 which has been failing for some time.

Unsatisfactory because rather ad hoc -- but that applies to lots
of the unboxed tuple stuff. 

This commit adds bang-patterns, 
	enabled by -fglasgow-exts or -fbang-patterns
	diabled by -fno-bang-patterns

The idea is described here
	http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/BangPatterns

We must record the type of a TuplePat after typechecking, just like a ConPatOut,
so that desugaring works correctly for GADTs. See comments with the declaration
of HsPat.TuplePat, and test gadt15

This very large commit adds impredicativity to GHC, plus
numerous other small things.
  
*** WARNING: I have compiled all the libraries, and
***	     a stage-2 compiler, and everything seems
***	     fine.  But don't grab this patch if you 
***	     can't tolerate a hiccup if something is
***	     broken.
  
The big picture is this:

a) GHC handles impredicative polymorphism, as described in the
   "Boxy types: type inference for higher-rank types and
   impredicativity" paper

b) GHC handles GADTs in the new simplified (and very sligtly less
   epxrssive) way described in the
   "Simple unification-based type inference for GADTs" paper

  
But there are lots of smaller changes, and since it was pre-Darcs
they are not individually recorded.
  
Some things to watch out for:
  
c)   The story on lexically-scoped type variables has changed, as per
     my email.  I append the story below for completeness, but I 
     am still not happy with it, and it may change again.  In particular,
     the new story does not allow a pattern-bound scoped type variable
     to be wobbly, so (\(x::[a]) -> ...) is usually rejected.  This is
     more restrictive than before, and we might loosen up again.
  
d)   A consequence of adding impredicativity is that GHC is a bit less
     gung ho about converting automatically between
  	(ty1 -> forall a. ty2)    and    (forall a. ty1 -> ty2)
     In particular, you may need to eta-expand some functions to make
     typechecking work again.
   
     Furthermore, functions are now invariant in their argument types,
     rather than being contravariant.  Again, the main consequence is
     that you may occasionally need to eta-expand function arguments when
     using higher-rank polymorphism.
  

Please test, and let me know of any hiccups


Scoped type variables in GHC
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	January 2006

0) Terminology.
   
   A *pattern binding* is of the form
	pat = rhs

   A *function binding* is of the form
	f pat1 .. patn = rhs

   A binding of the formm
	var = rhs
   is treated as a (degenerate) *function binding*.


   A *declaration type signature* is a separate type signature for a
   let-bound or where-bound variable:
	f :: Int -> Int

   A *pattern type signature* is a signature in a pattern: 
	\(x::a) -> x
	f (x::a) = x

   A *result type signature* is a signature on the result of a
   function definition:
	f :: forall a. [a] -> a
	head (x:xs) :: a = x

   The form
	x :: a = rhs
   is treated as a (degnerate) function binding with a result
   type signature, not as a pattern binding.

1) The main invariants:

     A) A lexically-scoped type variable always names a (rigid)
 	type variable (not an arbitrary type).  THIS IS A CHANGE.
        Previously, a scoped type variable named an arbitrary *type*.

     B) A type signature always describes a rigid type (since
	its free (scoped) type variables name rigid type variables).
	This is also a change, a consequence of (A).

     C) Distinct lexically-scoped type variables name distinct
	rigid type variables.  This choice is open; 

2) Scoping

2(a) If a declaration type signature has an explicit forall, those type
   variables are brought into scope in the right hand side of the 
   corresponding binding (plus, for function bindings, the patterns on
   the LHS).  
	f :: forall a. a -> [a]
	f (x::a) = [x :: a, x]
   Both occurences of 'a' in the second line are bound by 
   the 'forall a' in the first line

   A declaration type signature *without* an explicit top-level forall
   is implicitly quantified over all the type variables that are
   mentioned in the type but not already in scope.  GHC's current
   rule is that this implicit quantification does *not* bring into scope
   any new scoped type variables.
	f :: a -> a
	f x = ...('a' is not in scope here)...
   This gives compatibility with Haskell 98

2(b) A pattern type signature implicitly brings into scope any type
   variables mentioned in the type that are not already into scope.
   These are called *pattern-bound type variables*.
	g :: a -> a -> [a]
	g (x::a) (y::a) = [y :: a, x]
   The pattern type signature (x::a) brings 'a' into scope.
   The 'a' in the pattern (y::a) is bound, as is the occurrence on 
   the RHS.  

   A pattern type siganture is the only way you can bring existentials 
   into scope.
	data T where
	  MkT :: forall a. a -> (a->Int) -> T

	f x = case x of
		MkT (x::a) f -> f (x::a)

2a) QUESTION
	class C a where
	  op :: forall b. b->a->a

	instance C (T p q) where
	  op = <rhs>
    Clearly p,q are in scope in <rhs>, but is 'b'?  Not at the moment.
    Nor can you add a type signature for op in the instance decl.
    You'd have to say this:
	instance C (T p q) where
	  op = let op' :: forall b. ...
	           op' = <rhs>
	       in op'

3) A pattern-bound type variable is allowed only if the pattern's
   expected type is rigid.  Otherwise we don't know exactly *which*
   skolem the scoped type variable should be bound to, and that means
   we can't do GADT refinement.  This is invariant (A), and it is a 
   big change from the current situation.

	f (x::a) = x	-- NO; pattern type is wobbly
	
	g1 :: b -> b
	g1 (x::b) = x	-- YES, because the pattern type is rigid

	g2 :: b -> b
	g2 (x::c) = x	-- YES, same reason

	h :: forall b. b -> b
	h (x::b) = x	-- YES, but the inner b is bound

	k :: forall b. b -> b
	k (x::c) = x	-- NO, it can't be both b and c

3a) You cannot give different names for the same type variable in the same scope
    (Invariant (C)):

	f1 :: p -> p -> p		-- NO; because 'a' and 'b' would be
	f1 (x::a) (y::b) = (x::a)	--     bound to the same type variable

	f2 :: p -> p -> p		-- OK; 'a' is bound to the type variable
	f2 (x::a) (y::a) = (x::a)	--     over which f2 is quantified
					-- NB: 'p' is not lexically scoped

	f3 :: forall p. p -> p -> p	-- NO: 'p' is now scoped, and is bound to
	f3 (x::a) (y::a) = (x::a)	--     to the same type varialble as 'a'

	f4 :: forall p. p -> p -> p	-- OK: 'p' is now scoped, and its occurences
	f4 (x::p) (y::p) = (x::p)	--     in the patterns are bound by the forall


3b) You can give a different name to the same type variable in different
    disjoint scopes, just as you can (if you want) give diferent names to 
    the same value parameter

	g :: a -> Bool -> Maybe a
	g (x::p) True  = Just x  :: Maybe p
	g (y::q) False = Nothing :: Maybe q

3c) Scoped type variables respect alpha renaming. For example, 
    function f2 from (3a) above could also be written:
	f2' :: p -> p -> p
	f2' (x::b) (y::b) = x::b
   where the scoped type variable is called 'b' instead of 'a'.


4) Result type signatures obey the same rules as pattern types signatures.
   In particular, they can bind a type variable only if the result type is rigid

	f x :: a = x	-- NO

	g :: b -> b
	g x :: b = x	-- YES; binds b in rhs

5) A *pattern type signature* in a *pattern binding* cannot bind a 
   scoped type variable

	(x::a, y) = ...		-- Legal only if 'a' is already in scope

   Reason: in type checking, the "expected type" of the LHS pattern is
   always wobbly, so we can't bind a rigid type variable.  (The exception
   would be for an existential type variable, but existentials are not
   allowed in pattern bindings either.)
 
   Even this is illegal
	f :: forall a. a -> a
	f x = let ((y::b)::a, z) = ... 
	      in 
   Here it looks as if 'b' might get a rigid binding; but you can't bind
   it to the same skolem as a.

6) Explicitly-forall'd type variables in the *declaration type signature(s)*
   for a *pattern binding* do not scope AT ALL.

	x :: forall a. a->a	  -- NO; the forall a does 
	Just (x::a->a) = Just id  --     not scope at all

	y :: forall a. a->a
	Just y = Just (id :: a->a)  -- NO; same reason

   THIS IS A CHANGE, but one I bet that very few people will notice.
   Here's why:

	strange :: forall b. (b->b,b->b)
	strange = (id,id)

	x1 :: forall a. a->a
	y1 :: forall b. b->b
	(x1,y1) = strange

    This is legal Haskell 98 (modulo the forall). If both 'a' and 'b'
    both scoped over the RHS, they'd get unified and so cannot stand
    for distinct type variables. One could *imagine* allowing this:
   
	x2 :: forall a. a->a
	y2 :: forall a. a->a
	(x2,y2) = strange

    using the very same type variable 'a' in both signatures, so that
    a single 'a' scopes over the RHS.  That seems defensible, but odd,
    because though there are two type signatures, they introduce just
    *one* scoped type variable, a.

7) Possible extension.  We might consider allowing
	\(x :: [ _ ]) -> <expr>
    where "_" is a wild card, to mean "x has type list of something", without
    naming the something.

Add a new pragma: SPECIALISE INLINE

This amounts to adding an INLINE pragma to the specialised version
of the function.  You can add phase stuff too (SPECIALISE INLINE [2]),
and NOINLINE instead of INLINE.

The reason for doing this is to support inlining of type-directed
recursive functions.  The main example is this:

  -- non-uniform array type
  data Arr e where
    ArrInt  :: !Int -> ByteArray#       -> Arr Int
    ArrPair :: !Int -> Arr e1 -> Arr e2 -> Arr (e1, e2)

  (!:) :: Arr e -> Int -> e
  {-# SPECIALISE INLINE (!:) :: Arr Int -> Int -> Int #-}
  {-# SPECIALISE INLINE (!:) :: Arr (a, b) -> Int -> (a, b) #-}
  ArrInt  _ ba    !: (I# i) = I# (indexIntArray# ba i)
  ArrPair _ a1 a2 !: i      = (a1 !: i, a2 !: i)

If we use (!:) at a particular array type, we want to inline (:!),
which is recursive, until all the type specialisation is done.


On the way I did a bit of renaming and tidying of the way that
pragmas are carried, so quite a lot of files are touched in a
fairly trivial way.

It turned out that doing all binding dependency analysis in the typechecker
meant that the renamer's unused-binding error messages got worse.  So now
I've put the first dep anal back into the renamer, while the second (which
is specific to type checking) remains in the type checker.

I've also made the pretty printer sort the decls back into source order
before printing them (except with -dppr-debug).

Fixes rn041.