October 2017 - ghc-tickets

[GHC] #14350: Infinite loop when typechecking incorrect implementation (GHC HEAD only)
by GHC 19 Oct '17

19 Oct '17

#14350: Infinite loop when typechecking incorrect implementation (GHC HEAD only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On GHC HEAD, typechecking this program loops infinitely: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind data Proxy a = Proxy data family Sing (a :: k) data SomeSing k where SomeSing :: Sing (a :: k) -> SomeSing k class SingKind k where type Demote k :: Type fromSing :: Sing (a :: k) -> Demote k toSing :: Demote k -> SomeSing k data instance Sing (x :: Proxy k) where SProxy :: Sing 'Proxy instance SingKind (Proxy k) where type Demote (Proxy k) = Proxy k fromSing SProxy = Proxy toSing Proxy = SomeSing SProxy data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 type a @@ b = Apply a b infixl 9 @@ newtype instance Sing (f :: k1 ~> k2) = SLambda { applySing :: forall t. Sing t -> Sing (f @@ t) } instance (SingKind k1, SingKind k2) => SingKind (k1 ~> k2) where type Demote (k1 ~> k2) = Demote k1 -> Demote k2 fromSing sFun x = case toSing x of SomeSing y -> fromSing (applySing sFun y) toSing = undefined dcomp :: forall (a :: Type) (b :: a ~> Type) (c :: forall (x :: a). Proxy x ~> b @@ x ~> Type) (f :: forall (x :: a) (y :: b @@ x). Proxy x ~> Proxy y ~> c @@ ('Proxy :: Proxy x) @@ y) (g :: forall (x :: a). Proxy x ~> b @@ x) (x :: a). Sing f -> Sing g -> Sing x -> c @@ ('Proxy :: Proxy x) @@ (g @@ ('Proxy :: Proxy x)) dcomp f g x = applySing f Proxy Proxy }}} This is a regression from GHC 8.2.1/8.2.2, where it gives a proper error message: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:60:15: error: • Couldn't match expected type ‘Proxy a2 -> Apply (Apply (c x4) 'Proxy) (Apply (g x4) 'Proxy)’ with actual type ‘Sing (f x y @@ t0)’ • The function ‘applySing’ is applied to three arguments, but its type ‘Sing (f x y) -> Sing t0 -> Sing (f x y @@ t0)’ has only two In the expression: applySing f Proxy Proxy In an equation for ‘dcomp’: dcomp f g x = applySing f Proxy Proxy • Relevant bindings include x :: Sing x4 (bound at Bug.hs:60:11) g :: Sing (g x3) (bound at Bug.hs:60:9) f :: Sing (f x2 y) (bound at Bug.hs:60:7) dcomp :: Sing (f x2 y) -> Sing (g x3) -> Sing x4 -> (c x4 @@ 'Proxy) @@ (g x4 @@ 'Proxy) (bound at Bug.hs:60:1) | 60 | dcomp f g x = applySing f Proxy Proxy | ^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:60:27: error: • Couldn't match expected type ‘Sing t0’ with actual type ‘Proxy a0’ • In the second argument of ‘applySing’, namely ‘Proxy’ In the expression: applySing f Proxy Proxy In an equation for ‘dcomp’: dcomp f g x = applySing f Proxy Proxy • Relevant bindings include x :: Sing x4 (bound at Bug.hs:60:11) g :: Sing (g x3) (bound at Bug.hs:60:9) f :: Sing (f x2 y) (bound at Bug.hs:60:7) dcomp :: Sing (f x2 y) -> Sing (g x3) -> Sing x4 -> (c x4 @@ 'Proxy) @@ (g x4 @@ 'Proxy) (bound at Bug.hs:60:1) | 60 | dcomp f g x = applySing f Proxy Proxy | ^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13385: ghci fails to start when -XRebindableSyntax is passed
by GHC 19 Oct '17

19 Oct '17

#13385: ghci fails to start when -XRebindableSyntax is passed -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 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: -------------------------------------+------------------------------------- Running "ghci -XRebindableSyntax" yields the following output: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help <interactive>:1:6: error: Not in scope: ‘>>’ <interactive>:1:70: error: Not in scope: ‘>>’ <interactive>:1:135: error: Not in scope: ‘return’ }}} This appears to be a regression, as it does not occur with ghc-7.10.3. Originally reported as a stack issue by Michal Konecny - https://github.com/commercialhaskell/stack/issues/3043 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14367: Lazy evaluation can be invalidated
by GHC 19 Oct '17

