RE: Deleting sync-all

Hi Thomas, Sure I can take care of that part. I'll make a separate issue for it. I also think we should do the first part as well eventually (using mingw-w for for both x64 and x86_64) as that solves #10435 . Regards, Tamar -- From: Thomas Miedema Sent: ‎7/‎27/‎2015 1

warnings

Yurgh. I committed a patch but my validate had -Wwarn by mistake. So there are warnings in base (and binary actually). I will sort them out tomorrow. Could revert and re-apply but doesn't seem worth it. Sorry Simon ___ ghc-devs mailing list ghc-devs@

RE: TypeLits and type families wrt. equality

| When saying "Big Deal" did you mean |- highly desirable and somebody should go for it |- or a terrible amount of work, and who tackles it is probably a | fool on a hubris trip? I meant - a lot of work, including changes to the core System FC language - we lack enough compelling ca

Re: TypeLits and type families wrt. equality

It sounds like you want this, then: > gabor :: forall a b. > (KnownSymbol a, KnownSymbol b) > => Proxy a -> Proxy b > -> Either (Equal a b :~: 'False) (a :~: b) > gabor a b = case sameSymbol a b of > Just refl -> Right refl > Nothing -> Left (unsafeCoerce Refl) > It st

Re: Deleting sync-all

Hi Tamar, feel free to take over that patch , or extract the parts you like. It currently does (too) many things, which is part of the reason why it stalled. See my comments in #9218 . Do not wait to get rid of the

Re: TypeLits and type families wrt. equality

On 7/27/15, Richard Eisenberg wrote: > This works for me (with ScopedTypeVariables): > >> gabor :: forall a b lhs rhs. >> (KnownSymbol a, KnownSymbol b) >> => Proxy a -> Proxy b -> Proxy (lhs :~: rhs) >> -> Either (lhs :~: rhs) (a :~: b) >> gabor a b _ = case sameSymbol a b of

Re: TypeLits and type families wrt. equality

This works for me (with ScopedTypeVariables): > gabor :: forall a b lhs rhs. > (KnownSymbol a, KnownSymbol b) > => Proxy a -> Proxy b -> Proxy (lhs :~: rhs) > -> Either (lhs :~: rhs) (a :~: b) > gabor a b _ = case sameSymbol a b of > Just refl -> Right refl > Nothing ->

Re: TypeLits and type families wrt. equality

On 7/27/15, Richard Eisenberg wrote: > > On Jul 27, 2015, at 10:56 AM, Gabor Greif wrote: decideRefl :: Proxy (a :: Symbol) -> Proxy b -> Proxy (Equal a b :~: 'False) -> Either (Equal a b :~: 'False) (a :~: b) > > What's the point of the third Proxy a

Re: TypeLits and type families wrt. equality

On Jul 27, 2015, at 10:56 AM, Gabor Greif wrote: >>> >>> decideRefl :: Proxy (a :: Symbol) -> Proxy b >>> -> Proxy (Equal a b :~: 'False) >>> -> Either (Equal a b :~: 'False) (a :~: b) What's the point of the third Proxy argument? I don't think it adds anything. Perha

Re: TypeLits and type families wrt. equality

On 7/27/15, Richard Eisenberg wrote: > > On Jul 27, 2015, at 10:36 AM, Gabor Greif wrote: > >> When saying "Big Deal" did you mean >> - highly desirable and somebody should go for it >> - or a terrible amount of work, and who tackles it is probably a >> fool on a hubris trip? >> >> (I still hav

Re: TypeLits and type families wrt. equality

On Jul 27, 2015, at 10:36 AM, Gabor Greif wrote: > When saying "Big Deal" did you mean > - highly desirable and somebody should go for it > - or a terrible amount of work, and who tackles it is probably a > fool on a hubris trip? > > (I still have my problems deciphering British irony.) My u

Re: TypeLits and type families wrt. equality

On Jul 27, 2015, at 9:48 AM, Simon Peyton Jones wrote: > > Making type inference (and system FC) exploit negative info would be a Big > Deal, I think. Yes. Gabor points out a known infelicity with the interaction between closed type families and GADTs. But I agree with Simon that fixing it wo

Re: TypeLits and type families wrt. equality

Simon, yes, this is the the same problem. You probably meant: = type family Equal a b where Equal a a = 'True Equal a b = 'False foo :: Proxy 'False -> Bool foo x = False f :: forall a b. Maybe (a :~: b) -> Bool f x = case x of Just Refl -> True

RE: TypeLits and type families wrt. equality

Yes. Here's a simpler example: = type family Equal a b where Equal a a = 'True Equal a b = 'False foo :: Proxy 'True -> Bool foo x = True f :: forall a b. Maybe (a :~: b) -> Bool f x = case x of Just Refl -> True Nothing -> foo (undefined

RE: Deleting sync-all

Hi There is a sorta in limbo differential from gintas that would have solved this by doing it in the configure script. I liked that solution. As far as I know the patch was delayed because the reviewers suggested we get rid of the perl dependency first. Regards, Tamar ---

RE: RULES in binary

Correct. Or if you want the inlning, you can delay it by saying INLINE [n], or indeed NOINLINE [n], which will ensure that the inlining does not happen until phase n S From: Lennart Kolmodin [mailto:kolmo...@gmail.com] Sent: 27 July 2015 11:02 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Sub

Re: RULES in binary

2015-07-27 10:02 GMT+02:00 Simon Peyton Jones : > Terrific. > > > > If a RULE and an inlining “do the same thing”, the RULE is usually to be > preferred because it duplicates less code. > As I've understood it, I'll still need an (NO)INLINE pragma. GHC will warn that the RULE might not fire sinc

Re: RULES in binary

2015-07-26 23:06 GMT+02:00 Joachim Breitner : > Hi, > > Am Sonntag, den 26.07.2015, 22:50 +0200 schrieb Lennart Kolmodin: > > This trick relies so much on that the user's code has been inlined > > properly that it probably very rarely fires in a real application. It > > does wonders in the unreali

Re: Deleting sync-all

Hi Gábor, instead of changing `ghc.mk`, please change the builder script to also run `git clone git://git.haskell.org/ghc-tarballs.git`. (Edit: while typing this, I saw you just did so) The benefits are: * the windows specific part of creating a source distribution also gets tested * the release

RE: Handling overflow and division by zero

| Do I need to create a ticket, too? Yes, it's always a good idea to create a ticket to say what you are doing track progress give an opportunity for others to comment Simon | -Original Message- | From: Nikita Karetnikov [mailto:nik...@karetnikov.org] | Sent: 25 July 2015 18:47

RE: RULES in binary

Terrific. If a RULE and an inlining “do the same thing”, the RULE is usually to be preferred because it duplicates less code. Simon From: Lennart Kolmodin [mailto:kolmo...@gmail.com] Sent: 26 July 2015 21:50 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: RULES in binary Yes, this