- ghc-tickets - Haskell.org

[GHC] #7645: Parens in an error message
by GHC 14 Feb '13

14 Feb '13

#7645: Parens in an error message -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #7609 -----------------------------+---------------------------------------------- {{{ {-# LANGUAGE TypeOperators #-} data (+) a b f :: ((+) a a, Maybe) f = undefined }}} gives {{{ X.hs:3:16: Expecting one more argument to `Maybe' In the type signature for `f': f :: (+ a a, Maybe) }}} which should be `(+) a a`. I tried {{{ #!diff diff --git a/compiler/hsSyn/HsTypes.lhs b/compiler/hsSyn/HsTypes.lhs index 74aa477..d0d9e1a 100644 --- a/compiler/hsSyn/HsTypes.lhs +++ b/compiler/hsSyn/HsTypes.lhs @@ -614,7 +614,7 @@ ppr_mono_ty ctxt_prec (HsForAllTy exp tvs ctxt ty) ppr_mono_ty _ (HsBangTy b ty) = ppr b <> ppr_mono_lty pREC_CON ty ppr_mono_ty _ (HsQuasiQuoteTy qq) = ppr qq ppr_mono_ty _ (HsRecTy flds) = pprConDeclFields flds -ppr_mono_ty _ (HsTyVar name) = ppr name +ppr_mono_ty _ (HsTyVar name) = pprPrefixOcc name ppr_mono_ty prec (HsFunTy ty1 ty2) = ppr_fun_ty prec ty1 ty2 ppr_mono_ty _ (HsTupleTy con tys) = tupleParens std_con (interpp'SP tys) where std_con = case con of }}} but this causes the kind * to be printed as (*). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 14 Feb '13

14 Feb '13

#4012: Compilation results are not deterministic -------------------------------+-------------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Difficulty: Difficult (2-5 days) Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by refold): * cc: the.dead.shall.rise@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4012#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7674: Separate StablePtr table from StableName table.
by GHC 14 Feb '13

14 Feb '13

#7674: Separate StablePtr table from StableName table. -----------------------------+---------------------------------------------- Reporter: EyalLotem | Owner: EyalLotem Type: task | Status: new Priority: normal | Component: Runtime System Version: 7.6.2 | Keywords: rts stable_ptr stable_name performance Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Currently, there is one table for these two difference concepts which makes each one of them less efficient. The patches that address this improve some benchmarks' performance by a factor of ~3. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #876: Length is not a good consumer
by GHC 14 Feb '13

14 Feb '13

#876: Length is not a good consumer --------------------------------------+------------------------------------- Reporter: ariep@… | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: fixed | Keywords: length Os: Linux | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: perf/should_run/T876 | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: list003 => perf/should_run/T876 * resolution: => fixed Comment: This patch to `GHC.List` makes `length` a good consumer, for what it's worth. The nofib numbers didn't budge. Simon {{{ commit 82f56e5a331f9bbd5c8afda9e8d8ad71059e934b Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu Feb 14 08:22:08 2013 +0000 Make 'length' into a good consumer, fixing Trac #876 Trac #876 is the oldest ticket I have fixed in a long time. I finally figured out how to make foldr behave in a non space-leaky way for length. Thanks to Andy for re-opening. >--------------------------------------------------------------- GHC/List.lhs | 23 ++++++++++++++++++----- 1 files changed, 18 insertions(+), 5 deletions(-) diff --git a/GHC/List.lhs b/GHC/List.lhs index 02d6965..049aa2a 100644 --- a/GHC/List.lhs +++ b/GHC/List.lhs @@ -114,12 +114,25 @@ null (_:_) = False -- | /O(n)/. 'length' returns the length of a finite list as an 'Int'. -- It is an instance of the more general 'Data.List.genericLength', -- the result type of which may be any kind of number. +{-# NOINLINE [1] length #-} length :: [a] -> Int -length l = len l 0# - where - len :: [a] -> Int# -> Int - len [] a# = I# a# - len (_:xs) a# = len xs (a# +# 1#) +length l = lenAcc l 0# + +lenAcc :: [a] -> Int# -> Int +lenAcc [] a# = I# a# +lenAcc (_:xs) a# = lenAcc xs (a# +# 1#) + +incLen :: a -> (Int# -> Int) -> Int# -> Int incLen _ g x = g (x +# 1#) + +-- These rules make length into a good consumer +-- Note that we use a higher-order-style use of foldr, so that +-- the accumulating parameter can be evaluated strictly +-- See Trac #876 for what goes wrong otherwise {-# RULES +"length" [~1] forall xs. length xs = foldr incLen I# xs 0# +"lengthList" [1] foldr incLen I# = lenAcc #-} -- | 'filter', applied to a predicate and a list, returns the list of -- those elements that satisfy the predicate; i.e., }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/876#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7649: BangPatterns + ViewPatterns
by GHC 14 Feb '13

14 Feb '13