19 Oct '17

#14367: Lazy evaluation can be invalidated -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Evaluating arguments only if and when they are needed. This is the first principle of lazy evaluation.\\ Example:\\ {{{ Prelude> let f True x y = x Prelude> f True 3 (3/0) 3 }}} Good answer! See this:\\ {{{ Prelude> f True 8 undefined 8 }}} and:\\ {{{ Prelude> f True undefined 8 *** Exception: Prelude.undefined CallStack (from HasCallStack): error, called at libraries\base\GHC\Err.hs:79:14 in base:GHC.Err undefined, called at <interactive>:2:8 in interactive:Ghci2 }}} These results are all correct because the evaluated expression (function) is non-strict.\\ The same expression below with a changed argument:\\ {{{ Prelude> f True 3 _ <interactive>:54:10: error: * Found hole: _ :: p20 Where: `p20' is an ambiguous type variable * In the third argument of `f', namely `_' In the expression: f True 3 _ In an equation for `it': it = f True 3 _ * Relevant bindings include it :: p1 (bound at <interactive>:54:1) }}} I understand this error, it is legitimate except that here, in this specific case, I would never use this expression.( i.e{{{_}}}) or the result of that expression if that result were to be used. Here the error message should not have priority. \\ This argument ( i.e {{{_}}}) does not need to be evaluated to calculate the result.\\ With Normal-Order Reduction, an expression is reduced only when absolutely necessary to continue the reduction.\\ So, here, who cares! Since this expression (i.e{{{_}}}), or the result is supposed never to be used.\\ It is the same for this example:\\ {{{ Prelude> f True 3 r <interactive>:55:10: error: Variable not in scope: r }}} Idem, here the error message should not have priority. About {{{r}}} here, who cares! \\ By contrast here in this other example,{{{r}}} must be in the scope to be used:\\ {{{ Prelude> let g x t = x + t + r <interactive>:56:21: error: Variable not in scope: r }}} Anyway,{{{(+)}}} is strict in both arguments.\\ I think leaving the priority to lazy evaluation will bring much more consistency in the results. Of course, ghc would take this error into account and send it after the compilation if needed. \\ These examples are not exaustive examples. See ticket [ticket:14355]. (although in this ticket, the thing is slightly different). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14367> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible
by GHC 19 Oct '17

19 Oct '17

#11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.11 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: -------------------------------------+------------------------------------- While helping a Haskell beginner today, we came across this behavior and I wondered why there wasn't already a ticket for this problem in the tracker. In fact, this is technically a duplicate of #3217, but that ticket is long (and it was difficult to find!) so I just want to file a new ticket to summarize what needs to be done. The essential problem is that a user is editing a file that looks like this: {{{ {-# LANGUAGE OverloadedStrings #-} module A where ... some code ... }}} and they load this into ghci with `ghci A.hs`. They then might reasonably type a string into the GHCi prompt and expect it to be overloaded... but it will not be! They had to have invoked GHCi with `ghci -XOverloadedStrings A.hs`. This behavior is unexpected and not very nice. The proposal is this: (from https://ghc.haskell.org/trac/ghc/ticket/3217#comment:15) GHCi should be changed so that at most one module is "fully open", currently denoted *M in GHCi's prompt. If a module M is "fully open", expressions typed at the GHCi prompt are interpreted (roughly) as if they were written in M itself. Specifically: * All the top-level things in the module are in scope * The per-module flags in {-# OPTIONS #-} and {-# LANGUAGE #-} pragmas * M's default declaration holds Note that currently more than one module can be fully open, and their top level scopes are merged. We propose to make that at most one. When compiling an expression typed on the GHCi command line: * Start with the baseline DynFlags * Apply flags specified on the original command-line * (Perhaps: apply flags specified by :set in this GHCi session. We aren't sure whether or not to do this.) * Apply GHCi baseline command-prompt flags (e.g. special defaulting rules) * Apply flags specified by :seti in this GHCi session * If there is a fully-open module M, apply flags specified in M itself. That is, flags in M get the last word. Implementing this plan will require some representation changes. In particular, since we need to apply M's source-code flags in two difference places, we really need to remember the diffs with M, perhaps as a `(DynFlags -> DynFlags)` function or something. See also: https://ghc.haskell.org/trac/ghc/ticket/3217#comment:28 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11469> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14362: Allow: Coercing (a:~:b) to (b:~:a)
by GHC 19 Oct '17

