X-Git-Url: http://git.megacz.com/?p=ghc-hetmet.git;a=blobdiff_plain;f=compiler%2FNOTES;h=645d27eaed6d638dde2db7d63d95f09aacc26fdb;hp=8c6275000813987394a5b8a255f9787b25422595;hb=18691d440f90a3dff4ef538091c886af505e5cf5;hpb=0065d5ab628975892cea1ec7303f968c3338cbe1

diff --git a/compiler/NOTES b/compiler/NOTES
index 8c62750..645d27e 100644
--- a/compiler/NOTES
+++ b/compiler/NOTES
@@ -1,3 +1,40 @@
+More type functions
+~~~~~~~~~~~~~~~~~~~
+* Allow {tv = TYPE ty) as a non-rec binding in Core
+* Use this to make equality constraints more uniform
+* Can a Dict can contain an EqPred?  
+  How does that differ from an EqInst?
+* Make DictBinds into Core
+
+* In zonking, do we need to zonk the kinds of coercion variables?
+
+Type functions
+~~~~~~~~~~~~~~
+* A Given inst should be a CoVar, not a coercion
+
+* finaliseEqInst should not need to call zonk
+
+* Why do we need fromGivenEqDict?  How could we construct 	
+	a Dict that had an EqPred?
+	newDictBndr should make an EqInst directly
+
+* tc_co should be accessed only inside Inst
+
+* Inst.mkImplicTy needs a commment about filtering out EqInsts
+  How *do* we deal with wanted equalities?
+
+* Inst.instType behaves inconsistently for EqInsts: it should
+  return an EqPred, like the instType' hack in pprDictsTheta
+
+  Consequences: adjust the uses of instType in TcSimplify
+
+* tcDeref* functions are unused, except in tcGenericNormalizeFamInst, when
+  we can equally well use TcMType.lookupTcTyVar
+
+* Coercion.mkEqPredCoI looks very peculiar.
+
+
+
 
 -------------------------
 *** unexpected failure for jtod_circint(opt)
@@ -46,18 +83,6 @@ Cmm parser notes
   do we need to assign to Node?
 
 
--------------------------
-* 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)
@@ -118,46 +143,6 @@ completeLazyBind: 	[given a simplified RHS]
 
 
 
-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
 ~~~~~~~~~~~~~~