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.

Answer 2

1. Yes

2. Because the underlying VM abstracts any access to the world "outside", there is basically the option to either ship with compiled code, making Scala not platform-independent or using things like java.io.File which is just utterly broken. Java 7 has (after only 15 years) finally added some usable file system API, which is already targeted as far as I know by the in-progress Scala IO library. Another point is the support of other runtime platforms. It isn't a good idea to release a Scala IO library which has only a JVM implementation. So basically: Having some decent IO library was made possible by Java 7 a few weeks ago. Considering that Scala will not drop support for Java 6 (and 5) in the near future, don't expect IO shipping with the standard library soon.

3. You are using it wrong. But feel free to create your own language which does everything better if you think "Scala designers will realize the folly". Reified generics are hard to combine with higher-kinded types. And if I had to choose, I will take HKT over reified generics every time.

Ahhh .. right. These things aren't your questions. Answer to your actual question:

It could be done, but people like to keep the rules simple. So probably not.

Answer 3

I don't have enough rep power to add this as a comment, so I must add as an answer. Also this is too long for a comment.

Regarding the main question, I agree that the types of input parameters with default values could be inferred. I did the following query at their Scala issues tracker and didn't find an applicable feature request. So perhaps you could file one there.

project = SI AND (summary ~ "default" AND summary ~ "value")

1. no comment
2. no comment
3. As others have pointed out, reification (ie not type erasure) makes higher-kinded generics more difficult to implement. Here is a direct quote from section 6.1 of "Generics of a Higher Kind", Piessens, Moors, Odersky.

Since Scala uses type erasure in the back-end, the extent of the changes is limited to the type checker. Clearly, our extension thus does not have any impact on the run-time characteristics of a program. Ironically, as type erasure is at the root of other limitations in Scala, it was an important benefit in implementing type constructor polymorphism.

Similar extensions in languages that target the .NET platform face a tougher challenge, as the virtual machine has a richer notion of types and thus enforces stricter invariants. Unfortunately, the model of types does not include higher-kinded types. Thus, to ensure full interoperability with genericity in other languages on this platform, compilers for languages with type constructor polymorphism must resort to partial erasure, as well as code specialisation in order to construct the necessary representations of types that result from abstract type constructors being applied to arguments.

You can review that paper for an explanation of why higher-kinded generics are important. Although Scala 2.8 does not apparently use them extensively in their new collections library, so far I find it is impossible to implement my category theory library in a subtyped elegant manner without higher-kinds (contrast this with Scalaz non-subtyped design which I find to be extremely complex).

Daniel C. Sobral regarding your comment below your answer, I think it is the D principle in SOLID that is violated by constructors. Urban Vagabon, factories should be used to achieve inversion-of-control, a/k/a the Hollywood principle. See also Gilad Bracha's blog "Constructors Considered Harmful".

This is not intended to be the most complete or best answer, rather some partial thoughts which might add to this knowledge-base.