#7179: Non-unique variable bindings in the Core
-------------------------------+--------------------------------------------
  Reporter:  stephen70edwards  |          Owner:                  
      Type:  bug               |         Status:  closed          
  Priority:  normal            |      Milestone:                  
 Component:  External Core     |        Version:  7.4.1           
Resolution:  wontfix           |       Keywords:  CoreSyn Unique  
        Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  Other             |     Difficulty:  Unknown         
  Testcase:                    |      Blockedby:                  
  Blocking:                    |        Related:                  
-------------------------------+--------------------------------------------
Changes (by simonpj):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => wontfix


Comment:

 I'm afraid Core makes no claim to uniqueness.  In general, the Simplifier
 tends to remove shadowing, so it will tend not to produce this:
 {{{
   (\x_3. \x_3. ...x_3...)
 }}}
 But that's only to make life easier for the Simplifier itself; it's not a
 guarantee. And no other pass is required to ensure uniqueness.

 The simplifier does not even try to eliminate uses of the same binder in
 different sub-expressions (your example).

 These would be hard invariants to maintain. If you want to establish such
 an invariant, just before you do something else. you can write a pass that
 does so.

 I recently added this comment to `CoreSyn.lhs`:
 {{{
 Note [Shadowing]
 ~~~~~~~~~~~~~~~~
 While various passes attempt to rename on-the-fly in a manner that
 avoids "shadowing" (thereby simplifying downstream optimizations),
 neither the simplifier nor any other pass GUARANTEES that shadowing is
 avoided. Thus, all passes SHOULD work fine even in the presence of
 arbitrary shadowing in their inputs.

 In particular, scrutinee variables `x` in expressions of the form
 `Case e x t` are often renamed to variables with a prefix
 "wild_". These "wild" variables may appear in the body of the
 case-expression, and further, may be shadowed within the body.
 }}}
 If you would like to modify it, or add some more clarification, can you
 suggest some words and I'll add them?

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7179#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to