From: simonpj@microsoft.com <unknown>
Date: Tue, 6 Feb 2007 12:15:52 +0000 (+0000)
Subject: Do more wild-carding in SpecConstr; I'm not quite sure about this, but it does no... 
X-Git-Url: http://git.megacz.com/?p=ghc-hetmet.git;a=commitdiff_plain;h=45ee1c1b1c0fab2e8ac8ad584bee0fc6087e5711

Do more wild-carding in SpecConstr; I'm not quite sure about this, but it does no harm
---

diff --git a/compiler/specialise/SpecConstr.lhs b/compiler/specialise/SpecConstr.lhs
index 1cdeec1..b5ae45f 100644
--- a/compiler/specialise/SpecConstr.lhs
+++ b/compiler/specialise/SpecConstr.lhs
@@ -986,12 +986,18 @@ argToPat in_scope con_env (Var v) arg_occ
     isValueUnfolding (idUnfolding v)			-- (b)
   = return (True, Var v)
 
+{-	I'm really not sure what this comment means
+	And by not wild-carding we tend to get forall'd 
+	variables that are in soope, which in turn can
+	expose the weakness in let-matching
+	See Note [Matching lets] in Rules
   -- Check for a variable bound inside the function. 
   -- Don't make a wild-card, because we may usefully share
   --	e.g.  f a = let x = ... in f (x,x)
   -- NB: this case follows the lambda and con-app cases!!
 argToPat in_scope con_env (Var v) arg_occ
   = return (False, Var v)
+-}
 
   -- The default case: make a wild-card
 argToPat in_scope con_env arg arg_occ