June 2017 - ghc-tickets

[GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector
by GHC 27 Jun '17

27 Jun '17

#10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When compiling attached source file, GHC panics. The following is the error message. {{{ $ ghc -Wall Vec3.hs [1 of 1] Compiling Data.Vector.Vec3 ( Vec3.hs, Vec3.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Size.intSize W256 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Currently native code generator does not support SIMD operations, and my computer does not support AVX instructions. Therefore ghc cannot compile the source at any case. So I think this bug is not so important. My system environment. {{{ $ uname -a Linux think 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU L9300 @ 1.60GHz stepping : 6 microcode : 0x60c cpu MHz : 1601.000 cache size : 6144 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority bugs : bogomips : 3193.86 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU L9300 @ 1.60GHz stepping : 6 microcode : 0x60c cpu MHz : 1601.000 cache size : 6144 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority bugs : bogomips : 3193.86 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13874: GHC panic related to hybrid-vectors
by GHC 25 Jun '17

25 Jun '17

#13874: GHC panic related to hybrid-vectors -------------------------------------+------------------------------------- Reporter: ocramz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following module makes GHC 8.0.1 panic when the `fromList` declaration is uncommented: {{{#!hs import qualified Data.Vector.Hybrid as VH import qualified Data.Vector.Unboxed as VU import qualified Data.Vector as V data SHVector a = SHV {-# UNPACK #-} !Int !(VH.Vector VU.Vector V.Vector (Int, a)) deriving (Eq) fromList :: Int -> [(Int, a)] -> SHVector a fromList n ll = SHV n (VH.fromList ll) }}} Crash message follows: {{{#!hs ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Template variable unbound in rewrite rule Variable: sc_shyr Rule "SC:$j0" Rule bndrs: [sc_shyr, sc_shys, sc_shyt, sg_shyu, sc_shyq] LHS args: [sc_shyq, (MV @ (Mutable Vector) @ (Mutable Vector) @ (PrimState (ST RealWorld)) @ (Int, a_aeG1) @ Int @ a_aeG1 @~ (<(Int, a_aeG1)>_N :: ((Int, a_aeG1) :: *) ~# ((Int, a_aeG1) :: *)) sc_shys sc_shyt) `cast` (sg_shyu :: (MVector (Mutable Vector) (Mutable Vector) (PrimState (ST RealWorld)) (Int, a_aeG1) :: *) ~R# (Mutable (Vector Vector Vector) (PrimState (ST RealWorld)) (Int, a_aeG1) :: *))] Actual args: [sc_shyk, wild_ahdD `cast` (Sub (Sym (D:R:MutableVector[0] <Vector>_N <Vector>_N)) <PrimState (ST RealWorld)>_N <(Int, a_aeG1)>_N :: (MVector (Mutable Vector) (Mutable Vector) (PrimState (ST RealWorld)) (Int, a_aeG1) :: *) ~R# (Mutable (Vector Vector Vector) (PrimState (ST RealWorld)) (Int, a_aeG1) :: *))] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13874> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions
by GHC 25 Jun '17

25 Jun '17

#13376: GHC fails to specialize a pair of polymorphic INLINABLE functions -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new 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: #8668 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a boiled down version of a library I'm working on. It's possible this is the same issue as #8668 which seems to have stalled. Hopefully this example is simpler and useful in that case. Also likely the same as this https://github.com/jmoy/testing-specialize I have a library which defines the classes `H` and `S`; library consumers are likely to define their own `H` instances, and import `S` instances declared by ''other'' library authors (not me), who will depend on my `H`. Performance depends on all of it getting fully-specialized `hash` (i.e. for each combination of `H` and `S` that the consumer uses). But I don't really want `hash` inlined at every call site. Here is the code to repro with explanation below. I'm compiling like: `ghc --make -Wall -O2 -rtsopts -funbox-strict-fields -ddump-to-file -ddump- simpl -dsuppress-module-prefixes -dsuppress-uniques -ddump-core-stats -ddump-inlinings -ddump-asm -fforce-recomp Main.hs`, and we get the same bad behavior on GHC 7.10.3 and GHC 8.0.1: Lib.hs: {{{#!hs module Lib where class H h where hash :: (S s)=> s -> h -> s class S s where mix :: s -> Int -> s instance H Int where {-# INLINABLE hash #-} hash s = \x -> s `mix` x -- make this look big: `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x }}} S.hs: {{{#!hs module S where import Lib newtype Foo = Foo Int deriving Show instance S Foo where {-# INLINABLE mix #-} mix (Foo x) y = Foo (x+y) }}} And the `Main` I'm using, though you can just call print; it's obvious dumping inlinings when the functions get specialized and unboxed (look for "Inlining done: $fNumInt_$c+"): {{{#!hs module Main where import Lib import S import Criterion.Main main = defaultMain [ bench "foo" $ whnf (hash (Foo 1)) (1::Int) ] }}} If I use the `INLINABLE` pragmas above or omit them entirely we get bad code. If I put an `INLINE` on the `hash` declaration in Lib (and no pragmas in S), we get good unboxed additions and things are fast. Finally and most bizarrely, if I omit the `INLINE` pragma in `hash` (and similarly no pragmas in `S`) but make the body small enough (5 lines of the "`mix` x `mix` x..." junk) then we also get nice unboxed code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13865: Add to Data.Proxy a utility function proxy :: a -> Proxy a
by GHC 24 Jun '17

24 Jun '17

#13865: Add to Data.Proxy a utility function proxy :: a -> Proxy a -------------------------------------+------------------------------------- Reporter: louispan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/base | Keywords: Proxy | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I sometime find myself wanting to create a Proxy of a certain type (to pass into functions that use Proxy), but I only have easy access to the value, but not the type (eg. because the type is being inferred). That is, I find myself defining the following function proxy :: a -> Proxy a proxy _ = Proxy It would be great if something like that could be added to Data.Proxy -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13865> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12978: User guide section on AllowAmbiguousTypes should mention TypeApplications
by GHC 24 Jun '17

24 Jun '17

#12978: User guide section on AllowAmbiguousTypes should mention TypeApplications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #ghc-flag--XAllowAmbiguousTypes With type applications it is tempting to write {{{ class C x a where meth :: a }}} which will fail the ambiguity check as `x` is not used in any methods. One way to get around this is to use `TypeApplications` in order to specify what `x` should be at each usage of `meth`. A small section in the user guide explaining this and linking to the section on `TypeApplications` would be useful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13782: Bullish use of Template Haskell's newName causes GHC internal error
by GHC 24 Jun '17

24 Jun '17

#13782: Bullish use of Template Haskell's newName causes GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- int-index originally spotted this bug at https://github.com/goldfirere/singletons/issues/150#issuecomment-305909199. To reproduce, compile this file with GHC 8.0.1, 8.0.2, 8.2.1, or HEAD: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH $(do TyConI (DataD _ _ [KindedTV a1 _] _ _ _) <- reify ''Maybe [f,a2] <- mapM newName ["f","a"] return [ SigD f (ForallT [KindedTV a2 (AppT (ConT ''Maybe) (VarT a1))] [] (ConT ''Int)) , ValD (VarP f) (NormalB (LitE (IntegerL 42))) [] ]) }}} {{{ GHCi, version 8.2.0.20170522: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:9:3: error: • GHC internal error: ‘a_11’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] • In the first argument of ‘Maybe’, namely ‘a_11’ In the kind ‘Maybe a_11’ In the type signature: f :: forall (a_a4Qz :: Maybe a_11). Int | 9 | $(do TyConI (DataD _ _ [KindedTV a1 _] _ _ _) <- reify ''Maybe | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} The root cause of the issue seems to be that the name `a` (which we picked for `newName`) happens to clash with the type variable we reified from `Maybe` (since `data Maybe a = ...`). If we pick a different name: {{{#!hs [f,a2] <- mapM newName ["f","albatross"] }}} Then it will compile. This is a regression from GHC 7.10.3, as it compiles in that version (with a slight change to accommodate the API differences in `DataD` between 7.10.3 and 8.0): {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} module Works where import Language.Haskell.TH $(do TyConI (DataD _ _ [KindedTV a1 _] _ _) <- reify ''Maybe [f,a2] <- mapM newName ["f","a"] return [ SigD f (ForallT [KindedTV a2 (AppT (ConT ''Maybe) (VarT a1))] [] (ConT ''Int)) , ValD (VarP f) (NormalB (LitE (IntegerL 42))) [] ]) }}} {{{ $ /opt/ghc/7.10.3/bin/ghci Works.hs -ddump-splices GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Works ( Works.hs, interpreted ) Works.hs:(9,3)-(14,13): Splicing declarations do { TyConI (DataD _ _ [KindedTV a1_a3jt _] _ _) <- reify ''Maybe; [f_a3nh, a2_a3ni] <- mapM newName ["f", "a"]; return [SigD f_a3nh (ForallT [KindedTV a2_a3ni (AppT (ConT ''Maybe) (VarT a1_a3jt))] [] (ConT ''Int)), ValD (VarP f_a3nh) (NormalB (LitE (IntegerL 42))) []] } ======> f_a4vc :: forall (a_a4vd :: Maybe a_a4v3). Int f_a4vc = 42 Ok, modules loaded: Works. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13868: Improved help suggested in the error message about "import".
by GHC 24 Jun '17

24 Jun '17

#13868: Improved help suggested in the error message about "import". -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I know that improving error messages is a headache in Haskell. But we still need to point out the mistakes or the nonsense. Here are some examples of import test "module" at the beginning of the program (any). I randomly chose the "Data" module. Below each import, the response from GHC. And below, my opinion.\\ {{{ import Data.Aaa Failed to load interface for `Data.Aaa' Perhaps you meant Data.Data (from base-4.9.1.0) Data.Map (from containers-0.5.7.1) }}} No relationship.\\ {{{ import Data.Bbb Failed to load interface for `Data.Bbb' }}} Ok.\\ {{{ import Data.Ccc Failed to load interface for `Data.Ccc' }}} Ok.\\ {{{ import Data.Ddd Failed to load interface for `Data.Ddd' Perhaps you meant Data.Ord (from base-4.9.1.0) }}} No relationship.\\ {{{ import Data.Eee Failed to load interface for `Data.Eee' Perhaps you meant Data.Eq (from base-4.9.1.0) Data.Set (from containers-0.5.7.1) Data.Tree (from containers-0.5.7.1) }}} No relationship.\\ I stopped looking because I do not know how to correct it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13868> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining.
by GHC 24 Jun '17

24 Jun '17

#11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language PatternSynonyms , ViewPatterns #-} import Text.Read -- pattern PRead :: () => Read a => a -> String pattern PRead a <- (readMaybe -> Just a) foo :: String -> Int foo (PRead x) = (x::Int) foo (PRead xs) = sum (xs::[Int]) foo _ = 666 bar :: String -> Int bar (readMaybe -> Just x) = (x::Int) bar (readMaybe -> Just xs) = sum (xs::[Int]) bar _ = 666 main :: IO () main = do print $ foo "1" -- 1 print $ foo "[1,2,3]" -- 666 -- ??? print $ foo "xxx" -- 666 print $ bar "1" -- 1 print $ bar "[1,2,3]" -- 6 print $ bar "xxx" -- 666 }}} I'm expecting that semantics of the function `foo` would not change if I inline pattern synonym. However it does. `bar` successfully matches string against list of ints, whereas `foo` apperently skips this pattern and fall back to the catch-all case. Reproducible both in GHCi and GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #13856: "Zero-argument" lambda expressions from pretty-print strangely
by GHC 24 Jun '17

24 Jun '17

#13856: "Zero-argument" lambda expressions from pretty-print strangely -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | 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: -------------------------------------+------------------------------------- An amusing corner case of the language is that you can constructor lambdas with zero arguments using Template Haskell: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH f :: Int f = $(lamE [] [| 42 |]) }}} But if you try to compile that with `-ddump-splices` on, it'll look quite funny: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs -ddump-splices GHCi, version 8.2.0.20170616: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:6:7-22: Splicing expression lamE [] [| 42 |] ======> \ -> 42 Ok, modules loaded: Main. }}} Oh dear, `\ -> 42` isn't a valid expression at all. The same thing happens with the Template Haskell pretty-printer: {{{ λ> import Language.Haskell.TH λ> :set -XTemplateHaskell λ> putStrLn $(lamE [] [| 42 |] >>= stringE . pprint) <interactive>:4:12-48: Splicing expression lamE [] [| 42 |] >>= stringE . pprint ======> "\ -> 42" \ -> 42 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13856> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13869: Improved response from GHCi about ":l" or ":r".
by GHC 24 Jun '17

24 Jun '17

#13869: Improved response from GHCi about ":l" or ":r". -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I inadvertently wrote {{{:l}}} instead of {{{:r}}} and after typing on "return" GHCi replied\\ {{{ Prelude> :l Ok, modules loaded: none. }}} It disturbed me for a few moments. Why OK? Sorry but again this does not make sense here. The interpreter does not load anything. It is better to say\\ {{{ Failed, modules loaded: none. }}} And so after I write\\ {{{ Prelude> :r Ok, modules loaded: none. }}} Here too it is better to say\\ {{{ Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13869> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0