April 2018 - ghc-tickets

[GHC] #13704: -main-is flag should change exports in default module header
by GHC 17 Nov '18

17 Nov '18

#13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The -main-is option to GHC should probably change the export list for the default module header. It doesn't. {{{ $ cat Main.hs program = return () $ ghc -main-is Main.program Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:1:1: error: Not in scope: ‘main’ Perhaps you meant ‘min’ (imported from Prelude) Main.hs:1:1: error: The main IO action ‘program’ is not exported by module ‘Main’ }}} I cannot imagine any possible use case for a feature that changes the entry point name to something else, and then deliberately fails to export the symbol by that name. This seems like an obvious thing to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11477: Remove -Wamp
by GHC 17 Nov '18

17 Nov '18

#11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This warning is intended as a temporary measure to aid the Applicative- Monad Proposal transition. It should be eventually removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11477> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10675: GHC does not check the functional dependency consistency condition correctly
by GHC 16 Nov '18

16 Nov '18

#10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances, ScopedTypeVariables #-} class C a b | a -> b where op :: a -> b instance C [x] [x] instance {-# OVERLAPS #-} C x y => C [x] [Maybe y] f x = op [x] }}} Should these two instance declarations be accepted? They are simply ''inconsistent'' in the sense of Definition 6 of the [http://research.microsoft.com/en-us/um/people/simonpj/papers/fd- chr/jfp06.pdf FDs through CHRs paper]. Sadly GHC does not currently reject these as inconsistent. As a result it'll use ''both'' instance for improvement. In the definition of `f` for example we get {{{ C [alpha] beta }}} where `x:alpha` and the result type of `f` is `beta`. By using both instances for improvement we get {{{ C [Maybe gamma] [Maybe gamma] }}} Is that what we want? The two instances don't ''contradict'' each other, but neither do they agree as all published work on FDs says they should! Examples in the testsuite that exploit this loophole are {{{ ghci/scripts ghci047 polykinds T9106 typecheck/should_compile FD4 typecheck/should_compile T7875 }}} I'm not sure what the right thing here is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #14742: Unboxed sums can treat Int#s as Word#s
by GHC 16 Nov '18

16 Nov '18

#14742: Unboxed sums can treat Int#s as Word#s -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following module: {{{ {-# language MagicHash, UnboxedSums #-} {-# options_ghc -ddump-stg -dppr-debug -fprint-explicit-kinds -ddump-to- file #-} module Bug where import GHC.Prim import GHC.Types mkUnboxedSum :: () -> (# Float# | Int# #) mkUnboxedSum _ = (# | 9# #) {-# noinline mkUnboxedSum #-} foo :: Int foo = case mkUnboxedSum () of (# | i# #) -> I# i# (# f# | #) -> 8 }}} The full .dump-stg is attached. An abbreviation of the case statement in foo is: {{{ case (...) of (...) { ghc-prim:GHC.Prim.(#,,#){(w) d 89} ((us_g1h9{v} [lid] :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc-prim:GHC.Types.WordRep{(w) d 63J})) :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc- prim:GHC.Types.WordRep{(w) d 63J})) ((us_g1ha{v} [lid] :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc-prim:GHC.Types.WordRep{(w) d 63J})) :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc- prim:GHC.Types.WordRep{(w) d 63J})) ((us_g1hb{v} [lid] :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc-prim:GHC.Types.FloatRep{(w) d 63V})) :: ghc- prim:GHC.Types.Any{(w) tc 35K} (ghc- prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc- prim:GHC.Types.FloatRep{(w) d 63V})) -> case (us_g1h9{v} [lid] :: ghc-prim:GHC.Types.Any{(w) tc 35K} (ghc-prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc- prim:GHC.Types.WordRep{(w) d 63J})) :: Prim IntRep of ((tag_g1hc{v} [lid] :: ghc-prim:GHC.Prim.Int#{(w) tc 3s}) :: ghc-prim:GHC.Prim.Int#{(w) tc 3s}) { __DEFAULT -> ghc-prim:GHC.Types.I#{(w) d 6i} [8#]; 2# -> ghc-prim:GHC.Types.I#{(w) d 6i} [(us_g1ha{v} [lid] :: ghc-prim:GHC.Types.Any{(w) tc 35K} (ghc-prim:GHC.Prim.TYPE{(w) tc 32Q} 'ghc-prim:GHC.Types.WordRep{(w) d 63J}))]; }; }}} Note that: * `us_g1h9 :: Any (TYPE WordRep)`; * `us_g1ha :: Any (Type WordRep)`; * `tag_g1hc :: Int#`; * The `2#` alternative passes `us_g1ha` to an `I#` constructor. This seems wrong to me. It comes about because `slotPrimRep . primRepSlot` (in RepType) is not the identity. StgLint found this while I was working on ticket:14541 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14343: bad pretty-printing of types with promoted data types
by GHC 15 Nov '18