19 Oct '17

#14362: Allow: Coercing (a:~:b) to (b:~:a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: roles | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Is there *any* sensible way to enable coercing [https://hackage.haskell.org/package/base-4.10.0.0/docs/Data-Type- Equality.html#t::-126-: (:~:)] swapping its arguments {{{#!hs coerce :: a:~:b -> b:~:a }}} Same for [https://hackage.haskell.org/package/base-4.10.0.0/docs/Data- Type-Coercion.html#t:Coercion Coercion] {{{#!hs coerce :: Coercion a b -> Coercion b a }}} Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14371: ghc: panic! when reloading file with code
by GHC 18 Oct '17

18 Oct '17

#14371: ghc: panic! when reloading file with code -------------------------------------+------------------------------------- Reporter: xvrbka1 | 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: -------------------------------------+------------------------------------- Hello, I have no idea what causes it (maybe my mistake) so I probably will give you more code then necessaty. Sorry for that. \\ **I had working code:** {{{ f :: [[Bool]] -> ([Bool], [[Bool]]) f [] = ([True], g []) f (x:xs) = (g x, g xs) g :: [a] -> [a] g [] = [] g x = x listITE :: [Bool] -> [a] -> [a] -> [a] listITE [] _ _ = [] listITE _ _ [] = [] listITE _ [] _ = [] listITE (b:bs) (x:xs) (y:ys) = [(if b then x else y)] ++ listITE bs xs ys --zipWith (\x,y -> if ) ; firstMatch :: (a -> a -> Bool) -> [a] -> a -> a firstMatch _ [] y = y firstMatch p (x:s) y = if index >= (length (x:s)) then y else (x:s) !! index where index = indexOf True (zipWith p (x:s) s) indexOf :: (Eq a) => a -> [a] -> Int indexOf _ [] = 10 indexOf c (x:s) = if c==x then 0 else 1 + indexOf c s }}} that I could load, run and reload. \\ ** After I wrote this and tried to reload:** {{{ countInversions :: (Ord a) => [a] -> Int countInversions [] = 0 countInversions (x:s) = (countSame (True==) (map (x>) s)) + countInversions s countSame :: (Ord a) => (a -> Bool) [a] -> Int countSame _ [] = 0; countSame p (x:s) = (if p x then 1 else 0) + indexOf c s }}} \\ **I get error:** ''ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): repSplitAppTys a_a6Xb[sk:1] Bool [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type'' \\ I hope I found u a bug :) \\ Have a nice day -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11343: Unable to infer type when using DuplicateRecordFields
by GHC 18 Oct '17

18 Oct '17

#11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- It seems to me that GHC should be able to easily infer the types for the record updates in this simple example. Is there a reason that it is unable to infer the type currently? {{{ {-# LANGUAGE OverloadedLabels, DuplicateRecordFields #-} module C where main = do print aThing print bThing print (aThing { a = 5 } ) print (bThing { a = 5 } ) data B = B { a :: Int} deriving Show bThing = B 10 data A = A { a :: Int } deriving Show aThing = A 10 {- [1 of 1] Compiling C ( C.hs, C.o ) C.hs:7:10: error: • Record update is ambiguous, and requires a type signature • In the first argument of ‘print’, namely ‘(aThing {a = 5})’ In a stmt of a 'do' block: print (aThing {a = 5}) In the expression: do { print aThing; print bThing; print (aThing {a = 5}); print (bThing {a = 5}) } -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11343> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14323: Occurs check regressions in GHC 8.2.1 (and HEAD)
by GHC 18 Oct '17

18 Oct '17

