Opened 9 years ago

Closed 8 years ago

Last modified 2 years ago

#5022 closed bug (fixed)

Core Lint error from polymorphic definitions inside arrow rec

Reported by: serpentologist Owned by: ross
Priority: high Milestone: 7.4.1
Component: Compiler Version: 7.0.2
Keywords: Arrows Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: None/Unknown Test Case: arrows/T5022
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I am trying to build Paul Hudak's Eutrepea library ( and GHC is getting stuck at compiling src/Euterpea/Audio/Render.hs file. It failed to complete compilation in 5 hours.

I am using the following versions of GHC and Haskell-Platform: 1) 2)

The source code of the file:

Change History (21)

comment:1 Changed 9 years ago by serpentologist

I was told in LiveJournal community that the problem might be caused by pSwitch function, specifically by 'forall' usage. So i removed it along with the renderFS function dependent on it and compilation succeeded.

comment:2 Changed 9 years ago by simonpj

Can you provide step-by-step instructions to reproduce the problem? Ideally depending on as few auxiliary packages as possible. Thanks.

comment:3 Changed 9 years ago by serpentologist

Unfortunately i'm a complete newbie in Haskell. I'm just going to start learning it and hardly can read the source code, so it's unlikely i will be able to isolate the problem and reproduce it per se.

The steps i took:

1) I installed GHC 7.0.2 ( using default settings (./configure && sudo make install)

2) Then i installed Haskell-Platform (haskell-platform-2011.2.0.0.tar.gz) (./configure && make && sudo make install)

3) Then i followed instructions from page

cabal update

cabal install darcs --flags="http -curl"

added export PATH=~/.cabal/bin:$PATH to .bashrc

mkdir HSoM && cd HSoM

darcs get

cd Euterpea

cabal install

GHC got stuck at src/Euterpea/Audio/Render.hs file. It did not complain about any errors but it kept running for about 5 hours consuming 90% of CPU time so i was forced to interrupt it. The memory usage was not high - 8% of the 2G.

comment:4 Changed 8 years ago by igloo

I can't reproduce this, using the x86/Linux bindist.

Is it reproducible for you, serpentologist?

comment:5 Changed 8 years ago by serpentologist

I don't know what bindlist is (is it cross-compiling?), but yes, i can reproduce it on my Ubuntu 10.04 system.

Could it depend on the compiler version? The version i have is $ gcc --version gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

comment:6 Changed 8 years ago by igloo

Milestone: 7.2.1
Priority: normalhigh

The bindist is