15 Nov '18

#14343: bad pretty-printing of types with promoted data types -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ > :set -XDataKinds > :set -XPolyKinds > data Proxy k = Proxy > _ :: Proxy '[ 'True ] error: Found hole: _ :: Proxy '['True] > _ :: Proxy '['True] error: Invalid type signature: _ :: ... Should be of form <variable> :: <type> }}} Alternatively, this could be attributed to the parser/lexer doing an insufficient job there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14343> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr`
by GHC 15 Nov '18

15 Nov '18

#10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- An `HsExpr` should look exactly as a user wrote some Haskell code. Its pretty printer should therefore be quite dumb. Just print out the code! But a few places in GHC create `HsExpr`s and aren't scrupulous with regard to adding `HsPar` nodes where source syntax would need them. Thus, well- meaning souls have added `pprParendExpr` calls to the `HsExpr` pretty- printer to try to cover these cases. Simon and I [https://phabricator.haskell.org/D1219#34199 think] that we should remove all recursive uses of `pprParendExpr` from the `HsExpr` pretty-printer and instead add the `HsPar`s where necessary. It was recently reported that the following test cases break when simply removing `pprParendExpr`: {{{ Unexpected failures: deriving/should_fail T4846 [stderr mismatch] (normal) generics GenDerivOutput [stderr mismatch] (normal) generics GenDerivOutput1_0 [stderr mismatch] (normal) generics GenDerivOutput1_1 [stderr mismatch] (normal) ghci/scripts T10248 [bad stderr] (ghci) indexed-types/should_compile PushedInAsGivens [stderr mismatch] (normal) safeHaskell/safeLanguage SafeLang10 [stderr mismatch] (normal) safeHaskell/safeLanguage SafeLang17 [stderr mismatch] (normal) typecheck/should_fail T8603 [stderr mismatch] (normal) typecheck/should_fail tcfail177 [stderr mismatch] (normal) }}} See also considerable commentary on Phab:D1114. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14293: View patterns with locally defined functions in restructuring don't compile
by GHC 14 Nov '18

14 Nov '18

#14293: View patterns with locally defined functions in restructuring don't compile -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ViewPatterns #-} foo x = x Just (id -> res) = pure 'a' -- WORKS Just (foo -> res') = pure 'a' -- FAILS bar (foo -> res) = res -- WORKS {- [1 of 1] Compiling Main ( T14293.hs, interpreted ) T14293.hs:6:7-9: error: Variable not in scope: foo :: Char -> t | 6 | Just (foo -> res') = pure 'a' | ^^^ Failed, 0 modules loaded. -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13114: UniqSet definition seems shady
by GHC 13 Nov '18

13 Nov '18

#13114: UniqSet definition seems shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, {{{#!hs type UniqSet a = UniqFM a }}} The key invariant of `UniqSet` is expressed in the somewhat-poorly-named `Note [Unsound mapUniqSet]`, and not enforced by the types. It seems likely that the clean thing is {{{#!hs newtype UniqSet a = US (UniqFM a) }}} Unfortunately there's an awful lot of code using `UniqSet` and assuming it's the same as `UniqFM`. To make this work, we'd need to expand the `UniqSet` API somewhat and figure out what to do at use sites using it interchangeably with `UniqFM`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15054: ghc internal error appeared in GHCI
by GHC 11 Nov '18

11 Nov '18

