- ghc-devs - Haskell.org

10 Sep '13

1 0

Re: [GHC] #8256: adding locality levels to prefetch# and friends
by Carter Schonwald 10 Sep '13

10 Sep '13

Hey all, I'd really love some preliminary feedback on this augmented prefetch patch, 1) so i can have any issues addressed before the merge window closes 2) If the basic patch looks good to folks (subject to some cleanup), I'd like to also see about adding prefetch support on x86 native backend, and fallback NOOP on other architectures. (because its something which shouldn't be llvm only) thanks! -Carter On Tue, Sep 10, 2013 at 1:21 PM, GHC <ghc-devs(a)haskell.org> wrote: > #8256: adding locality levels to prefetch# and friends > -------------------------------------+------------------------------------ > Reporter: carter | Owner: carter > Type: task | Status: new > Priority: normal | Milestone: 7.8.1 > Component: Compiler | Version: 7.7 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: Unknown/Multiple > Type of failure: None/Unknown | Difficulty: Unknown > Test Case: | Blocked By: > Blocking: | Related Tickets: #8252 ,#8107 > -------------------------------------+------------------------------------ > > Comment (by carter): > > one thing i'm worried i'm overlooking, is how do I make sure cmm-lint > knows about prefetch op types? > > (or is that a none issue) > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8256#comment:8> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

来自重庆华润励致集团的信函
by 薛纬填 10 Sep '13

10 Sep '13

1 0

Problems with validating template-haskell
by Jan Stolarek 10 Sep '13

10 Sep '13

I have problems with validating my changes in template-haskell, file Language/Haskell/Th/Syntax.hs. I added isTrue# function in the import: import GHC.Base ( Int(..), Int#, (<#), (==#), isTrue# ) And later on I'm using isTrue#. However, when stage1 compiler tries to compile Syntax.hs, validation fails (due to -Werror): libraries/template-haskell/Language/Haskell/TH/Syntax.hs:19:1: Warning: The import of ‛Int#, Int, ==#, <#’ from module ‛GHC.Base’ is redundant The module obviously uses mentioned operators and data types. I wonder what did I miss. Ideas anyone? Janek

1 0

newtype coercion wrapping status
by Joachim Breitner 10 Sep '13

10 Sep '13

Hi, after following SPJ’s latest advise and implementing the newtype coercion classes directly and ad-hoc in the type checker (in TcInteract, similarly to the SingI), this rewrite of the code is now working (for some value of working): What works now ============== The setup: Prelude> :info GHC.NT.castNT castNT :: NT a b => a -> b -- Defined in ‛GHC.NT’ Simple cases: Prelude> newtype Age = Age Int deriving Show Prelude> GHC.NT.castNT (Age 1) :: Int 1 Prelude> GHC.NT.castNT (1::Int) :: Age Age 1 Unrolling several newtypes at the same time: Prelude> newtype Bar = Bar Age deriving Show Prelude> newtype Baz = Baz Int deriving Show Prelude> GHC.NT.castNT (Baz 1) :: Bar Bar (Age 1) Unrolling newtypes with type arguments, even polymorphically: Prelude> newtype MyMB a = MyMB (Maybe a) deriving Show Prelude> GHC.NT.castNT (Just ()) :: MyMB () MyMB (Just ()) Prelude> let f1 = (\x -> GHC.NT.castNT (Just x)) :: a -> MyMB a Prelude> f1 True MyMB (Just True) Prelude> let f2 = (\x -> GHC.NT.castNT (Just x)) :: GHC.NT.NT a b => a -> MyMB b Prelude> f2 (Baz 1) :: MyMB Bar MyMB (Just (Bar (Age 1))) Unrolling inside type constructor arguments, including functions and tuples: Prelude> GHC.NT.castNT (Just (Age 1)) :: Maybe Int Just 1 Prelude> (GHC.NT.castNT Age :: (Baz -> Bar)) (Baz 1) Bar (Age 1) Prelude> GHC.NT.castNT (Age 1, Baz 1) :: (Bar, Int) (Bar (Age 1),1) Arbitrary changing of Phantom types: Prelude> data Proxy a = Proxy deriving Show Prelude> GHC.NT.castNT (Proxy :: Proxy Int) :: Proxy Bool Proxy Unwanted casting can be prevented by role annotations: Prelude> :set -XRoleAnnotations Prelude> data Map a@N b = Map a b deriving Show Prelude> GHC.NT.castNT (Map () (1::Int)) :: Map () Bar Map () (Bar (Age 1)) Prelude> GHC.NT.castNT (Map (1::Int) ()) :: Map Bar () <interactive>:24:1: No instance for (GHC.NT.NT (Map Int ()) (Map Bar ())) arising from a use of ‛GHC.NT.castNT’ In the expression: GHC.NT.castNT (Map (1 :: Int) ()) :: Map Bar () In an equation for ‛it’: it = GHC.NT.castNT (Map (1 :: Int) ()) :: Map Bar () GADTs have the roles set automatically, so this does not work either, as expected: Prelude> :set -XGADTs -XStandaloneDeriving Prelude> data GADT a where GADT :: GADT Int Prelude> deriving instance Show (GADT a) Prelude> GHC.NT.castNT GADT :: GADT Age <interactive>:37:1: No instance for (GHC.NT.NT (GADT Int) (GADT Age)) arising from a use of ‛GHC.NT.castNT’ In the expression: GHC.NT.castNT GADT :: GADT Age In an equation for ‛it’: it = GHC.NT.castNT GADT :: GADT Age What is still missing ===================== * Good error messages (see above) * Checking if all involved data constructors are in scope * Marking these data constructors as used (to avoid unused import warnings) * Prevent the user from writing NT instances himself. * Code documentation * User documentation * Tests. * More testing, especially with weird types and advanced type system features, e.g. type families. What needs more thought ======================= * How to handle recursive newtypes, such as newtype Void = Void Void or worse newtype Foo a = Foo (Foo (a,a))? With the current setup, which is equivalent to an instance instance NT (Foo (a,a)) b => NT (Foo a) b it will cause constraint checking to loop. I’m inclined to simply not create instances for recursive newtypes, or alternatively only in modules with UndecidableInstances turned on. The code ======== The code can be reviewed at https://github.com/nomeata/ghc/compare/ntclass-clean with the corresponding ghc-prim changes at https://github.com/nomeata/packages-ghc-prim/compare/ntclass-clean I followed the example of SingI and created a new constructor in data EvTerm for NT evidences. There are three kinds of evidence for NT t1 t2: One for t1 == t2, one for unfolding a newtype (at t1 or t2), and one if t1 and t2 have the same type constructor at the head. This corresponds to the the shapes of NT instances one would write by hand. The evidence is created in TcInteract, in a function called by matchClassInst, and turned into Core by dsEvTerm in DsBinds. Currently there is both a type constructor GHC.Types.EqR that boxes EqR# and is built-in, and a type class GHC.NT.NT, which has just one method of type EqR. This is because it seems to be quite tricky to create a built-in class in GHC.Prim, but also causes a bit of extra bookkeeping. I guess the final patch will somehow avoid this indirection. Richard, can you have a look at my changes to compiler/types/Coercion.lhs, if they are sound? I found that there was a hardcoded role of Nominal where, with my code, also Representational could occur. Is this going in the right direction, both design and implementation-wise? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

4 18

Pattern synonyms: help needed: capturing EvBinds in tcPat
by Dr. ERDI Gergo 10 Sep '13

10 Sep '13

Hi, Based on feedback from Simon PJ a couple weeks ago, I started a substantial rewrite of the typecheker of pattern synonyms, to support existential types. My latest code (full of 'stash' commits and a huge amount of 'traceTc' calls) is available in the pattern-synonyms-wip branch of http://github.com/gergoerdi/ghc.git. What I'm struggling with, is capturing the evidence bindings during the typechecking of a pattern which is a pattern synonym occurance. For example, suppose I have the following module: {-# LANGUAGE GADTs, PatternSynonyms #-} module ConstrEx where data T where MkT :: (Eq b) => b -> b -> T pattern P b b' = (MkT b b', ()) f (P x y) = [x] == [y] The names in the following will refer to the output of pattern-synonyms-wip with --ddump-tc-trace. The right-hand side of 'f' requires an instance Eq [b], and is given an instance $dEq_an5 :: Eq b, so it binds a dictionary '$dEq_an7 = GHC.Classes.$fEq[] @[b] [$dEq_an5]'. This makes sense. However, inside 'tcPatSynPat', which is the version of 'tcPat' for pattern synonym occurances, the 'checkConstraints'-wrapped call to (eventually) 'thing_inside' doesn't capture this binding (I get back an empty 'TcEvBinds'). This causes problems further on because even though $dEq_an5 is going to be in scope while generating code for the right-hand side (since 'tcInstPatSyn', the function that instantiates 'P x y' into '(MkT x y, ())', substitutes the name of the dictionary bound by MkT, $dEq_amS, to $dEq_an5), but $dEq_an7 is not, since its binding is not emitted by 'tcPatSynPat' (since it doesn't get it from 'checkConstraints'). Looking at the tc-trace log, I see '$dEq_an7 = GHC.Classes.$fEq[] @[b] [$dEq_an5]' on line 2070, way after the call to 'checkConstraints' returns on line 1811. I realize the above description is basically incomprehensible unless you go through the trouble of reading through 'tcPatSynDecl', 'tcPatSynPat' and 'tcInstPatSyn', but I don't yet know how to even formulate my question more succinctly. Any help is appreciated. Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' GDK is the GNU Not Unix Image Manipulation Program Tool Kit Drawing Kit

2 2

RE: Proposal: Improving the IsString String instance
by Simon Peyton-Jones 10 Sep '13

10 Sep '13

(redirecting to ghc-devs) Thomas Let's be clear what is happening here. After all the dust has settled we call TcSimplify.applyDefaultingRules to look at a bunch of unsolved constraints and generate new, extra constraints that might help solve them. Thus if we see (Eq a, Num a) we might generate the extra constraint (a ~ Integer) to try to help solve them. Now, what you want to do is to spot a constraint like (IsString [a]), and generate (a ~ Char). Now it's true that the current machinery in findDefaultableGroups is set up to look for constraints of form (C a), because that's what the rules say. If you change the rules you'll need to change the code. But I'm not even sure what the new rule *are*. The current GHCi defaulting rules are documented here: http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluat… The first thing to do is to write down the exact new rules that you are trying to implement. Simon | -----Original Message----- | From: Thomas Schilling [mailto:nominolo@googlemail.com] | Sent: 09 September 2013 23:24 | To: Ganesh Sittampalam | Cc: Simon Peyton-Jones; Edward Kmett; Haskell Libraries | Subject: Re: Proposal: Improving the IsString String instance | | I took a stab at implementing this. Having a superclass would probably | make the implementation simpler. | | I can't figure out the proper way to add a "C [a] = <ty>" constraint to | the simplifier. The defaulting mechanism currently just looks tries | combinations of "a := <ty>" for all the candidate types. If "a" is not | just a type variable this needs to be add another wanted constraint, but | I couldn't find a function that satisfies that purpose. (Even though I | read the OutsideIn(X) journal paper a while ago, the type checker code | does indeed seem nearly impenetrable -- there's still some boxy | unification code in TcUnify, and it's not clear how that interacts with | the new solver.) | | Anyway, if someone can point out how I to turn "setWantedTyBind tv ty" | into something like "setWantedEquality ty1 ty2" I can implement it. | Otherwise, I'd have to use use some rather gnarly hack that special- | cases "C [a] = <ty>" to "a := Char" iff "<ty> == String" | | / Thomas | | On 29 Aug 2013, at 08:03, Ganesh Sittampalam <ganesh(a)earth.li> wrote: | | > I'd be marginally in favour of the new class + simpler defaulting | rule. | > | > This is mostly on the philosophical ground that it's better to compose | > existing features than to introduce new ones. | > | > It also feels like it might be more future-proof/flexible, though I | > can't think of a compelling example. A weak one is that someone might | > want to work with Array Char or similar. | > | > On 27/08/2013 08:29, Simon Peyton-Jones wrote: | >> PS: I'm not convinced that it's worth the overhead of adding a new | class. Modifying the defaulting rules would probably be enough, although | it does involve one new feature, namely that it must default IsString | [beta] as well as IsString alpha. | >> | >> Simon | >> | >> | -----Original Message----- | >> | From: Simon Peyton-Jones | >> | Sent: 27 August 2013 08:27 | >> | To: 'Ganesh Sittampalam'; Edward Kmett | >> | Cc: Haskell Libraries | >> | Subject: RE: Proposal: Improving the IsString String instance | >> | | >> | If I understand aright, the problem is that we end up with | constraints | >> | like | >> | IsString alpha | >> | or | >> | IsString [beta] | >> | where alpha or beta are otherwise-unconstrained unification | variables. | >> | Under those circumstances we'd like to default to IsString String. | >> | | >> | This is *exactly* what the current type-class-defaulting mechanism | does. | >> | Eg with (show 3) you get (Show alpha, Num alpha) and want to choose | >> | alpha to be something sensible. | >> | | >> | We've already extended it for GHCi | >> | | http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive- | >> | evaluation.html#extended-default-rules | >> | | >> | I don't think this would be controversial. The path seems to be: | >> | propose a concrete extension to the rules, | >> | specify when it's enabled | >> | get everyone to agree | >> | provide a patch (relevant code is in | >> | TcSimplify.applyDefaultingRules) | >> | | >> | Simon | >> | | >> | | -----Original Message----- | >> | | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf | Of | >> | | Ganesh Sittampalam | >> | | Sent: 26 August 2013 21:55 | >> | | To: Edward Kmett | >> | | Cc: Haskell Libraries | >> | | Subject: Re: Proposal: Improving the IsString String instance | >> | | | >> | | Couldn't it work (with suitable extensions to the list of blessed | >> | | classes) with Henning's IsCharList suggestion? The unresolved | >> | constraint | >> | | would be IsCharList a. | >> | | | >> | | On 26/08/2013 21:47, Edward Kmett wrote: | >> | | > The problem is ExtendedDefaultRules only works when the whole | type | >> | is | >> | | > unknown. If we know part of the type e.g. that it is [a] for | some a | >> | as | >> | | > we figure out from length, or that it is (f a), then it doesn't | kick | >> | | in. | >> | | > | >> | | > print works because "hello" :: (IsString a, Show a) => a | >> | | > | >> | | > knows nothing about the argument a | >> | | > | >> | | > and Show is included in the EDR list of blessed classes. | >> | | > | >> | | > If at the repl you turn on OverloadedStrings and EDR | >> | | > | >> | | > showList "hello" "" | >> | | > | >> | | > will still blow up, because it can know you have an argument | [a] | >> | with | >> | | a | >> | | > Show a constraint on it, and IsString [a], so it fails to meet | the | >> | | > fairly simplistic conditions required by EDR. | >> | | > | >> | | > -Edward | >> | | > | >> | | > | >> | | > On Mon, Aug 26, 2013 at 4:34 PM, Dag Odenhall | >> | <dag.odenhall(a)gmail.com | >> | | > <mailto:dag.odenhall@gmail.com>> wrote: | >> | | > | >> | | > |ExtendedDefaultRules| already provides this to some | extent, for | >> | | > example it makes |print "hello"| work without type | information. | >> | | > | >> | | > | >> | | > | >> | | > On Mon, Aug 26, 2013 at 10:09 PM, Dan Burton | >> | | > <danburton.email(a)gmail.com | <mailto:danburton.email@gmail.com>> | >> | | wrote: | >> | | > | >> | | > Just to throw another curveball at this conversation, | what | >> | | about | >> | | > a general, ad-hoc solution for 'typeclass defaults'? | The | >> | logic | >> | | > goes like this: Is there an "ambiguous type variable" | error | >> | | due | >> | | > to the use of the IsString typeclass? Try defaulting to | the | >> | | > String instance. If that doesn't work, try defaulting | to | >> | Text. | >> | | > Repeat for a finite, explicit list of instances. If | none of | >> | | > these defaults are successful, type error. | >> | | > | >> | | > We have hard-coded this sort of behavior into the Num | class. | >> | | Why | >> | | > not just provide this general capability for arbitrary | >> | | classes? | >> | | > Or at least hard-code it into IsString as well. | >> | | > | >> | | > In the absence of this sort of solution, +1 to Edward's | >> | | original | >> | | > proposal. | >> | | > | >> | | > The "o" proposal is not viable because the oft-needed | parens | >> | | > make it confusing and irritating to the new Haskeller. | >> | | > | >> | | > -- Dan Burton | >> | | > | >> | | > | >> | | > On Mon, Aug 26, 2013 at 12:41 PM, Henning Thielemann | >> | | > <lemming(a)henning-thielemann.de | >> | | > <mailto:lemming@henning-thielemann.de>> wrote: | >> | | > | >> | | > | >> | | > On Mon, 26 Aug 2013, Gabriel Gonzalez wrote: | >> | | > | >> | | > I'm guessing this is sarcastic, but I just want | to | >> | | > clarify what I understood Henning's proposal to | be. | >> | | > He's not saying we should provide an `o` | function | >> | in | >> | | > the standard library, but rather encourage | users to | >> | | > define their own. | >> | | > | >> | | > | >> | | > Yes. I would be ok if packages provide this | function, | >> | but | >> | | I | >> | | > would urge programmers to import that explicitly. | >> | | > | >> | | > | >> | | > This one liner would take the place of the | current | >> | | line | >> | | > that they devote right now to | `OverloadedStrings` . | >> | | > | >> | | > | >> | | > right | >> | | > | >> | | > | >> | | > However, the analogy is still apt since the | exact | >> | same | >> | | > line of reasoning applies to overloaded numeric | >> | | > literals where we currently rely on defaulting | to | >> | | solve | >> | | > this problem. | >> | | > | >> | | > | >> | | > I always use -Wall and thus I am warned about when | >> | | > defaulting takes place. Thus I am confident that I | do | >> | not | >> | | > rely on defaulting in my code. | >> | | > | >> | | > _______________________________________________ | >> | | > Libraries mailing list | >> | | > Libraries(a)haskell.org | <mailto:Libraries@haskell.org> | >> | | > http://www.haskell.org/mailman/listinfo/libraries | >> | | > | >> | | > | >> | | > | >> | | > _______________________________________________ | >> | | > Libraries mailing list | >> | | > Libraries(a)haskell.org <mailto:Libraries@haskell.org> | >> | | > http://www.haskell.org/mailman/listinfo/libraries | >> | | > | >> | | > | >> | | > | >> | | > _______________________________________________ | >> | | > Libraries mailing list | >> | | > Libraries(a)haskell.org <mailto:Libraries@haskell.org> | >> | | > http://www.haskell.org/mailman/listinfo/libraries | >> | | > | >> | | > | >> | | > | >> | | > | >> | | > _______________________________________________ | >> | | > Libraries mailing list | >> | | > Libraries(a)haskell.org | >> | | > http://www.haskell.org/mailman/listinfo/libraries | >> | | > | >> | | | >> | | | >> | | _______________________________________________ | >> | | Libraries mailing list | >> | | Libraries(a)haskell.org | >> | | http://www.haskell.org/mailman/listinfo/libraries | >> | >> _______________________________________________ | >> Libraries mailing list | >> Libraries(a)haskell.org | >> http://www.haskell.org/mailman/listinfo/libraries | >> | > | > | > _______________________________________________ | > Libraries mailing list | > Libraries(a)haskell.org | > http://www.haskell.org/mailman/listinfo/libraries

1 0

习李执政/经济走势与经营对策
by 庾轲葳 10 Sep '13

10 Sep '13

1 0

如何激励下属创造最佳业绩
by 怀荷觅 10 Sep '13

10 Sep '13

1 0

Control Your Appetite! No More Calorie Counting!
by Pure Garcinia Cambogia 10 Sep '13

10 Sep '13

100% Organic Weight Loss! http://www.fbadacieiodous.biz/2190/29/71/156/432.12tt64201835AAF17.php To Unsub - http://www.fbadacieiodous.biz/2190/29/71/156/432.12tt64201835AAF10.html PO Box 26452 Minneapolis, MN 55426 UNITED NATIONS Secretary-General Ban Ki-moon is recommending a 15 percent reduction in the number of U.N. troops in Haiti and an examination of whether a peacekeeping operation is still the best way to support the impoverished Caribbean nation.In a report to the U.N. Security Council circulated Tuesday, Ban said he intends to discuss with Haiti's government and member states the best way for the U.N. to continue contributing to "greater stability and development in the country."Ban said he will explore the option of replacing the peacekeeping mission, known as MINUSTAH, "with a smaller, more focused assistance mission by 2016" and include proposals on the way forward in his next report in March 2014.In the meantime, he recommended reducing MINUSTAH's military strength from 6,270 to 5,021 by June 2014. ve Boone and other past mascots a retirement ceremony in the upcoming academic year.The image of Denver Boone was originally designed by a Walt Disney artist and named by a UD student back in 1968 .The cartoony figure, which sports a scruffy beard and a raccoon skin cap, is reminiscent of the Daniel Boone character from the 1950s TV show based on the real-life pioneer.Boone was a legend of early American history and the archetypal hero of the American Western Frontier.Later, his image and legend fell victim to revisionist history as he became associated with the forceful displacement of Native Americans from their land.So how closely linked are Denver Boone and Daniel Boone?Any association of the Denver Boone caricature with America's pioneer hero, Daniel Boone, is misguided, said Randell Jones, historian and author of the book In the Footsteps of Daniel Boone.Mythology and Fess Parker aside, it is well documented that Daniel Boone never wore a coonskin cap. Neither did he wear a beard. Moreover, any exploits by him west of Missouri are speculative at best.

1 0