#7649: BangPatterns + ViewPatterns ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ This program: {{{ {-# LANGUAGE ViewPatterns, BangPatterns #-} import Control.Exception main :: IO () main = do print (f False) print (f True) print (g undefined) `catchE` \_ -> putStrLn "g exception" print (h undefined) `catchE` \_ -> putStrLn "h exception" print (i undefined) `catchE` \_ -> putStrLn "i exception" putStrLn "Done" f :: Bool -> String f (view -> Nothing) = "Got Nothing" f (view -> Just x) = "Got Just " ++ show x g :: Bool -> String g (view -> x) = "g Got something" h :: Bool -> String h (view -> !x) = "h Got something" i :: Bool -> String i !(view -> x) = "i Got something" view :: Bool -> Maybe Int view False = Nothing view True = Just 5 catchE :: IO a -> (ErrorCall -> IO a) -> IO a catchE = catch }}} prints: {{{ "Got Nothing" "Got Just 5" "g Got something" "h exception "i Got something" Done }}} but presumably `i` ought to be strict in `x`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7683: Expose tcIfaceExpr
by GHC 14 Feb '13

14 Feb '13

#7683: Expose tcIfaceExpr -----------------------------+---------------------------------------------- Reporter: afarmer | Owner: Type: feature request | Status: new Priority: normal | Component: GHC API Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The tcIface module exports: {{{ tcExtCoreBindings :: [IfaceBinding] -> IfL CoreProgram }}} which is useful for typechecking whole programs in Iface Core. It unfortunately does not export: {{{ tcIfaceExpr :: IfaceExpr -> IfL CoreExpr }}} This function would be useful to the HERMIT plugin, where we want to parse and typecheck Core fragments by way of Iface Core. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7658: Support empty record update syntax
by GHC 14 Feb '13

14 Feb '13

#7658: Support empty record update syntax -----------------------------+---------------------------------------------- Reporter: glguy | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Empty record update syntax would be useful for when you are changing phantom type parameters. It is currently explicitly disallowed, but it isn't clear if that is absolutely necessary to me. {{{ data R phantom = C { a,b :: Int } r :: R Int r = C 1 2 --This is OK r1 :: R Char r1 = r { a = a r } --Why not this? r2 :: R Char r2 = r {} }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics
by GHC 14 Feb '13

14 Feb '13

#1171: GHC doesn't respect the imprecise exceptions semantics -------------------------------+-------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: cg059 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by igloo): Is your last example right? `f` isn't used -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1171#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics
by GHC 14 Feb '13

14 Feb '13

#1171: GHC doesn't respect the imprecise exceptions semantics -------------------------------+-------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: cg059 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by simonpj): Simon PJ and Simon M also discussed `throwIO`, which is a bit more preditable than `throw`. Specifically: {{{ throw e `seq` x ===> throw e throwIO e `seq` x ===> x }}} However, `throwIO` currently is still just as strict as `throw`. For example: {{{ f :: (Int,Int) -> IO a f x = throwIO (ErrorCall "urk") main = throwIO (error "yes") }}} This will throw `(error "yes")` because `throwIO` evaluates (but doesn't unbox) its argument because `throwIO` is strict. We could artificially make `throwIO` appear not to diverge, even when given two arguments (ie including the state token). That would have a much less bad effect than making `error` or `throw` appear not to diverge; and would make `throwIO` still more predictable, but I don't know how large the effect would be. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1171#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics
by GHC 14 Feb '13

14 Feb '13

#1171: GHC doesn't respect the imprecise exceptions semantics -------------------------------+-------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: cg059 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by simonpj): Here are some more notes about this subject, culled from an exchange betwen Simon M and Simon PJ. Consider this: {{{ f :: Bool -> (Int,Int) -> Int f x y = case x of True -> error "urk" False -> case y of (a,b) -> a+b }}} Can we pass y unboxed? Yes, we do so, because we regard bottom (the error branch) as hyperstrict in everything. So we do a w/w split thus {{{ f x y = case y of (a,b) -> case a of I# a1 -> case b of I# b1 -> fw x a1 b1 }}} That means, of course, that `(f True (error "a", 3))` would throw `(error "a")` not `(error "urk")`. The paper doesn't allow this, but I believe that it's crucial for strictness analysis to work well. However, if the function unconditionally diverges, it seems stupid to unbox: {{{ f :: (Int,Int) -> a f x = error "urk" }}} Here it seems fruitless to do the same w/w/ split as I gave above, even though the semantics justifies it equally. So pragmatically we do NOT do w/w for a hyper-strict demand. Another variant: {{{ f :: (Int,Int) -> a f (x,y) = error (show x) main = ...(f (3, error "no no"))... }}} Similar to the previous example, the `(error "no no")` is not even used, so it would be very odd indeed to evaluate it before the call to `f`. See {{{ Note [Unpacking arguments with product and polymorphic demands] }}} in `stranal/WwLib`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1171#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0