Scala plugin for IDEA 8733 EAP

I love the new autocompletion support.

Thanks!

Hi people. I have a problem with the latest plugin. If I create this object:

object Test {
def main(args: Array[String]) {
val testBoolean = true;
println(testBoolean)
}
}

and try to run it I can't. If I comment out the println(testBoolean) line I can run it. I can then put the line back in but then a red cross comes up (in the run configuration combo box) indicating it can't be run any more. However, if I do run it, it runs as expected. So nothing major, just slightly annoying.

Thanks, Paul.

Paul,

It looks like a omission in our type inference system. Specify type of main() function explicitly as Unit to make it run as application.

Ilya

Where is println defined?

println lives in scala.Predef. Control or Command-Click on it, IDEA will take you there.

OK, the explanation is as follows:
println() is defined in Predef (thanks, Tom), which is a compiled class. Since we don't have a scala decompiled yet, the signature of the relevant method is println(Object) instead of println(Any) as per source. Because Boolean is not a subtype of Object according to scala (there is an implicit conversion to boxed type, but we don't deal with implicits yet), this method is considered non-applicable. In Predef there is also println() without parameters, that is of course not applicable either. So there are 2 resolve candidates, and no single one. Thus we don't know the type of println() call and are not sure it is Unit/void.
So the problem is really in the lack of scala decompiler, not in type system. The work on the decompiler has been started, but it is going to take some time.

Eugene.

Hi Ilya. Your workaround worked thanks.

Another problem (that I think worked on an earlier version of the plugin) is the rename refactor seems to be broken. When renaming just between scala classes or between scala objects, the preview seems to work, be the actual refactor doesn't.

Thanks, and keep up the great work!

Paul.

I agree with your explanation of why you can't infer the type however I have two comments about this.

1) If you define any method in scala like so:

def main(args: Array[String]) { }

then the return type is always Unit. There is no need to infer the return type unless you have an equals sign as so:

def main(args: Array[String]) = { }

Therefore, you shouldn't be infering the type in this case and I should be able to use the main method as an entry point.


2) I'm sure you guys are aware that scalac gives you an AST so I suppose I'm wondering why you are parsing the code yourselves?

The merit in doing your own parsing is you will have tight integration with the IDE and it might be a difficult task to map scalac AST onto the current IDE, but the downside is it could take forever and any changes to scalac will break the IDE. I know that eclipse is using the AST and netbeans has just recently given up doing their own parsing and are now using the AST.

Thanks, Paul.

>def main(args: ArrayString) { }

>then the return type is always Unit. There is no need to infer the return type unless you have an equals sign as so:

This is true indeed, I will modify respective code accordingly.

>2) I'm sure you guys are aware that scalac gives you an AST so I suppose I'm wondering why you are parsing the code yourselves?
Yes, we are aware of the approach other IDE plugins take. However having an own type system implementation has stronger merits than what you listed:
1) it allows for more IDE features like e.g. refactorings independent of compiler support, which it probably won't have all we need ever.
2) it shields us from the instability caused by tailoring batch compiler to do IDE stuff.

Eugene.
P.S. it is a difficult task, but if noone can provide an alternative type system implementation, is the language feasible for everyday use by the progammers at all?