X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=ghc%2Fcompiler%2FNOTES;h=4c2b7024d7a7e7113226b2e8812f1210b0415c4e;hb=affe92132329afa642bc83d74d5b07d14187e968;hp=67b4c623b9135c8ba91eca3a4ce5295df393ce8f;hpb=bc83a34d48b33181fc06365ff2a67ee8d8e568cb;p=ghc-hetmet.git

diff --git a/ghc/compiler/NOTES b/ghc/compiler/NOTES
index 67b4c62..4c2b702 100644
--- a/ghc/compiler/NOTES
+++ b/ghc/compiler/NOTES
@@ -1,3 +1,17 @@
+* Can a scoped type variable denote a type scheme?
+
+* Relation between separate type sigs and pattern type sigs
+f :: forall a. a->a
+f :: b->b = e   -- No: monomorphic
+
+f :: forall a. a->a
+f :: forall a. a->a  -- OK
+
+f :: forall a. [a] -> [a]
+f :: forall b. b->b = e  ???
+
+
+-------------------------------
 NB: all floats are let-binds, but some non-rec lets
     may be unlifted (with RHS ok-for-speculation)
 
@@ -30,7 +44,7 @@ simplNonRecBind:	[was simplBeta]
     else
 	completeLazyBind
 
-simplRecPair:	[binder already simplified, but not its IdInfo]
+simplLazyBind:	[binder already simplified, but not its IdInfo]
 	  	[used for both rec and top-lvl non-rec]
 		[must not be strict/unboxed; case not allowed]
   - check for PreInlineUnconditionally
@@ -54,3 +68,57 @@ completeLazyBind: 	[given a simplified RHS]
 
   - add unfolding [this is the only place we add an unfolding]
     add arity
+
+
+
+Right hand sides and arguments
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In many ways we want to treat 
+	(a) the right hand side of a let(rec), and 
+	(b) a function argument
+in the same way.  But not always!  In particular, we would
+like to leave these arguments exactly as they are, so they
+will match a RULE more easily.
+	
+	f (g x, h x)	
+	g (+ x)
+
+It's harder to make the rule match if we ANF-ise the constructor,
+or eta-expand the PAP:
+
+	f (let { a = g x; b = h x } in (a,b))
+	g (\y. + x y)
+
+On the other hand if we see the let-defns
+
+	p = (g x, h x)
+	q = + x
+
+then we *do* want to ANF-ise and eta-expand, so that p and q
+can be safely inlined.   
+
+Even floating lets out is a bit dubious.  For let RHS's we float lets
+out if that exposes a value, so that the value can be inlined more vigorously.
+For example
+
+	r = let x = e in (x,x)
+
+Here, if we float the let out we'll expose a nice constructor. We did experiments
+that showed this to be a generally good thing.  But it was a bad thing to float
+lets out unconditionally, because that meant they got allocated more often.
+
+For function arguments, there's less reason to expose a constructor (it won't
+get inlined).  Just possibly it might make a rule match, but I'm pretty skeptical.
+So for the moment we don't float lets out of function arguments either.
+
+
+Eta expansion
+~~~~~~~~~~~~~~
+For eta expansion, we want to catch things like
+
+	case e of (a,b) -> \x -> case a of (p,q) -> \y -> r
+
+If the \x was on the RHS of a let, we'd eta expand to bring the two
+lambdas together.  And in general that's a good thing to do.  Perhaps
+we should eta expand wherever we find a (value) lambda?  Then the eta
+expansion at a let RHS can concentrate solely on the PAP case.