The type 'NS.Type1' is not compatible with the type 'NS.Type1' in f#

Go To StackoverFlow.com

0

I just splited a project in a few libraries. And I have the strange error in the title.

I can't explain myself why it is the case. Also, this error used to show up only in FSI.exe

I thought it was because of pb with loading dll in fsi but there is more to this.

It might be a stupid error (probably is..) but if anyone encoutered this sybillin error message before and knows what happens, I'd be glad to hear it.

UPDATE

I thought it was namespace issues, but it is not. This issue is very odd. Please ignore it if you did not experienced it. I am still trying to pinpoint the exact origin.

2012-04-04 17:40
by nicolas
How about some code to reproduce what you're seeing - GregC 2012-04-04 17:42
@GregC I would hope that if it was easy to reproduce, it would not have gone unnoticed by the testers at MSF - nicolas 2012-04-04 18:04
may be this question is not fit for here. i can delete it - nicolas 2012-04-04 18:09
The question is fine here. If you reset the session before sending code to fsi, there is not much different between using fsi and compiling\executing F# programs - pad 2012-04-04 18:30
Nicolas--F# does type inference. This could very much affect the behavior of your code so asking us to guess about the problem with no code is effectively useless. We can't see how you've defined your code so there's no way we can guess what may be going on with the type inference. This is especially true in the FSI. If you start a fresh FSI instance and try your steps again, does the problem still occur - Onorio Catenacci 2012-04-04 20:46
@OnorioCatenacci I understand, however it is difficult to repoduce.I tried to slim it down, but then the problem disappear - nicolas 2012-04-04 20:55


3

Without more information it's hard to know for sure. One way this could happen is if you end up redefining a type in FSI without redefining some things that depend on it. Then those things expect the old version of the type, but you end up creating instances of the new version, which are not compatible. For instance, given this code:

type MyType<'a>() = class end
let myFun (_:MyType<int>) = 0

let result = myFun (MyType())

If I send the first two lines to FSI, then the first line again by itself, and then the third line, I get something similar to your error message. The solution is to re-evaluate all dependent definitions.

2012-04-04 18:12
by kvb
I am being stupid, this is the solution. time to sleep - nicolas 2012-04-04 21:01
if that is indeed the case, which I still try to confirm, I guess some visual indication is necessary in the devenv. in FSI we have a version number, so that make it easy to see. in VS, there is no difference at all. if I confirm, I will send a ticket to the VS guy - nicolas 2012-04-04 21:04
@Nicolas - I don't think I've ever seen this problem in VS, but perhaps it could appear as a transient error after making large changes without the compiler catching up. If that's the case, I wonder if rebuilding might help - kvb 2012-04-04 23:51
The error only appears in fsx files. I think it is due to dependency hell when loading multiple files in FSI, as when I reorder the loads, I have the same kind of error, but with different types - nicolas 2012-04-05 09:01
I would have to build a dependency graph of all the structure, enumerate them from the edge first, then add them to FSI - nicolas 2012-04-05 09:13
Ads