- ghc-devs - Haskell.org

RE: [GHC] #7631: Allow to differentiate between newtypes and datatypes when using Generics
by Simon Peyton-Jones 13 Feb '13

13 Feb '13

Thanks for fixing Pedro Our usual test-case nomenclature would be to use "T7631" as the test name. Not worth changing now. Simon | -----Original Message----- | From: ghc-tickets-bounces(a)haskell.org [mailto:ghc-tickets-bounces@haskell.org] | On Behalf Of GHC | Sent: 13 February 2013 10:44 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #7631: Allow to differentiate between newtypes and | datatypes when using Generics | | #7631: Allow to differentiate between newtypes and datatypes when using | Generics | ---------------------------------+------------------------------------------ | Reporter: Feuerbach | Owner: dreixel | Type: feature request | Status: closed | Priority: normal | Component: libraries (other) | Version: 7.7 | Resolution: fixed | Keywords: generics | Os: Unknown/Multiple | Architecture: Unknown/Multiple | Failure: None/Unknown | Blockedby: | Blocking: | Related: | | ---------------------------------+------------------------------------------ | Changes (by dreixel): | | * status: new => closed | * resolution: => fixed | | | Comment: | | Done. New test is `GenNewtype`. | | -- | Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7631#comment:4> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0

Re: RFC: Singleton equality witnesses
by Gabor Greif 13 Feb '13

13 Feb '13

Richard and all, sorry for reviving such an ancient thread, but I'd like to move this forward a bit :-) In the meantime Iavor has added the (:~:) GADT, so I can reuse it. It has been commented that it could (finally) end up in GHC.Exts, but for now I want my changes minimized. I have added the class @SingEquality@ and have implemented the @sameSing@ method in terms of Iavor's functions. This is rather pretty now. Here is the patch: ------------------------------------------------------ $ git show 0eacf265255b9c5e0191b6a5100f3076b8eb5520 commit 0eacf265255b9c5e0191b6a5100f3076b8eb5520 Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Nov 30 12:23:28 2012 +0100 Introduce the SingEquality class with customizable witness type and a sameSing method that may produce the latter. diff --git a/GHC/TypeLits.hs b/GHC/TypeLits.hs index f8b759e..5546a5a 100644 --- a/GHC/TypeLits.hs +++ b/GHC/TypeLits.hs @@ -30,7 +30,7 @@ module GHC.TypeLits , type (-) -- * Comparing for equality - , type (:~:) (..), eqSingNat, eqSingSym + , type (:~:) (..), eqSingNat, eqSingSym, SingEquality (..) -- * Destructing type-nat singletons. , isZero, IsZero(..) @@ -56,6 +56,7 @@ import Unsafe.Coerce(unsafeCoerce) -- import Data.Bits(testBit,shiftR) import Data.Maybe(Maybe(..)) import Data.List((++)) +import Control.Monad (guard, return, (>>)) -- | (Kind) A kind useful for passing kinds as parameters. data OfKind (a :: *) = KindParam @@ -133,6 +134,11 @@ class (kparam ~ KindParam) => SingE (kparam :: OfKind k) where type DemoteRep kparam :: * fromSing :: Sing (a :: k) -> DemoteRep kparam +class (kparam ~ KindParam, SingE (kparam :: OfKind k)) => SingEquality (kparam :: OfKind k) where + type SameSing kparam :: k -> k -> * + type SameSing kparam = (:~:) + sameSing :: Sing a -> Sing b -> Maybe (SameSing kparam a b) + instance SingE (KindParam :: OfKind Nat) where type DemoteRep (KindParam :: OfKind Nat) = Integer fromSing (SNat n) = n @@ -141,6 +147,12 @@ instance SingE (KindParam :: OfKind Symbol) where type DemoteRep (KindParam :: OfKind Symbol) = String fromSing (SSym s) = s +instance SingEquality (KindParam :: OfKind Nat) where + sameSing = eqSingNat + +instance SingEquality (KindParam :: OfKind Symbol) where + sameSing = eqSingSym + {- | A convenient name for the type used to representing the values for a particular singleton family. For example, @Demote 2 ~ Integer@, and also @Demote 3 ~ Integer@, but @Demote "Hello" ~ String@. -} ------------------------------------------------------ Regarding Richard's decidable equality suggestion, I think this would be the next step. IIRC, empty case expressions have been implemented, so GHC HEAD should be prepared. What do you think? Okay to push in this form? Cheers, Gabor On 12/5/12, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > I don't think anything here is *high priority*, just musings on how best to > move forward. > > About empty case, consider this: > >> data a :~: b where >> Refl :: a :~: a >> >> absurd :: True :~: False -> a > > Now, I want to write a term binding for absurd. GHC can figure out that > (True :~: False) is an empty type. So, if we have (absurd x = case x of …), > there are no valid patterns, other than _, that could be used. Instead of > writing (absurd _ = undefined), I would much prefer to write (absurd x = > case x of {}). Why? If I compile with -fwarn-incomplete-patterns and > -Werror, then the latter has no possible source of partiality and yet > compiles. The former looks dangerous, and GHC doesn't check to make sure > that, in fact, the function can never get called. > > The bottom line, for me at least, is that I want to avoid the partial > constructs (incomplete patterns, undefined, etc) in Haskell as much as > possible, especially when I'm leveraging the type system to a high degree. > The lack of empty case statements forces me to use undefined where it isn't > really necessary. > > I'll leave it to others to comment on TypeRep, as I'm a little hazy there > myself. > > Richard > >

