RE: Explanation of a core-lint warning (Bad getNth)

upenn.edu>; ghc-devs@haskell.org Subject: Re: Explanation of a core-lint warning (Bad getNth) I have condensed a self-contained plugin and an example application that reproduces the error. You can find it here: https://github.com/jbracker/polymonad-plugin/tree/master/examples/core-error Y

Re: Explanation of a core-lint warning (Bad getNth)

. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Richard > Eisenberg > *Sent:* 18 November 2015 17:14 > *To:* Jan Bracker > *Cc:* ghc-devs@haskell.org > *Subject:* Re: Explanation of a core-lint warning (Bad getNth) &g

Re: Explanation of a core-lint warning (Bad getNth)

*Sent:* 15 January 2016 14:03 > *To:* Simon Peyton Jones <simo...@microsoft.com> > *Cc:* Richard Eisenberg <e...@cis.upenn.edu>; ghc-devs@haskell.org > > *Subject:* Re: Explanation of a core-lint warning (Bad getNth) > > > > I have condensed a self-contai

Re: Explanation of a core-lint warning (Bad getNth)

On Fri, Jan 15, 2016 at 3:03 PM, Jan Bracker wrote: > You just have to download the three files and run "cabal install" to > reproduce the error. > It's never that easy, is it? Can you try in a cabal sandbox, with ghc-7.10.3. I'm getting: cabal: Could not resolve

Re: Explanation of a core-lint warning (Bad getNth)

Hard-coding the exact base version was a stupid mistake, sorry. I relaxed that and reattached a new version of the files to the ticket. It seems that 'effect-monad's dependency on 'type-level-sets' is a bit to liberal, because the module structure and exports of that package changed between

Re: Explanation of a core-lint warning (Bad getNth)

I can reproduce the problem with 7.10.3. Since the compiler got completely rewritten, the plugin for sure doesn't work with 8.0. In case anyone else wants to take look at this bug, I can say the plugin contains a lot of hopefully helpful comments. On Sat, Jan 16, 2016 at 12:49 AM, Jan Bracker

RE: Explanation of a core-lint warning (Bad getNth)

to help. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard Eisenberg Sent: 18 November 2015 17:14 To: Jan Bracker Cc: ghc-devs@haskell.org Subject: Re: Explanation of a core-lint warning (Bad getNth) Ah yes. I looked too quickly. Note that there are two NthCo's listed

Re: Explanation of a core-lint warning (Bad getNth)

As far as I understand your explanation this should not lead to an error, although it is not the most obvious coercion. Is that right? Do you or anybody else have a suggestion on how to resolve this issue? 2015-11-18 17:13 GMT+00:00 Richard Eisenberg : > Ah yes. I looked too

Re: Explanation of a core-lint warning (Bad getNth)

On Nov 18, 2015, at 12:19 PM, Jan Bracker wrote: > As far as I understand your explanation this should not lead to an error, > although it is not the most obvious coercion. Is that right? That's what it seems to be, in this particular case. But I'd be nervous with

Re: Explanation of a core-lint warning (Bad getNth)

Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its the outermost that's the problem, which is deconstructing the Union. But it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which is rather easy to prove without NthCo. I'm not sure why GHC is doing this.

Re: Explanation of a core-lint warning (Bad getNth)

I took just a quick look at this. Is Split a type family? The NthCo coercion form takes apart a composite equality into its pieces. For example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres" :-> Int]

Re: Explanation of a core-lint warning (Bad getNth)

Hi Richard, No "Split" is a class and is defined here: http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split "Union" is a type function (synonym that refers to a type function call):