GitLab

For a long time, Template Haskell has fallen over in a very un-graceful
way (i.e. panic) even when it encounters a programmer error.  In particular,
when DsMeta converts HsSyn to TH syntax, it may find Haskell code that
TH does not understand. This should be reported as a normal programmer
error, not with a compiler panic!

Originally the desugarer was supposed to never generate error
messages, but this TH desugaring thing does make it do so.  And in
fact, for other reasons, the desugarer now uses the TcRnIf monad, the
common monad used by the renamer, typechecker, interface checker, and
desugarer.  

This patch completes the job, by 
 - allowing the desugarer to generate errors
 - re-plumbing the error handling to take account of this
 - making DsMeta use the new facilities to report error gracefully

Quite a few lines of code are touched, but nothing deep is going on.

Fixes Trac# 760.

See extensive comments with Note [INLINE and NOINLINE] in this file.

A consequence of my recent meddling with hs-boot files is that GHC is
more picky about the correpondence between the hs-boot file and the hs file.
In particular, you must use the same type synonyms.

This patche fixes up GHC's own hs-boot files to match the restriction.

The problem with tagToEnum# is that it is not overloaded (in the
Haskell sense) but you are only supposed to apply it to a TyCon
that is an enumeration (isEnumerationTyCon).

The Real Way to do this is to have some special kind of type constraint
for the purpose, but that is wild overkill. So this patch adds a small
rather ad-hoc check to TcExpr.instFun.  Crude, simple, but it works fine.

Fixes Trac #786
Test is tcfail164

argToPat is a crucial function for SpecConstr, because it decides
what patterns are worth specialising.  I was being much too gung-ho about
constants.  This patch makes it much better.

This refactoring ensures that when mkAtomicArgs adds new bindings,
it does so using completeNonRecX, which adds unfoldings etc.  More
modular, and saves passes too.

(This was important when getting rules to work right.  We want tob
fire a rule as soon as possible, taking into account all inlinings,
else a less-good rule applies.  That's what I found when doing 
stream fusion anyway.)

Regardless, this is an improvement.

I have spent altogether too long on my attempt to avoid case-of-case
in situations where it is a Bad Thing.  All the action is in the
case for mkDupableAlt that handles cases with a single alternative.

I've added rather extensive comments, and it finally seems to be working
more or less right.  If you compile (say) GHC/Real.o you'll see quite a
few case-of-cases remain (which didn't happen before), and they mostly look
pretty sensible to me.

Faced with
	case x of y { (a,b) -> rhs }

where x is bound to (c,d), we were generating
	
	let y = (c,d) in rhs

and thenn hoping to get rid of the y binding by CSE or some such.  It's
better simply not to build it in the first place, by generating

	let y = x in rhs

This patch does the job.

I was forgetting the non-pattern-matched type args of a constructor.

Previously we checked the form of the arguments of a RULE lhs, to 
ensure that they were simple applications. There was no good reason
for that, save to prevent you writing LHSs that were unlikely to match.

And Don Stewart found he wanted to do something we didn't allow (a section,
I think).  So I have just disabled the check.

For some reason, in 6.5 the manual said you could put a class decl in
an interface file, but not an instance decl; whereas the implementation
was exactly the othe way round.

This patch makes it possible to put *both* class and instance decls
in an interface file. 

I also did a bit of re-factoring; comparing the declarations in the
hs-boot and hs file is now done by converting to IfaceSyn, because we
have good comparison operations for IfaceSyn already implemented.
This fixed a bug that previously let through an inconsistent declaration 
of a data type.

The remaining infelicity concerns "abstract" TyCons.  They are a bit
of a hack anyway; and Classes are not handled in the same way.  Need
to think about this, but I think it's probably ok as it stands.

Trac #864 suggested a derivable type class with a higher-rank method.

In principle this is quite do-able, but in practice the mechanism works
by generating source code and then doing type inference.  To make this work
with higher-rank types would require impredicative polymorphism. And we 
do have that, so it could probably be made to work by generating (source-level)
type annotations.  But it's real work, so I'm settling for generating a
decent error message rather than crashing.

Roman inspired me to beef up SpecConstr to deal with
a) constant arguments
b) lambda arguments

This is described in elaborate comments in the file:
 	Note [Specialising for constant parameters]
	Note [Specialising for lambda parameters]

I also took the opportunity to fix the usage analysis done by
SpecConstr, which was only handling the top-level correctly.
Now it does nesting too.

These two typo-like bugs have been there for a long time!

  One concerns the selection of overlapping rules, 
  which was back to front

  The other was name-lining-up bug in the Case case of matching

This patch also arranges to export matchN. 
  (Not a good name, but still!)

Roman found that GHC was duplicating continuations that arose (essentially)
from uses of 'seq', or strict constructors.  This fixes the problem;
see the comments mkDupableCont (the Select case with a single alternative).

I'm a little concerned that this may also miss useful case-of-case
tranformations, so I'd like to know if anyone finds that this patch
makes performance worse.

To make it a bit more gung-ho, one could check for all the binders
being dead, before choosing this new, conservative alternative.

Consider
	x = case y of { True -> (p,q); ... }

The occurrence analyser was marking p,q as 'Many', because they args
of a constructor in an RhsCtxt.  But actually they aren't in a RhsCtxt,
and in this case it's better to inline.

exprIsCheap is meant to return True iff it's ok to push the expression
inside a lambda.  But the previous version would return True of a nested
construtor application like (1:2:3:[]), which isn't right.

This patch re-factors the code somewhat, and fixes the bug.

Fixes Trac #863.
Test is tcfail162

When adding the experimental -fmono-pat-binds, I forgot to check
for type signatures of the now-monomorphic patterns.  This patch
completes the job.

I documented the design too:
   http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/MonomorphicPatternBindings

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.