Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#1382 closed bug (fixed)

Monad GHC.Prim.Any1 gets derived in a context

Reported by: iampure@… Owned by: simonpj
Priority: high Milestone:
Component: Compiler (Type checker) Version: 6.7
Keywords: Any1 context type-inference Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Difficulty: Unknown
Test Case: tcfail181 Blocked By:
Blocking: Related Tickets:

Description

Because Monad GHC.Prim.Any1 gets derived in the type of the function test in the attached file, I cannot write an instance for it (obviously) and I cannot continue writing the code where I use the test function. I.e. I have this problem in a real project and it's blocking progress, until I find a work-around (which I didn't find after about an hour). I hope this gets fixed soon.

Attachments (1)

Bugs.hs (1.4 KB) - added by iampure@… 7 years ago.
File containing the function test, which ghci claims to have Monad (GHC.Prim.Any1) in the context of a type.

Download all attachments as: .zip

Change History (9)

Changed 7 years ago by iampure@…

File containing the function test, which ghci claims to have Monad (GHC.Prim.Any1) in the context of a type.

comment:1 Changed 7 years ago by iampure@…

I experimented somewhat more with my original code and it appears that

using e.g.

(Something{bar = (\edge -> returnG (1 > 0)),

initializer = returnG ()
}

)

on the location of default_visitor{bar = \_ -> return True} in the function test doesn't have this weird Any1 type mentioned anywhere. So, merely using a record update creates this problem.

The idea of using default_visitor is of course that some have "default values", s.t. users don't need to mention all the fields. This property is now broken.

comment:2 Changed 7 years ago by iampure@…

  • severity changed from blocker to critical

Even some more information: it appears that using
abc = do

(ans, _) <- run_mymonad (algorithmT undefined)
return ans

also generates an Any constraint

When using abc bar = do

(ans, _) <- run_mymonad (algorithmT bar)
return ans

this constraint disappears.

comment:3 Changed 7 years ago by simonpj

  • Owner set to simonpj
  • Version changed from 6.6.1 to 6.7

Just to clarify, you don't mean GHC 6.6.1, do you? For that I get

BugBug.hs:66:24:
    Ambiguous type variable `m' in the constraint:
      `Monad m'
	arising from use of `default_visitor' at BugBug.hs:66:24-38
    Probable fix: add a type signature that fixes these type variable(s)

In the HEAD, I agree something odd happens:

bash-3.1$ $gpj -c BugBug.hs -ddump-types
TYPE SIGNATURES
    ...    
  test :: forall (m :: * -> *) state (g :: * -> * -> *) a b state1.
	    (Gr g, Show b, Show a, Monad GHC.Prim.Any1, Monad m) =>
	    Foo m (g a b) state (Maybe [A])

I'll look into it. Meanwhile, use GHC 6.6.1!

Simon

comment:4 Changed 7 years ago by simonpj

You program really is ambiguous (see message above). Nevertheless, it's definitely a bug that GHC HEAD infers a type with a stupid Any in the context. I've boiled it down a lot more:

data Something d e = Something{ bar::  d, initializer::e   }

foo :: (Monad m) => Something (m Bool) n
foo = undefined

wog x = foo{bar = return True}

Look at wog's type. No time to fix today, but this is at least a nice small case.

Simon

comment:5 Changed 7 years ago by iampure@…

Just to clarify, you don't mean GHC 6.6.1, do you?

I meant 6.7, indeed. Sorry for misinformation. I am, however, fairly sure I have seen Any types being derived with 6.6.1. I will open another bug when I find such code again.

comment:6 Changed 7 years ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed
  • Test Case set to tcfail181

OK, fixed. Thanks for the report.

Simon

comment:7 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:8 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple
Note: See TracTickets for help on using tickets.