"Unpredictable" class cast exception in Seq.sortWith

On Sat, Jun 19, 2010 at 02:53:24PM -0700, Niels Hoogeveen wrote:
> I'm trying sort a sequence of tuples based on one of the tuple
> elements which is a Double and run into a class cast exception.

I'm not sure how that is happening, and if you can narrow it you should
probably open a ticket, but in the meantime: you are calling sortWith,
which takes a (T, T) => Boolean argument, and one way or another it
thinks (Int, Int) => Boolean is the right thing. It's the closure being
compiled to CompositeTemplate$$anonfun$1.apply.

If you insist it use (Double, Double) => Boolean I expect your CCE will
go away. As always it's a little easier if you supply some source.
Most likely it would be enough to see the sortWith.

> If you insist it use (Double, Double) => Boolean I expect your CCE will
> go away. As always it's a little easier if you supply some source.
> Most likely it would be enough to see the sortWith.
>
The offending line of code reads like this:

val sortedChldtRels = chldtRels.sortWith((a, b) =>
a.get(SubtemplateWeight).asInstanceOf[Double] <
b.get(SubtemplateWeight).asInstanceOf[Double])

The get(SubtemplateWeight) calls return a Double, but since the dependent
method type (running with both Xfuture and Xexperimental on) I use for the
get method doesn't always get inferred properly, I explicitly cast it to a
Double in the comparison closure.

The underlying value of get(SubtemplateWeight) is most certainly a Double,
or to be more accurate a java.lang.Double.

I wish I could reproduce the error, but it seems to be a pretty intricate
error that depends on the order of compilation. Once I recompile the file
containing the offending line of code, the problem goes away.

SubtemplateWeight and the get method are both not contained in the file
giving this CCE.

On Sun, Jun 20, 2010 at 05:17:05AM -0700, Niels Hoogeveen wrote:
> The offending line of code reads like this:
>
> val sortedChldtRels = chldtRels.sortWith((a, b) =>
> a.get(SubtemplateWeight).asInstanceOf[Double] <
> b.get(SubtemplateWeight).asInstanceOf[Double])
>
> The get(SubtemplateWeight) calls return a Double, but since the
> dependent method type (running with both Xfuture and Xexperimental on)

Oh I see, only two explicit casts, two nutty compiler options, and one
very experimental and unsupported feature. Do I have to even explain
what's wrong with this question and answer sequence? You make me feel
like a sucker for trying to answer the original question.

Perhaps I can illustrate by analogy.

"Doctor, there's something wrong with my child! He has a terrible head
pain!"

"I'm a medical professional, I'm here to help. Do you have any idea
what could have happened?"

"Not a one! He's been quietly hitting himself in the forehead with the
hammer from his Little Mechanic toolset and I've been feeding him these
experimental brain pills I bought from a Nigerian pharmacy, but I don't
know what that could have to do with anything."

"Thank you for paging me. I prescribe amputation."

If I ever write a Scala book, can I please quote you on that?It's inspired, and really must be preserved for future generations...
:)
On 20 June 2010 17:03, Paul Phillips <paulp@improving.org> wrote:

On Sun, Jun 20, 2010 at 05:17:05AM -0700, Niels Hoogeveen wrote:
> The offending line of code reads like this:
>
> val sortedChldtRels = chldtRels.sortWith((a, b) =>
> a.get(SubtemplateWeight).asInstanceOf[Double] <
> b.get(SubtemplateWeight).asInstanceOf[Double])
>
> The get(SubtemplateWeight) calls return a Double, but since the
> dependent method type (running with both Xfuture and Xexperimental on)

Oh I see, only two explicit casts, two nutty compiler options, and one
very experimental and unsupported feature.  Do I have to even explain
what's wrong with this question and answer sequence? You make me feel
like a sucker for trying to answer the original question.

Perhaps I can illustrate by analogy.

"Doctor, there's something wrong with my child! He has a terrible head
pain!"

"I'm a medical professional, I'm here to help.  Do you have any idea
what could have happened?"

"Not a one! He's been quietly hitting himself in the forehead with the
hammer from his Little Mechanic toolset and I've been feeding him these
experimental brain pills I bought from a Nigerian pharmacy, but I don't
know what that could have to do with anything."

"Thank you for paging me.  I prescribe amputation."

--
Paul Phillips      | We must respect the other fellow's religion, but only
Everyman           | in the sense and to the extent that we respect his
Empiricist         | theory that his wife is beautiful and his children smart.
i pull his palp!   |     -- H. L. Mencken

--
Kevin Wright

mail/google talk: kev.lee.wright@gmail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Thank you for your kind response. It was most enlightening.

Somewhere down the line, dependent method types will no longer be
experimental and then this issue will probably pop up in other peoples code
too, until that time I will have to live with a somewhat quirky compilation
cycle.

Sorry I wasted your precious time.