#14323: Occurs check regressions in GHC 8.2.1 (and HEAD) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | 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: -------------------------------------+------------------------------------- Inspired by adamse's comment at https://ghc.haskell.org/trac/ghc/ticket/14317#comment:3, I've discovered some programs which behave differently on GHC 8.0.2, 8.2.1, and HEAD. ----- First, there's this program: {{{#!hs {-# LANGUAGE GADTs #-} hm1 :: b ~ f b => b -> f b hm1 x = x }}} On GHC 8.0.2, this compiles (with a warning): {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:4:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘hm1’: hm1 x = ... }}} But on GHC 8.2.1, it errors: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:4:9: error: • Could not deduce: b ~ f b from the context: b ~ f b bound by the type signature for: hm1 :: forall b (f :: * -> *). b ~ f b => b -> f b at Bug.hs:3:1-26 ‘b’ is a rigid type variable bound by the type signature for: hm1 :: forall b (f :: * -> *). b ~ f b => b -> f b at Bug.hs:3:1-26 • In the expression: x In an equation for ‘hm1’: hm1 x = x • Relevant bindings include x :: b (bound at Bug.hs:4:5) hm1 :: b -> f b (bound at Bug.hs:4:1) | 4 | hm1 x = x | ^ }}} And on GHC HEAD, it fails with a different error! {{{ GHCi, version 8.3.20171004: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:4:9: error: • Occurs check: cannot construct the infinite type: b ~ f b • In the expression: x In an equation for ‘hm1’: hm1 x = x • Relevant bindings include x :: b (bound at Bug.hs:4:5) hm1 :: b -> f b (bound at Bug.hs:4:1) | 4 | hm1 x = x | ^ }}} The same errors occur if you give `hm1` the type `hm1 :: b ~ f b => f b -> b`. ----- What happens if you try `Coercible` instead of `(~)`? Consider this variant of the program above: {{{#!hs {-# LANGUAGE GADTs #-} import Data.Coerce hm2 :: Coercible b (f b) => b -> f b hm2 = coerce }}} On GHC 8.0.2, 8.2.1, and HEAD, this compiles (without warnings). Good. But if you change the type to use the symmetric version of that constraint: {{{#!hs {-# LANGUAGE GADTs #-} import Data.Coerce hm3 :: Coercible (f b) b => b -> f b hm3 = coerce }}} Then on GHC 8.0.2, it compiles without warnings, but on 8.2.1 and HEAD it fails! Here is the error with 8.2.1: {{{ Bug3.hs:6:7: error: • Could not deduce: Coercible b (f b) arising from a use of ‘coerce’ from the context: Coercible (f b) b bound by the type signature for: hm3 :: forall (f :: * -> *) b. Coercible (f b) b => b -> f b at Bug3.hs:5:1-36 ‘b’ is a rigid type variable bound by the type signature for: hm3 :: forall (f :: * -> *) b. Coercible (f b) b => b -> f b at Bug3.hs:5:1-36 • In the expression: coerce In an equation for ‘hm3’: hm3 = coerce • Relevant bindings include hm3 :: b -> f b (bound at Bug3.hs:6:1) | 6 | hm3 = coerce | ^^^^^^ }}} And on HEAD: {{{ Bug3.hs:6:7: error: • Occurs check: cannot construct the infinite type: b ~ f b arising from a use of ‘coerce’ • In the expression: coerce In an equation for ‘hm3’: hm3 = coerce • Relevant bindings include hm3 :: b -> f b (bound at Bug3.hs:6:1) | 6 | hm3 = coerce | ^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving"
by GHC 17 Oct '17

17 Oct '17

#13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Nowhere in the documentation is it clearly stated which classes can be derived (assuming extensions as necessary) by GHC's "deriving" mechanism. As determined by reading the sources, this appears to be - Bounded, Enum, Eq, Ix, Ord, Read, Show, Functor, Foldable, Traversable, Generic, Generic1, Data, Lift. This was discussed on haskell-cafe -- see https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125379.html. PS: I would be willing to fix this myself, if only I knew *where* to insert that information so that it is easily ''findable''! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13175> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14357: Document deriving strategies fully
by GHC 17 Oct '17

17 Oct '17

#14357: Document deriving strategies fully -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- The users’ guide currently sais in the section on `DerivingStrategies`: > If an explicit deriving strategy is not given, GHC has an algorithm for determining how it will actually derive an instance. For brevity, the algorithm is omitted here. You can read the full algorithm at Wiki page. I think this is doing our users a disservice: They want to rely on the guide to have authorative, concise and clear information. The wiki page contains too much stuff that is confusing for users (Alternative syntax, rationales etc.) (Also, the link in the manual is wrong). Ryan, do you agree and are you available to put the relevant bits into the manual? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11