#2722: <<loop> when compiling with -O option with ghc-6.10.0.20081019
-------------------------------+--------------------------------------------
 Reporter:  uwe                |          Owner:         
     Type:  bug                |         Status:  new    
 Priority:  high               |      Milestone:  6.10.1 
Component:  Compiler           |        Version:  6.10.1 
 Severity:  normal             |     Resolution:         
 Keywords:  Optimization Loop  |     Difficulty:  Unknown
 Testcase:                     |   Architecture:  x86    
       Os:  Linux              |  
-------------------------------+--------------------------------------------
Comment (by simonpj):

 OK I know what is happening.  Sigh.

 I boiled it down still more:
 {{{
 module Foo (main, arid1, arid2) where

 import Prelude hiding (id, (.))
 import qualified Prelude
 import Control.Category
 import Control.Arrow
 import System.IO
 import Debug.Trace


 main = runXIOState arid1        -- Loop with arid1
                                 -- Works with arid2

 arid1 :: Arrow m => m a a
 arid1 = arr id

 arid2 :: Arrow m => m a a
 arid2 = arr Prelude.id

 runXIOState :: IOSLA () c -> IO [c]
 runXIOState f = runIOSLA f ()

 newtype IOSLA a b = IOSLA { runIOSLA :: a -> IO [b] }

 instance Arrow IOSLA where
     arr f = IOSLA $ \ x -> return [f x]

 instance Category IOSLA where
     id = arr id

 -- arr :: Arrow m => (b->c) -> m b c
 -- id  :: Category m => m b b
 -- (arr id) :: Arrow m => m a a

 }}}
 What is happening is this.
   * In `Control.Arrow` we find the following rewrite rule
 {{{
 {-# RULES "identity" arr id = id
 }}}
   * But, as you see above, `id` is defined to be `arr id`.

 So the result is (unsurprisingly) a loop.

 I'm not sure whether the fault lies with the person who wrote the RULE in
 `Control.Arrow`, or the person who wrote the instance of IOSLA above.
 (The instance does look suspicious, because `Category` is a superclass of
 `Arrow`, and yet uses the arrow `arr` method to define `id`.)

 Very tricky to track down.  At all events I say that GHC is not at fault.

 I'm leaving this open because someone should
  * Decide whether the rules in `Control.Arrow` are valid in general.
  * If so, write some documentation somewhere about the constraints that
 these rules impose on instance declarations.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2722#comment:5>
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