Scala compiler error – no wonder some folks are giving up…

This is the compiler error I’m getting from Scala… This is why I’m pretty sure that tools improvement (and compiler included) is #1 priority for Scala team. How f-ing hard is to format this gibberish right? Compiler errors are FOR HUMANS to read and understand. Scala team desperately needs someone who can finally productize this technology (look at Scaladoc debacle).

error: overloaded method value mapreduce with alternatives:
(mapper: org.gridgain.grid.lang.GridMapper[org.gridgain.grid.lang.GridOutClosure[R1],org.gridgain.grid.GridRichNode],job: org.gridgain.grid.lang.GridClosure[_ >: () => R1, R1],pdc: org.gridgain.grid.lang.GridOutClosure[() => R1],cnt: Int,rdc: org.gridgain.grid.lang.GridReducer[R1,R2],p: [org.gridgain.grid.lang.GridPredicate[_ >: org.gridgain.grid.GridRichNode]])R2
(mapper: org.gridgain.grid.lang.GridMapper[org.gridgain.grid.lang.GridOutClosure[R1],org.gridgain.grid.GridRichNode],job: org.gridgain.grid.lang.GridClosure[_ >: () => R1, R1],args: java.util.Collection[_ R1],rdc: org.gridgain.grid.lang.GridReducer[R1,R2],p: [org.gridgain.grid.lang.GridPredicate[_ >: org.gridgain.grid.GridRichNode]])R2
(mapper: org.gridgain.grid.lang.GridMapper[org.gridgain.grid.lang.GridOutClosure[R1],org.gridgain.grid.GridRichNode],jobs: java.util.Collection[_ : () => R1, R1]],args: java.util.Collection[_ R1],rdc: org.gridgain.grid.lang.GridReducer[R1,R2],p: [org.gridgain.grid.lang.GridPredicate[_ >: org.gridgain.grid.GridRichNode]])R2
cannot be applied to ((Seq[() => R1]) => (() => R1) => org.gridgain.grid.GridRichNode, java.util.Collection[org.gridgain.grid.lang.GridOutClosure[R1]], (Seq[R1]) => R2, org.gridgain.grid.lang.GridPredicate[_$1(in method mapreduceAsynch)])
impl.mapreduce[R1, R2, Call[R1]](m, convert(s, (f: Call[R1]) => toOutClosure(f)), r, p: _*)

I still love Scala and would never go back. But lack of attention to details is devastating sometimes. For example, why not short-cut the repetitive package name? Or format it more forcefully? I mean – some things are just pretty obvious:

error: overloaded method value mapreduce with alternatives:
(
mapper: o.g.g.lang.GridMapper[o.g.g.lang.GridOutClosure[R1],o.g.g.GridRichNode],
job: o.g.g.lang.GridClosure[_ >: () => R1, R1],
pdc: o.g.g.lang.GridOutClosure[() => R1],
cnt: Int,
rdc: o.g.g.lang.GridReducer[R1,R2],p: [o.g.g.lang.GridPredicate[_ >: o.g.g.GridRichNode]]
)R2
============
(
mapper: o.g.g.lang.GridMapper[o.g.g.lang.GridOutClosure[R1],o.g.g.GridRichNode],
job: o.g.g.lang.GridClosure[_ >: () => R1, R1],
args: java.util.Collection[_ R1],
rdc: o.g.g.lang.GridReducer[R1,R2],
p: [o.g.g.lang.GridPredicate[_ >: o.g.g.GridRichNode]]
)R2
============
(
mapper: o.g.g.lang.GridMapper[o.g.g.lang.GridOutClosure[R1],o.g.g.GridRichNode],
jobs: java.util.Collection[_ : () => R1, R1]],
args: java.util.Collection[_ R1],
rdc: o.g.g.lang.GridReducer[R1,R2],
p: [o.g.g.lang.GridPredicate[_ >: o.g.g.GridRichNode]]
)R2
============
cannot be applied to
(
(Seq[() => R1]) => (() => R1) => o.g.g.GridRichNode,
java.util.Collection[o.g.g.lang.GridOutClosure[R1]],
(Seq[R1]) => R2,
o.g.g.lang.GridPredicate[_$1(in method mapreduceAsynch)]
)
impl.mapreduce[R1, R2, Call[R1]](m, convert(s, (f: Call[R1]) => toOutClosure(f)), r, p: _*)

4 responses

  1. I’ve added this to my anti-overloading advice. http://stackoverflow.com/questions/2510108/why-avoid-method-overloading/2512001#2512001

    Each alternative is already on a new line. Newlines between each alternative might help, as might a a numbered list, but even so, it’s pretty hard to read thanks the the number of similar alternatives in the API.

    javac only recently took steps towards improving such messages, see “improving javac diagnostics”: http://blogs.sun.com/mcimadamore/entry/improving_javac_diagnostics

    That endeavor was discussed (on IRC perhaps, I can’t find a mailing list thread) in the context of Scala, and someone had the idea to make things more readable with imports in the error message. So your example would look like: http://gist.github.com/658901. There are lots of corner cases to consider to do this properly, and I’m not aware of a prototype.

    If you have some concrete suggestions for improvements, perhaps you can start a discussion on the mailiing list; or open an enhancement request in Trac?

    -jason

  2. The problem is not that I don’t understand – I can see it clearly (after working with Scala for quite some time). Newcomers – will be turned off immediately. Short-cutting repetitive package names (a-la IDEA) and more forceful formatting can be done probably in 30-45 mins by someone with compiler sources in hand…

  3. An IDE can shorten fully qualified names because the error is shown inline at the call site, and the shortened names make sense in this context. scalac cannot shorten names and keep things unambiguous, without introducing imports or aliases, as per my gist. I don’t think that is as trivial as you suggest, but I do agree that improvements in this area are welcome.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,362 other followers

%d bloggers like this: