Fsharp: internal error : the list had different lengths. Parameter name xs2

Created on 4 Dec 2016  路  10Comments  路  Source: dotnet/fsharp

I'm new to F#, but based on information I found on StackOverflow I thought it might be useful to mention this compile error I can't get rid of.

"internal error : the list had different lengths. Parameter name xs2"

Repro steps

Try compiling this project https://github.com/robsiera/Fsharp-SignalR in Visual Studio 2015
That will trigger the error.

The project is currently using the latest nuget F# pre-release. But even that didn't solve the problem.

All 10 comments

IMHO this is not a compiler bug.

I assume it fails at

let definedClientHubTypes =
    List.zip (typeInfo |> List.map (fun (n,_) -> n)) clientTypeInfo
    |> List.map makeClientHubType

in SignalRProvider.fs.

Please report this to the author of tje SignalRProvider

Thx @forki for having a look at it.
But the error message is a compiler error message right? If so, then who/what is responsible (who's concern is it) for making sure that developers know what is going on. I mean, even you have to 'assume' where it fails. Can't we get rid of that kind of uncertainty?

No it's not. It's thrown by the zip function inside of the type provider constructor. This is "user code" that happens to be run at compile time. Yeah type providers are weird.

The message itself comes from fsharp.core and you can reproduce this easily if you zip two lists with unequal lengths in fsi. So the author of the type provider needs to make sure both lists are of equal length. If the author can't ensure that he should throw a detailed error message which gives a better error. As I said this is all "user code" and not coming from the compiler itself.

Ok, case closed.

But for future reference (it was very hard to find any information on this error) allow me to give my personal conclusion

Due to the fact that the error is raised in the context of a Type Provider, one needs to debug that Provider in order to gather more information on the error raised.
So it is just a matter of getting the Type Provider debugging to work. Which seems easier said than done. I tried following 3 different tutorials.

yes definetly a super complicated issue and needs much more love. I fully aggree

One could argue that the bug is the bad error message produced by the compiler. Maybe the compiler should write the full error info somewhere...

image

ok not that bad :)

That's what I got ootb in VS2013. I mean it could clearly be improved, but it's already pointing in the right direction.

But the xs2 part of the zip error message is really not helpful

We should just give a partial stack trace on type provider errors. That would help enormously.

Was this page helpful?
0 / 5 - 0 ratings