(i.e. I didn't try building the platform and compiling with that)

comment:7 Changed 8 years ago by igloo

Owner: set to igloo

comment:8 Changed 8 years ago by gareth.rowlands

Me too, on Windows 7, GHC 7.0.3, Haskell Platform 2001.2.0.1.

Same procedure and result:

darcs get

cd Euterpea

cabal install

GHC goes into apparently infinite loop after printing this last message:

[25 of 25] Compiling Euterpea.Audio.Render ( src\Euterpea\Audio\Render.hs, dist\build\Euterpea\Audio\Render.o )

comment:9 Changed 8 years ago by FlashKorten

Architecture: x86x86_64 (amd64)

You can find a work-around for this problem in the Euterpea file README.txt

To fix this problem, configure the module with optimization disabled:

runhaskell Setup.hs configure --disable-optimization

Then the build would succeed.

Alternatively, you can run cabal configure --disable-optimization

comment:10 Changed 8 years ago by simonpj

I get this

bash$ cabal install
Resolving dependencies...
Configuring PortMidi-0.1.3...
cabal: Missing dependency on a foreign library:
* Missing C library: asound
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Error: some packages failed to install:
Euterpea-0.1.0 depends on PortMidi-0.1.3 which failed to install.
PortMidi-0.1.3 failed during the configure step. The exception was:
ExitFailure 1

Your response could be "install asound" but I have no clue how to do that, and I only want to compile the thing! Can you tell me how to build up to the error you found, without installing lots of goop? Thanks!

If there are any other weird non-Haskell packages I'd like to avoid them too if poss.


comment:11 Changed 8 years ago by gareth.rowlands


When I built on Windows 7, I didn't have to install asound. Just darcs get; cabal install was enough to make GHC spin.

Sorry that doesn't help build on Linux.


comment:12 Changed 8 years ago by simonpj

Owner: changed from igloo to ross
Summary: GHC goes to infinite loopArrow desugarer generates Core Lint error

OK I managed to reproduce this, thank you. It turns out to be an error in the desugarer for arrows, which generates a Core Lint error. (Alwyas try switching on -dcore-lint!) I did not investigate the exact cause of the loop (which shows up in the FloatOut pass, but it might result from constructing an infinite type, or something like that. Anyway the first thing is to generate a type correct program.

Ross: here is a nice smallihs standalone test case. Could you investigate? Compile with -dcore-lint and it fails. No need for supporting packages or such. Thanks

{-# LANGUAGE Arrows, FlexibleInstances, MultiParamTypeClasses, ScopedTypeVariables #-}

module T5022 (
) where

import Prelude hiding ( id, init, (.) )
import Control.Arrow( Arrow, ArrowLoop, ArrowChoice )
import Control.Category( Category, (.) )

init :: b -> ArrowP SF p b b
init = error "urk"

returnA :: ArrowP SF p b b
returnA = error "urk"

newtype SF a b = SF { runSF :: (a -> (b, SF a b)) }
instance ArrowLoop SF where
instance Category SF where
instance Arrow SF where

newtype ArrowP a p b c = ArrowP (a b c)
instance ArrowLoop a => ArrowLoop (ArrowP a p) where
instance ArrowChoice a => ArrowChoice (ArrowP a p) where
instance Arrow a => Arrow (ArrowP a p) where
instance Category a => Category (ArrowP a p) where

strip :: ArrowP SF p b c -> SF b c
strip = error "urk"

type Signal clk a b = ArrowP SF clk a b

pSwitch :: forall p col a. (Functor col) =>
           col (Signal p () a) 
        -> Signal p () [()]    
        -> (col (Signal p () a) -> [()] -> col (Signal p () a))  
        -> Signal p () (col a)  
pSwitch col esig mod = 
    proc _ -> do
        evts <- esig -< ()
        sfcol <- init col -< mod sfcol' evts  
        let rs = fmap (\s -> runSF (strip s) ()) sfcol :: col (a, SF () a)
            (as, sfcol') = (fmap fst rs, fmap (ArrowP . snd) rs)
      returnA -< as

comment:13 Changed 8 years ago by ross

That's odd. This generates no error for me (linux-x86):

ghc-7.2.1 -dcore-lint -c T5022.hs

comment:14 Changed 8 years ago by igloo

I can reproduce it with HEAD, but not the 7.2 branch. (Linux/amd64)

comment:15 Changed 8 years ago by igloo


comment:16 Changed 8 years ago by ross

A simpler example of the same bug:

module T5022 (
) where

import Prelude hiding ( init )

returnA :: b -> b
returnA = id

newtype State s a = State { unState :: [a] }

pIterate :: a -> [a]
pIterate =
    proc x -> do
        as <- unState -< s
        let s = State (x:as)
      returnA -< as

s gets a polymorphic type, but for some reason the constructor of the tuple for feedback in the rec expects a monotype.

comment:17 Changed 8 years ago by ross@…

commit 4c8e03075ab8719f3753c1a2e4f05ef21be193ac

Author: Ross Paterson <>
Date:   Mon Dec 19 23:44:33 2011 +0000

    fix #5022: polymorphic definitions inside arrow rec
    This is quite tricky, with examples like this:
    import Control.Arrow
    pRepeat :: a -> [a]
    pRepeat =
        proc x -> do
            s <- returnA -< f_rec x:s       -- f_rec is monomorphic here
            let f_later y = y               -- f_later is polymorphic here
            _ <- returnA -< (f_later True, f_later 'a')
            let f_rec y = y                 -- f_rec is polymorphic here
          returnA -< f_later s              -- f_later is monomorphic here
    Fixed the typechecking of arrow RecStmt to track changes to the monad
    version.  It was simplest to add a field recS_later_rets corresponding
    to recS_rec_rets.  It's only used for the arrow version, and always
    empty for the monad version.  But I think it would be cleaner to put
    the rec_ids and later_ids in a single list with supplementary info
    saying how they're used.
    Also fixed several glitches in the desugaring of arrow RecStmt.  The fact
    that the monomorphic variables shadow their polymorphic counterparts is a
    major pain.  Also a bit of general cleanup of DsArrows while I was there.

 compiler/deSugar/DsArrows.lhs    |  238 +++++++++++++++++++++++---------------
 compiler/hsSyn/HsExpr.lhs        |    9 +-
 compiler/hsSyn/HsUtils.lhs       |    2 +-
 compiler/typecheck/TcArrows.lhs  |   27 +++--
 compiler/typecheck/TcHsSyn.lhs   |    9 +-
 compiler/typecheck/TcMatches.lhs |    3 +-
 6 files changed, 174 insertions(+), 114 deletions(-)

comment:18 Changed 8 years ago by ross

Status: newmerge
Summary: Arrow desugarer generates Core Lint errorCore Lint error from polymorphic definitions inside arrow rec

Polymorphic variables inside arrow rec were mishandled in both the typechecker and the desugarer. This test covers the several issues here (it should compile):

import Control.Arrow

pRepeat :: a -> [a]
pRepeat =
    proc x -> do
        s <- returnA -< f_rec x:s       -- f_rec is monomorphic here
        let f_later y = y               -- f_later is polymorphic here
        _ <- returnA -< (f_later True, f_later 'a')
        let f_rec y = y                 -- f_rec is polymorphic here
      returnA -< f_later s

comment:19 Changed 8 years ago by igloo

difficulty: Unknown
Resolution: fixed
Status: mergeclosed

comment:20 Changed 7 years ago by simonpj

Test Case: arrows/T5022

comment:21 Changed 2 years ago by simonpj

Keywords: Arrows added; infinite loop removed
Note: See TracTickets for help on using tickets.