#15054: ghc internal error appeared in GHCI -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After playing with vectors in ghci I got following error: {{{ ghc: internal error: Unable to commit 1048576 bytes of memory }}} It happened randomly, on empty prompt while no query was being evaluated I am using latest version of GHC on Arch Linux Here is my whole session: {{{ >λ= import Criterion Criterion Criterion.IO.Printf Criterion.Main.Options Criterion.Report Criterion.Analysis Criterion.Internal Criterion.Measurement Criterion.Types Criterion.IO Criterion.Main Criterion.Monad >λ= import Criterion.Main >λ= import Data.Vector >λ= import Data.Vector as V >λ= main = default defaultConfig defaultMain defaultMainWith >λ= defaultMain [bench "TESTXD" $ whnf ([1..100000]!!) 9999] benchmarking TESTXD time 19.81 μs (19.66 μs .. 19.99 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 13.47 μs (12.93 μs .. 14.11 μs) std dev 853.8 ns (542.7 ns .. 1.249 μs) variance introduced by outliers: 65% (severely inflated) >λ= defaultMain [bench "TESTXD" $ whnf ([1..100000]!!) 9999] benchmarking TESTXD time 19.62 μs (19.39 μs .. 19.99 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 13.49 μs (12.85 μs .. 14.51 μs) std dev 1.154 μs (524.9 ns .. 1.704 μs) variance introduced by outliers: 77% (severely inflated) >λ= v = V.fromList [1..100000] Display all 192 possibilities? (y or n) V.! V.fold1M' V.indexed V.prescanl V.unsafeDrop V.!? V.fold1M'_ V.init V.prescanl' V.unsafeFreeze V.++ V.fold1M_ V.iscanl V.prescanr V.unsafeHead V.// V.foldM V.iscanl' V.prescanr' V.unsafeHeadM V.MVector V.foldM' V.iscanr V.product V.unsafeIndex V.Vector V.foldM'_ V.iscanr' V.replicate V.unsafeIndexM V.accum V.foldM_ V.iterateN V.replicateM V.unsafeInit V.accumulate V.foldl V.iterateNM V.reverse V.unsafeLast V.accumulate_ V.foldl' V.izipWith V.scanl V.unsafeLastM V.all V.foldl1 V.izipWith3 V.scanl' V.unsafeSlice V.and V.foldl1' V.izipWith4 V.scanl1 V.unsafeTail V.any V.foldr V.izipWith5 V.scanl1' V.unsafeTake V.backpermute V.foldr' V.izipWith6 V.scanr V.unsafeThaw V.break V.foldr1 V.izipWithM V.scanr' V.unsafeUpd V.concat V.foldr1' V.izipWithM_ V.scanr1 V.unsafeUpdate V.concatMap V.forM V.last V.scanr1' V.unsafeUpdate_ V.cons V.forM_ V.lastM V.sequence V.unstablePartition V.constructN V.force V.length V.sequence_ V.unzip V.constructrN V.freeze V.map V.singleton V.unzip3 V.convert V.fromList V.mapM V.slice V.unzip4 V.copy V.fromListN V.mapM_ V.snoc V.unzip5 V.create V.generate V.mapMaybe V.span V.unzip6 V.createT V.generateM V.maxIndex V.splitAt V.update V.drop V.head V.maxIndexBy V.sum V.update_ V.dropWhile V.headM V.maximum V.tail V.zip V.elem V.ifilter V.maximumBy V.take V.zip3 V.elemIndex V.ifoldM V.minIndex V.takeWhile V.zip4 V.elemIndices V.ifoldM' V.minIndexBy V.thaw V.zip5 V.empty V.ifoldM'_ V.minimum V.toList V.zip6 V.enumFromN V.ifoldM_ V.minimumBy V.unfoldr V.zipWith V.enumFromStepN V.ifoldl V.modify V.unfoldrM V.zipWith3 V.enumFromThenTo V.ifoldl' V.notElem V.unfoldrN V.zipWith4 V.enumFromTo V.ifoldr V.null V.unfoldrNM V.zipWith5 V.filter V.ifoldr' V.or V.uniq V.zipWith6 V.filterM V.imap V.partition V.unsafeAccum V.zipWithM V.find V.imapM V.postscanl V.unsafeAccumulate V.zipWithM_ V.findIndex V.imapM_ V.postscanl' V.unsafeAccumulate_ V.findIndices V.imapMaybe V.postscanr V.unsafeBackpermute V.fold1M V.indexM V.postscanr' V.unsafeCopy >λ= defaultMain [bench "TESTXD" $ whnf ([1..100000]!!) 9999, bench "TESTV" $ whnf (\x -> (V.!) v x)] <interactive>:8:93: error: parse error (possibly incorrect indentation or mismatched brackets) ] λ= defaultMain [bench "TESTXD" $ whnf ([1..100000]!!) 9999, bench "TESTV" $ whnf (\x -> (V.!) v x) <interactive>:9:74: error: • Couldn't match expected type ‘Benchmarkable’ with actual type ‘Int -> Benchmarkable’ • Probable cause: ‘whnf’ is applied to too few arguments In the second argument of ‘($)’, namely ‘whnf (\ x -> (!) v x)’ In the expression: bench "TESTV" $ whnf (\ x -> (!) v x) In the first argument of ‘defaultMain’, namely ‘[bench "TESTXD" $ whnf ([1 .. 100000] !!) 9999, >λ= defaultMain [bench "TESTXD" $ whnf ([1..100000]!!) 9999, bench "TESTV" $ whnf (\x -> (V.!) v x) 9999] benchmarking TESTXD time 20.61 μs (20.47 μs .. 20.80 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 14.41 μs (13.85 μs .. 14.88 μs) std dev 805.2 ns (588.3 ns .. 1.036 μs) variance introduced by outliers: 59% (severely inflated) benchmarking TESTV time 1.796 ms (1.768 ms .. 1.831 ms) 0.997 R² (0.995 R² .. 0.999 R²) mean 1.426 ms (1.367 ms .. 1.481 ms) std dev 153.6 μs (123.2 μs .. 190.1 μs) variance introduced by outliers: 69% (severely inflated) (V.!) >λ= >λ= (V.!) v 999 1000 >λ= (V.!) v 9999 10000 >λ= l = [1..100000]) <interactive>:13:16: error: parse error on input ‘)’ >λ= l = [1..100000] >λ= l !! 9999 10000 >λ= l !! 99999 100000 >λ= l !! 999999 *** Exception: Prelude.!!: index too large >λ= l = [1..10000000] >λ= l !! 999999 1000000 >λ= l !! 9999999 10000000 >λ= l !! 99999999 *** Exception: Prelude.!!: index too large >λ= sum l <interactive>:22:1: error: Ambiguous occurrence ‘sum’ It could refer to either ‘Data.Vector.sum’, imported from ‘Data.Vector’ or ‘Prelude.sum’, imported from ‘Prelude’ (and originally defined in ‘Data.Foldable’) >λ= Prelude.sum l 50000005000000 >λ= Prelude.sum l 50000005000000 >λ= v = V.fr V.freeze V.fromList V.fromListN >λ= v = V.fromList l >λ= V.last v 10000000 >λ= :sprint v v = _ Display all 1088 possibilities? (y or n) >λ= V.sum v 50000005000000 >λ= V.sum v 50000005000000 >λ= V.last v 10000000 >λ= relast l read readIO readLn reads realToFrac rem replicate return readFile readList readParen readsPrec recip repeat replicateM reverse >λ= Prelude.last l 10000000 >λ= Prelude.last l 10000000 >λ= V.last v 10000000 >λ= :t (//) (//) :: Vector a -> [(Int, a)] -> Vector a >λ= :t v v :: (Enum a, Num a) => Vector a >λ= l = [1..10000000] :: [Int] >λ= last l <interactive>:37:1: error: Ambiguous occurrence ‘last’ It could refer to either ‘Data.Vector.last’, imported from ‘Data.Vector’ or ‘Prelude.last’, imported from ‘Prelude’ (and originally defined in ‘GHC.List’) >λ= import Prelude as P >λ= P.last l 10000000 >λ= v = from fromEnum fromInteger fromIntegral fromList fromListN fromRational >λ= v = fromList l >λ= :t v v :: Vector Int >λ= V.last v 10000000 >λ= V.last v 10000000 >λ= V.last v 10000000 >λ= v = fromList l >λ= P.last l 10000000 >λ= P.last l 10000000 >λ= V.last v 10000000 >λ= V.last v 10000000 >λ= V.last v 10000000 >λ= P.last l 10000000 >λ= P.last l 10000000 >λ= l = [1..100000000] :: [Int] >λ= v = fromList l >λ= P.last l 100000000 >λ= V.last v 100000000 >λ= V.last v 100000000 >λ= :t v v :: Vector Int >λ= :t v v :: Vector Int >λ= :sprint v v = Data.Vector.Vector 0 100000000 _ >λ= ghc: internal error: Unable to commit 1048576 bytes of memory (GHC version 8.2.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 12349 killed stack ghci }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s
by GHC 11 Nov '18

11 Nov '18

#11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Haskell2010 states: > An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`. Consider the following two modules: {{{#!hs -- module Main (main) where import Main2 (main) }}} {{{#!hs module Main2 (main) where main :: IO () main = return () }}} A non-interactive GHC happily compiles `ghc --make Main`, however, GHCi fails with {{{ $ ghci Main.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help unknown option: 'c' [1 of 2] Compiling Main2 ( Main2.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Main.hs:1:1: The IO action ‘main’ is not exported by module ‘Main’ Failed, modules loaded: Main2. }}} For GHCi we need to uncomment the explicit `module Main (main) where` line to make it work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6