I'll *try* :)

I assume  ghc rc, plus having cabal installed

1) cabal unpack the most recent haskeline, and fix it so it can build, 
this is updating the Setup.hs file for haskeline, as
theres no longer a Control.Exception.Extensible  (instead its just Control.Exception.Base ), so that just needs to be swapped
cabal install that.  

2) git clone https://github.com/cartazio/EpiVM, 
3) cd EpiVM ; git checkout patch-1 ; cabal build ; cabal configure ; cabal build ; cabal install 
4)  now you can try doing "cabal install idris" and you should get the following type error message  

https://gist.github.com/3405712

which is exactly an example of this sort of phenomena.

i can try to spend some more time on concocting a smaller case, but I'd rather not... i need to focus on building my haskell backed numerical computation tools I've got some enterprise customers waiting for this fall! 

please let me know either way if that helps!
cheers
-Carter

On Mon, Aug 20, 2012 at 4:44 AM, Simon Peyton-Jones <simonpj@microsoft.com> wrote:

That does seem odd.  Can you give instructions for how to reproduce this?  The fewer dependencies the better :-)

 

Simon

 

From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Carter Schonwald
Sent: 17 August 2012 19:01
To: GHC Users List
Subject: funny type inference error with ghc7.6rc1

 

Hey All,

 

When playing with the current hackage versions of Epic and Idris to make them play nice with ghc7.6rc1

 

and 

http://hackage.haskell.org/package/epic-0.9.3    (current version on github now builds on ghc 7.6, https://github.com/edwinb/EpiVM)

 

I ran into some funny type inference problems. Namely, using the idris-0.9.2.1  source and iteratively seeing how ghc complains, 

I repeated found that ghc would infer extraneous class constraints with variables that don't appear in the function type!

 

eg (Num a, Ord a) => PArg -> Doc, when the correct type to infer would  be PArg -> Doc.

heres some gists with links to more info

 

Anyways, I'm not sure what to make of this, is this a reasonable artifact of  type inference getting confused on functions with a large number of case analyses when various typeclass extensions are enabled? Or  Is this a bug in terms of what inference should be able to handle?

 

Just to be clear, when I add the infererred type ascriptions without the type class constraint, everything type checks in those modules. So my confusion is why the inference adding those unused class constraint variables! 

 

thanks all,

-Carter