The List.equals troubles my test code:

Int[] a := Int[1,2,3]
Int[] b := [0,1,2].map {it+1}
verifyEq(a, b)

This actually is a thorny problem. I made List.equals include the type of the list as part of its spec. So Int[,] != Str[,] which I think is the correct behavior. And certainly in a test suite, if you expect Str[] and get Obj[] there might be a bug in your code or your test.

But that said, often times I do wish to ignore the List type in equality checks. One thing I was thinking about is a new method in Test for checking list item equality (which could also dump the item noteq on failure which would be nice for debugging).

I get bitten by this often enough that, while I enjoy the convenience syntax for inferred-types on closures, it makes me wince when I write it.

That Int[] b ... line above, would work if it were

Int[] b := [0,1,2].map |Int x->Int| { x+1 }

Then, b.typeof is Int[] and all's good.

I agree that the semantics of Int[] is "ordered container of Int", therefore Int[,] != Obj[,].

I keep thinking we need to steal some better type-inference, Hindley-Milner, from Yeti or somewhere. :-)

In that case better type interference would be awesome. Though I wonder if there is limit to it?