5 14

[PATCH] GHC_CONVERT_VENDOR: allow 'w64' vendor, like x86_64-w64-mingw32
by Sergei Trofimovich 12 Feb '13

12 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Gentoo calls 'w64' a mingw flavour with mingw-w64 runtime. Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- aclocal.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aclocal.m4 b/aclocal.m4 index 9f9593a..30d492c 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -1812,7 +1812,7 @@ case "$1" in # converts vendor from gnu to ghc naming, and assigns the result to $target_var AC_DEFUN([GHC_CONVERT_VENDOR],[ case "$1" in - pc|gentoo) # like i686-pc-linux-gnu and i686-gentoo-freebsd8 + pc|gentoo|w64) # like i686-pc-linux-gnu, i686-gentoo-freebsd8, x86_64-w64-mingw32 $2="unknown" ;; softfloat) # like armv5tel-softfloat-linux-gnueabi -- 1.8.1.1

2 1

RE: GHC 7.8 release?
by Simon Peyton-Jones 12 Feb '13

12 Feb '13

(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. These must be social questions (what I was earlier calling “signposting”) rather than technical ones. For example, you say that (b) is not subject to any variety of reason, and yet no linux distribution tracks HEAD, does it? They don’t openly insult anyone who points to a release just because HEAD has new cool stuff! No, they track things we call “releases”. Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP. Or something. I’m just looking for a way to reconcile · Release early, release often · Stability for the Haskell Platform It seems to me that such a reconciliation is within reach, and is actually very close to what we do, if we only signpost what is what far more vigorously and clearly than we do now. But maybe I’m wrong. Simon From: Brandon Allbery [mailto:allbery.b@gmail.com] Sent: 11 February 2013 01:15 To: Simon Peyton-Jones Cc: Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; kostirya(a)gmail.com; glasgow-haskell-users; ghc-devs(a)haskell.org; Edsko de Vries Subject: Re: GHC 7.8 release? On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: What causes the "wave of package updates"? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. (a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason. It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com<mailto:allbery.b@gmail.com> ballbery(a)sinenomine.net<mailto:ballbery@sinenomine.net> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

8 9

RFC: Changes to help GHCJS, GHC API multi-target cross compile
by Luite Stegeman 12 Feb '13

12 Feb '13

Hi all, I'm looking for comments on two minor patches that would greatly help GHCJS [1]. The goal is to make a cabal-installable GHCJS compiler that uses the GHC API to generate both JavaScript (always 32 bit) and native code (to run Template Haskell). This way we can release updates frequently and have an easy installation procedure for users. I have an experimental branch [2] that uses the patches below to make working compiler that can generate 32 bit JavaScript from a 64 bit host compiler, with working TH. 1. Add a Way for custom build tags. Since we generate code for two architectures, we need to make sure that we don't mix the native and JavaScript .hi files. Setting the buildTag manually in DynFlags does not work, because it gets reset every time a file is preprocessed (due to OPTIONS pragma handling). This patch adds an extra Way that just adds something to the build tag, it could be extended to also add custom program options and extras. 2. Make GHC.Prim interface overridable. Since JavaScript does not support 64 bit integers, we want to generate 32 bit code, even if our host platform is 64 bit. HEAD has wORD_SIZE_IN_BITS already configurable though DynFlags, but unfortunately the primop interface (GHC.Prim) is also platform dependent, some primops have a different type on a 64 bit system. This patch makes it possible for a GHC API user to supply a custom interface for GHC.Prim. It's rather hacky, requires an extra hs-boot file and requires the user to mess with the NameCache to make it work correctly [3]. Probably a stopgap measure until GHC supports multitarget cross compilation out of the box. Is there a better way of doing this? Luite [1] https://github.com/ghcjs [2] https://github.com/ghcjs/ghcjs/tree/gen2-64 [3] https://github.com/ghcjs/ghcjs/blob/1a84f82fa149b4e9510586c10864694efe7820b…

2 1

RE: [commit: ghc] master: Fix Trac #7681. (7b098b6)
by Simon Peyton-Jones 12 Feb '13

12 Feb '13

Thanks for fixing. You removed lookupType_mod from TrieMap. It was defined and exported but not called. How did validate spot that? I'm sure there are quite a few such functions in GHC. Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Richard Eisenberg | Sent: 12 February 2013 04:10 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Fix Trac #7681. (7b098b6) | | Repository : ssh://darcs.haskell.org//srv/darcs/ghc | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/7b098b6009727a012cb1f3ff0c | a51698d302cae1 | | >--------------------------------------------------------------- | | commit 7b098b6009727a012cb1f3ff0ca51698d302cae1 | Author: Richard Eisenberg <eir(a)cis.upenn.edu> | Date: Mon Feb 11 23:07:25 2013 -0500 | | Fix Trac #7681. | | Removed checks for empty lists for case expressions and lambda-case. | If -XEmptyCase is not enabled, compilation still fails | (appropriately) | in the renamer. | | Had to remove dead code from TrieMap to pass the validator. | | >--------------------------------------------------------------- | | compiler/coreSyn/TrieMap.lhs | 38 +---------------------------------- | --- | compiler/deSugar/DsMeta.hs | 6 ++++-- | compiler/hsSyn/Convert.lhs | 8 ++------ | libraries/random | 2 +- | 4 files changed, 8 insertions(+), 46 deletions(-) | | diff --git a/compiler/coreSyn/TrieMap.lhs b/compiler/coreSyn/TrieMap.lhs | index 148464b..c013b5d 100644 | --- a/compiler/coreSyn/TrieMap.lhs | +++ b/compiler/coreSyn/TrieMap.lhs | @@ -14,7 +14,7 @@ | {-# LANGUAGE TypeFamilies #-} | module TrieMap( | CoreMap, emptyCoreMap, extendCoreMap, lookupCoreMap, foldCoreMap, | - TypeMap, foldTypeMap, lookupTypeMap_mod, | + TypeMap, foldTypeMap, -- lookupTypeMap_mod, | CoercionMap, | MaybeMap, | ListMap, | @@ -32,8 +32,6 @@ import UniqFM | import Unique( Unique ) | import FastString(FastString) | | -import Unify ( niFixTvSubst ) | - | import qualified Data.Map as Map | import qualified Data.IntMap as IntMap | import VarEnv | @@ -632,40 +630,6 @@ lkT env ty m | go (ForAllTy tv ty) = tm_forall >.> lkT (extendCME env tv) ty >=> | lkBndr env tv | | | -lkT_mod :: CmEnv | - -> TyVarEnv Type -- TvSubstEnv | - -> Type | - -> TypeMap b -> Maybe b | -lkT_mod env s ty m | - | EmptyTM <- m = Nothing | - | Just ty' <- coreView ty | - = lkT_mod env s ty' m | - | [] <- candidates | - = go env s ty m | - | otherwise | - = Just $ snd (head candidates) -- Yikes! | - where | - -- Hopefully intersects is much smaller than traversing the whole | vm_fvar | - intersects = eltsUFM $ | - intersectUFM_C (,) s (vm_fvar $ tm_var m) | - candidates = [ (u,ct) | (u,ct) <- intersects | - , Type.substTy (niFixTvSubst s) u `eqType` ty | ] | - | - go env _s (TyVarTy v) = tm_var >.> lkVar env v | - go env s (AppTy t1 t2) = tm_app >.> lkT_mod env s t1 >=> | lkT_mod env s t2 | - go env s (FunTy t1 t2) = tm_fun >.> lkT_mod env s t1 >=> | lkT_mod env s t2 | - go env s (TyConApp tc tys) = tm_tc_app >.> lkNamed tc >=> lkList | (lkT_mod env s) tys | - go _env _s (LitTy l) = tm_tylit >.> lkTyLit l | - go _env _s (ForAllTy _tv _ty) = const Nothing | - | - {- DV TODO: Add proper lookup for ForAll -} | - | -lookupTypeMap_mod :: TyVarEnv a -- A substitution to be applied to the | /keys/ of type map | - -> (a -> Type) | - -> Type | - -> TypeMap b -> Maybe b | -lookupTypeMap_mod s f = lkT_mod emptyCME (mapVarEnv f s) | - | ----------------- | xtT :: CmEnv -> Type -> XT a -> TypeMap a -> TypeMap a xtT env ty f m | diff --git a/compiler/deSugar/DsMeta.hs b/compiler/deSugar/DsMeta.hs | index 9a9f89d..4f5ba2d 100644 | --- a/compiler/deSugar/DsMeta.hs | +++ b/compiler/deSugar/DsMeta.hs | @@ -920,7 +920,8 @@ repE (HsLit l) = do { a <- repLiteral l; | repLit a } | repE (HsLam (MG { mg_alts = [m] })) = repLambda m repE (HsLamCase _ | (MG { mg_alts = ms })) | = do { ms' <- mapM repMatchTup ms | - ; repLamCase (nonEmptyCoreList ms') } | + ; core_ms <- coreList matchQTyConName ms' | + ; repLamCase core_ms } | repE (HsApp x y) = do {a <- repLE x; b <- repLE y; repApp a b} | | repE (OpApp e1 op _ e2) = | @@ -938,7 +939,8 @@ repE (SectionR x y) = do { a <- repLE x; b <- | repLE y; repSectionR a b } | repE (HsCase e (MG { mg_alts = ms })) | = do { arg <- repLE e | ; ms2 <- mapM repMatchTup ms | - ; repCaseE arg (nonEmptyCoreList ms2) } | + ; core_ms2 <- coreList matchQTyConName | ms2 | + ; repCaseE arg core_ms2 } | repE (HsIf _ x y z) = do | a <- repLE x | b <- repLE y | diff --git a/compiler/hsSyn/Convert.lhs b/compiler/hsSyn/Convert.lhs | index a21caf4..ce15071 100644 | --- a/compiler/hsSyn/Convert.lhs | +++ b/compiler/hsSyn/Convert.lhs | @@ -524,9 +524,7 @@ cvtl e = wrapL (cvt e) | cvt (AppE x y) = do { x' <- cvtl x; y' <- cvtl y; return $ | HsApp x' y' } | cvt (LamE ps e) = do { ps' <- cvtPats ps; e' <- cvtl e | ; return $ HsLam (mkMatchGroup | [mkSimpleMatch ps' e']) } | - cvt (LamCaseE ms) | - | null ms = failWith (ptext (sLit "Lambda-case expression | with no alternatives")) | - | otherwise = do { ms' <- mapM cvtMatch ms | + cvt (LamCaseE ms) = do { ms' <- mapM cvtMatch ms | ; return $ HsLamCase placeHolderType | (mkMatchGroup ms') | } | @@ -543,9 +541,7 @@ cvtl e = wrapL (cvt e) | ; return $ HsMultiIf placeHolderType alts' | } | cvt (LetE ds e) = do { ds' <- cvtLocalDecs (ptext (sLit "a let | expression")) ds | ; e' <- cvtl e; return $ HsLet ds' e' } | - cvt (CaseE e ms) | - | null ms = failWith (ptext (sLit "Case expression with no | alternatives")) | - | otherwise = do { e' <- cvtl e; ms' <- mapM cvtMatch ms | + cvt (CaseE e ms) = do { e' <- cvtl e; ms' <- mapM cvtMatch ms | ; return $ HsCase e' (mkMatchGroup ms') } | cvt (DoE ss) = cvtHsDo DoExpr ss | cvt (CompE ss) = cvtHsDo ListComp ss | diff --git a/libraries/random b/libraries/random index 0531d37..69bfde2 | 160000 | --- a/libraries/random | +++ b/libraries/random | @@ -1 +1 @@ | -Subproject commit 0531d37602d6e7c0b2b5adbf2d5fdd2d01830216 | +Subproject commit 69bfde219bab869729fdbe9c1496371f912bf41e | | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

Re: Patch to vector
by José Pedro Magalhães 12 Feb '13

12 Feb '13

Hi Roman, Just to remind you of the patch to vector I've previously sent you. Whenever you can apply it, we can remove the "temporary fix" patch on the GHC copy of the repo. Thanks, Pedro On Wed, Nov 28, 2012 at 3:03 PM, José Pedro Magalhães <jpm(a)cs.uu.nl> wrote: > Hi Roman, > > I'm attaching a patch to the vector package to make it derive Typeable > instances instead of defining them manually. GHC HEAD will soon ignore > handwritten Typeable instances, so this replacement is necessary. > > > Thanks, > Pedro > >

2 1

Missing change?
by Simon Peyton-Jones 12 Feb '13

12 Feb '13

Pedro: did you miss something? This is breaking my build. I have your last patch 12ba4321d34d646cf9040ad12810c4257d26ade9 Simon url = http://darcs.haskell.org/libraries/time.git/ libraries/time/Data/Time/Calendar/Days.hs:30:9: `typeOf' is not a (visible) method of class `Typeable' libraries/time/Data/Time/Calendar/Days.hs:30:32: Not in scope: `mkTyCon' Perhaps you meant `mkTyCon3' (imported from Data.Data)

2 2

nofib regressions in HEAD since 7.6.2 release
by Johan Tibell 12 Feb '13

12 Feb '13

Hi all, I just ran nofib on current HEAD and compared it to 7.6.2 on my 64-bit Linux machine. There are some regressions I think we should look into before a release: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna -0.8% +1.5% 0.08 0.08 +0.0% ansi -0.5% +0.5% 0.00 0.00 +0.0% atom -0.9% -0.0% -3.1% -0.8% +0.0% awards -0.9% +0.1% 0.00 0.00 +0.0% banner +0.1% +2.2% 0.00 0.00 +0.0% bernouilli -0.6% +2.7% 0.12 0.13 +0.0% boyer -0.7% +0.0% 0.03 0.04 +0.0% boyer2 -0.1% +0.0% 0.01 0.01 +0.0% bspt -0.6% -0.0% 0.01 0.02 +0.0% cacheprof -0.9% +6.9% +0.8% +4.0% +0.0% calendar -0.9% +0.1% 0.00 0.00 +0.0% cichelli -0.1% -0.0% 0.06 0.06 +9.4% circsim -0.7% +0.1% +1.6% +7.0% +13.6% clausify -0.8% +0.0% 0.03 0.03 +0.0% comp_lab_zift -0.7% +0.0% 0.14 0.14 -12.5% compress -0.1% +0.0% 0.12 0.13 +0.0% compress2 -0.0% +0.0% 0.12 0.14 +2.3% constraints -0.8% +0.0% -3.3% -0.7% +0.0% cryptarithm1 -0.1% +0.0% +2.1% +4.1% +0.0% cryptarithm2 -0.0% -0.8% 0.01 0.01 +0.0% cse -0.0% -0.0% 0.00 0.00 +0.0% eliza +0.1% +7.7% 0.00 0.00 +0.0% event -0.8% +0.0% 0.09 0.10 -8.7% exp3_8 -0.8% +0.0% 0.15 0.15 +100.0% expert -0.2% +18.4% 0.00 0.00 +0.0% fem +1.5% +0.5% 0.02 0.02 +0.0% fft -0.9% +0.0% 0.02 0.03 +0.0% fft2 +3.7% +31.9% 0.05 0.05 +20.0% fibheaps -1.0% +0.3% 0.03 0.03 +0.0% fish -0.0% -0.0% 0.01 0.01 +0.0% fluid -1.3% +13.0% 0.01 0.01 +0.0% fulsom -0.2% -0.0% 0.19 0.20 +8.3% gamteb -0.7% -0.2% 0.03 0.04 +0.0% gcd -0.8% +0.0% 0.02 0.03 +0.0% gen_regexps +0.0% +2.2% 0.00 0.00 +0.0% genfft -0.8% -0.3% 0.03 0.03 +0.0% gg -0.6% +40.4% 0.01 0.02 +50.0% grep -1.8% +2.3% 0.00 0.00 +0.0% hidden -0.7% +3.5% +4.1% +7.6% +0.0% hpg -1.3% -1.3% 0.05 0.10 +0.0% ida -0.7% -1.0% 0.07 0.08 +11.1% infer -0.9% +0.5% 0.05 0.05 +30.0% integer -0.8% +1.1% +1.1% +2.3% +0.0% integrate -0.9% +56.2% 0.20 0.23 +1.0% kahan -0.9% +144.9% +77.6% +78.4% +0.0% knights -0.1% -0.4% 0.01 0.01 +0.0% lcss -0.7% +0.7% -24.3% -18.4% +1.9% life -0.2% +0.0% 0.16 0.16 +0.0% lift -0.0% +0.1% 0.00 0.00 +0.0% listcompr -0.1% -0.0% 0.06 0.06 +0.0% listcopy -0.1% -0.0% 0.06 0.06 +0.0% maillist +0.0% +1.9% 0.02 0.04 +16.5% mandel -0.8% +0.0% 0.05 0.05 +0.0% mandel2 -0.1% -4.0% 0.00 0.01 +0.0% minimax -0.2% -0.0% 0.00 0.00 +0.0% mkhprog -0.1% +1.1% 0.00 0.00 +0.0% multiplier -1.2% +0.0% 0.07 0.08 +0.0% nucleic2 -3.3% +19.5% 0.05 0.05 +0.0% para -0.0% +25.0% 0.22 0.23 +0.0% paraffins -0.8% +0.0% 0.06 0.08 +7.5% parser -1.3% +22.2% 0.03 0.03 +0.0% parstof -0.5% +4.6% 0.01 0.00 +0.0% pic +0.5% +0.0% 0.00 0.00 +0.0% power -1.0% +0.0% -0.5% +1.0% +0.0% pretty -0.2% +0.0% 0.00 0.00 +0.0% primes -0.8% -0.0% 0.04 0.05 +0.0% primetest -0.7% +0.0% 0.07 0.07 +0.0% prolog -0.2% +16.0% 0.00 0.00 +0.0% puzzle -0.1% -2.1% 0.09 0.10 +0.0% queens -0.8% +0.0% 0.02 0.02 +0.0% reptile -0.8% +0.6% 0.01 0.02 +0.0% rewrite -0.8% +0.7% 0.02 0.02 +0.0% rfib -1.0% +0.4% 0.02 0.02 +0.0% rsa -0.7% +2.5% 0.02 0.02 +0.0% scc -0.1% +0.0% 0.00 0.00 +0.0% sched -0.8% +0.0% 0.01 0.02 +0.0% scs -1.9% +0.8% -5.3% -2.7% +0.0% simple -0.3% -0.0% 0.15 0.16 +6.9% solid -0.7% +0.0% 0.09 0.09 +0.0% sorting +0.0% +55.9% 0.00 0.00 +0.0% sphere -0.9% -1.8% 0.04 0.04 +0.0% symalg -0.8% +0.3% 0.01 0.01 +0.0% tak -0.8% +0.9% 0.01 0.01 +0.0% transform -0.8% +0.0% -3.3% -5.7% +0.0% treejoin +0.1% +109.3% 0.15 0.17 -7.4% typecheck -0.8% +0.0% 0.14 0.15 +0.0% veritas -0.8% +0.0% 0.00 0.00 +0.0% wang -0.9% +0.0% 0.07 0.08 +0.0% wave4main -0.8% +1.8% 0.18 0.19 -7.1% wheel-sieve1 -0.7% +0.0% +0.0% +1.5% -12.5% wheel-sieve2 -0.7% +0.0% 0.11 0.12 +2.1% x2n1 +7.4% +43.3% 0.01 0.01 +200.0% -------------------------------------------------------------------------------- Min -3.3% -4.0% -24.3% -18.4% -12.5% Max +7.4% +144.9% +77.6% +78.4% +200.0% Geometric Mean -0.5% +5.5% +1.8% +4.3% +3.2% I haven't had time to look through the regressions yet, so if someone has time, please grab a benchmark that looks bad and have a look at the Core to see what's going on. I suggest starting with "kahan", which is a relatively simple benchmark. -- Johan

4 14

Re: Patch to time
by José Pedro Magalhães 12 Feb '13

12 Feb '13

Hi Ashley, Just to remind you of the patch to time I've previously sent you. Whenever you can apply it, we can remove the "temporary fix" patch on the GHC copy of the repo. Thanks, Pedro On Wed, Nov 28, 2012 at 3:05 PM, José Pedro Magalhães <jpm(a)cs.uu.nl> wrote: > Hi Ashley, > > I'm attaching a patch to the time package to make it derive Typeable > instances instead of defining them manually. GHC HEAD will soon ignore > handwritten Typeable instances, so this replacement is necessary. > > > Thanks, > Pedro > >

1 0