Wierd problem comparing numeric values and list using == (PR#1076)

      > list(1) == list(1)

      [1] FALSE

      > 1 == list(1)

      [1] TRUE

      > as.integer(1)==list(as.integer(1))

      [1] FALSE

      > as.integer(1)==list(as.double(1))

      [1] FALSE

      > list(as.integer(1))==list(as.integer(1))

      [1] FALSE

      > list(as.integer(1))==as.integer(1)

      [1] FALSE

      > list(as.double(1))==list(as.double(1))

      [1] FALSE

However, these cases work:

      > as.double(1)==list(as.integer(1))

      [1] TRUE

      > list(as.integer(1))==as.double(1)

      [1] TRUE

As of 1.4, we will have the `identical' function, which is the right way
to do such comparisons in any case.

So I'd vote for making a use of the comparison operators an error unless
the type is correct (or there is a method defined).  There is even code
in relop.c (commented out) that looks like the right test.  Any
objections?

x<-2
list(x)==list(x)

list(.Alias(x))==list(.Alias(x))

As of 1.4, we will have the `identical' function, which is the right way
to do such comparisons in any case.

So I'd vote for making a use of the comparison operators an error unless
the type is correct (or there is a method defined).  There is even code
in relop.c (commented out) that looks like the right test.  Any
objections?

Not really, except that I get the usual nagging suspicion that someone
(who?) meant something by doing it this way...

The current logic seems to be that if either side of the == is a
vector of atomic type, try to coerce the list on the other side to a
similar object and then test. However this has a clear bug in that the
coercion is to double even when the atomic vector is integer. If there
are lists on both sides, a pointer comparison is done:

x<-2
list(x)==list(x)

[1] FALSE

list(.Alias(x))==list(.Alias(x))

[1] TRUE

The latter seems highly dubious to me. I'd rather have a recursive
pairwise application of "==" there. However, none of this is what
identical does, is it?