Comments only, esp about RecStmts
authorsimonpj@microsoft.com <unknown>
Thu, 26 Nov 2009 16:32:41 +0000 (16:32 +0000)
committersimonpj@microsoft.com <unknown>
Thu, 26 Nov 2009 16:32:41 +0000 (16:32 +0000)
compiler/hsSyn/HsExpr.lhs
compiler/stranal/WorkWrap.lhs

index 6530ad6..f638f65 100644 (file)
@@ -857,12 +857,9 @@ data StmtLR idL idR
      , recS_rec_ids :: [idR]   -- Ditto, but these variables are the "recursive" ones,
                               -- that are used before they are bound in the stmts of
                               -- the RecStmt. 
      , recS_rec_ids :: [idR]   -- Ditto, but these variables are the "recursive" ones,
                               -- that are used before they are bound in the stmts of
                               -- the RecStmt. 
-
        -- An Id can be in both groups
        -- Both sets of Ids are (now) treated monomorphically
        -- An Id can be in both groups
        -- Both sets of Ids are (now) treated monomorphically
-       -- The only reason they are separate is becuase the DsArrows 
-       -- code uses them separately, and I don't understand it well
-       -- enough to change it
+       -- See Note [How RecStmt works] for why they are separate
 
        -- Rebindable syntax
      , recS_bind_fn :: SyntaxExpr idR -- The bind function
 
        -- Rebindable syntax
      , recS_bind_fn :: SyntaxExpr idR -- The bind function
@@ -912,25 +909,30 @@ Array comprehensions are handled like list comprehensions -=chak
 Note [How RecStmt works]
 ~~~~~~~~~~~~~~~~~~~~~~~~
 Example:
 Note [How RecStmt works]
 ~~~~~~~~~~~~~~~~~~~~~~~~
 Example:
-        HsDo [ BindStmt x ex
+   HsDo [ BindStmt x ex
 
 
-             , RecStmt [a::forall a. a -> a, b]
-                       [a::Int -> Int,       c]
-                       [ BindStmt b (return x)
-                       , LetStmt a = ea
-                       , BindStmt c ec ]
+        , RecStmt { recS_rec_ids   = [a, c]
+                  , recS_stmts            = [ BindStmt b (return (a,c))
+                                    , LetStmt a = ...b...
+                                    , BindStmt c ec ]
+                  , recS_later_ids = [a, b]
 
 
-             , return (a b) ]
+        , return (a b) ]
 
 Here, the RecStmt binds a,b,c; but
   - Only a,b are used in the stmts *following* the RecStmt,
 
 Here, the RecStmt binds a,b,c; but
   - Only a,b are used in the stmts *following* the RecStmt,
-        This 'a' is *polymorphic'
   - Only a,c are used in the stmts *inside* the RecStmt
         *before* their bindings
   - Only a,c are used in the stmts *inside* the RecStmt
         *before* their bindings
-        This 'a' is monomorphic
 
 
-Nota Bene: the two a's have different types, even though they
-have the same Name.
+Why do we need *both* rec_ids and later_ids?  For monads they could be
+combined into a single set of variables, but not for arrows.  That
+follows from the types of the respective feedback operators:
+
+       mfix :: MonadFix m => (a -> m a) -> m a
+       loop :: ArrowLoop a => a (b,d) (c,d) -> a b c
+
+* For mfix, the 'a' covers the union of the later_ids and the rec_ids 
+* For 'loop', 'c' is the later_ids and 'd' is the rec_ids 
 
 Note [Typing a RecStmt]
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 Note [Typing a RecStmt]
 ~~~~~~~~~~~~~~~~~~~~~~~
index 4e7a494..125d5de 100644 (file)
@@ -156,7 +156,7 @@ The only reason this is monadised is for the unique supply.
 Note [Don't w/w inline things (a)]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 It's very important to refrain from w/w-ing an INLINE function
 Note [Don't w/w inline things (a)]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 It's very important to refrain from w/w-ing an INLINE function
-because the wrapepr will then overwrite the InlineRule unfolding.
+because the wrapper will then overwrite the InlineRule unfolding.
 
 It was wrong with the old InlineMe Note too: if we do so by mistake 
 we transform
 
 It was wrong with the old InlineMe Note too: if we do so by mistake 
 we transform