scala 2.9: plans for type inference of function parameters with default arguments?

Question

I'm just getting started with Scala. I've been using Python for research programming, and I'm converting a fairly large (~ 4000 line) Python program.

A few comments:

1. It looks like the right time to get involved in Scala, as a lot of good stuff has been added to 2.8.
2. On the other hand ... I wonder why Scala doesn't seem to have a decent IO package, and why this doesn't seem to be a priority. In most languages, IO is considered one of the most fundamental operations, and parts of the language are typically designed specifically so that IO works well. For example, the IO library in Python seems one of the oldest and most stable parts of the language (at least in its interface). Yet the comments from two years ago say things like "Source.fromFile() is a massive hack, wait till so-and-so finishes the new IO package" -- and I see no movement towards finishing this. Even worse is the fact that Source.fromFile().getLines() -- which, hack or not, is the generally advertised interface -- was entirely broken by changes made in 2.9.0.1 (see https://issues.scala-lang.org/browse/SI-4662). Evidently there is no regression testing at all for this most basic of IO interfaces, which is a bad sign.
3. Type erasure sucks so incredibly badly that I really wonder why the decision was made in Scala to stick it in. Yes, I know that Java has type erasure, and Scala is built on the JVM, but the resulting need to add explicitly visible stuff like manifests, specialization annotations, etc. etc. to work around type erasure just smells really bad ... I sense ultimately that the Scala designers will realize the folly of all this, and be forced to implement proper generic typing, at which point they will then have a lot of unneeded cruft to deprecate.

My question is:

Are there plans to add type inference for function parameters with default arguments? It's getting a bit annoying to write stuff like this:

  def add_words(words:Traversable[String], ignoreCase:Boolean=true,
                stopwords:Set[String]=Set[String]()) {
    ...
  }

In this case, there's simply no need at all for the type annotations on ignoreCase and stopwords, and they just add unneeded verbosity.

Thanks for any comments from those involved in Scala development.

Answer 1

1. Scala has had good stuff added for quite a while, but as it gains popularity it will get increasingly more stable. People who were around before 2.8 had much more leverage on modifying the language than people nowdays -- both because they represented a bigger percentage of users, and because the language was more flexible.

   Take, for instance, your issue with erasure. As a 2.0 user you'd have a way bigger chance of getting something done about it than you have now. In fact, the impact that would have in compatibility is pretty much a guarantee that it won't happen anymore, unless Java leads.

2. You come from a scripting language. Scripting languages are very much concerned with I/O, because that's their butter and bread. For Scala, any serious I/O is simply relegated to Java libraries -- that's kind of the point of having Scala be compatible with Java, after all.

   Furthermore, your characterization of 4662 is, actually, completely wrong. It was not broken at all, though a change in behavior made arguably incorrect code work again. This is 4662 in a nutshell:

   val source = scala.io.Source.fromFile(new java.io.File("test1.file"))
   use(source)
   val lines = source.getLines
   

   Since source is an Iterator, it is gone once you use it. It was a coincidence that you could reuse it after calling toString on it, not an intrinsic guarantee.

3. Type erasure is not so bad. In fact, it is a sign of bad design if it gets much in the way -- you are not supposed to check what the type of something is, but to call methods on it and let it handle itself. Not to say it isn't annoying at times, but not so badly. Alas, it is a fundamental choice in having seamlessly compatibility with Java, and it was very consciously made. I don't see Scala leading the way out of it.

   One of the new languages that promise to get rid of erasure, and maintain compatibility with Java, is Ceylon. If Ceylon manages that, and I'm firmly in the doubters camp, then Scala could follow.

   Also, on a recent discussion of closures for Java 8 indicated the possibility that something might be done about erasure. If that turns out to be true, then Scala could cash in as well.

As for the question, I agree that these types could be inferred. I'm not sure anyone is doing something with default parameters, however -- priorities for the moment lie elsewhere.