Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I recently began learning to program in Scala, and it's been fun so far. I really like the ability to declare functions within another function which just seems to intuitive thing to do.

One pet peeve I have about Scala is the fact that Scala requires explicit return type in its functions. And I feel like this hinders on expressiveness of the language. Also it's just difficult to program with that requirement. Maybe it's because I come from Javascript and Ruby comfort zone. But for a language like Scala which will have tons of connected functions in an application, I cannot conceive how I brainstorm in my head exactly what type the particular function I am writing should return with recursions after recursions.

This requirement of explicit return type declaration on functions, do not bother me for languages like Java and C++. Recursions in Java and C++, when they did happen, often were dealt with 2 to 3 functions max. Never several functions chained up together like Scala.

So I guess I'm wondering if there is a good reason why Scala should have the requirement of functions having explicit return type?

share|improve this question
5  
It doesn't -- and I fail to see why it would be a problem if it did. –  Keith Thompson Oct 3 '12 at 3:24
1  
I thought it did. Are there cases in Scala where the return type for a function is actually ambiguous? –  garbage collection Oct 3 '12 at 3:37

1 Answer 1

up vote 11 down vote accepted

Scala doesn't require an explicit return type on all functions, just recursive ones. The reason for that is that Scala's type inference algorithm is (something close to) a simple scan from beginning to end that is incapable of lookahead.

This means that a function like this:

def fortuneCookieJoke(message: String) = message + " in bed."

doesn't need a return type, since the Scala compiler can clearly see, without using logic variables or looking at anything other than the method's parameters, that the return type must be String.

On the other hand, a function like this:

def mapInts(f: (Int) => Int, l: List[Int]) = l match {
  case Nil => Nil
  case x :: xs => f(x) :: mapInts(f, xs)
}

will cause a compile-time error, because the Scala compiler cannot see, without using either lookahead or logic variables, exactly what the type of mapInts is. The most it could say, if it were smart enough, is that the return type is a supertype of List[Nothing], since Nil is of that type. That doesn't give it anywhere near enough information to accurately determine the return type of mapInts.

Please note that this is specific to Scala, and that there are other statically typed languages (most of the Miranda/Haskell/Clean family, most of the ML family, and a few scattered others) that use much more comprehensive and capable type inference algorithms than Scala uses. Also, be aware that this is not entirely Scala's fault; nominal subtyping and whole-module type inference are fundamentally at odds with each other, and the designers of Scala chose to favor the former over the latter for the sake of Java compatibility, while the "purer" statically typed functional languages were mostly designed with the opposite choice in mind.

share|improve this answer
4  
Actually, the problem is not so much figuring out a more comprehensive type inferencing algorithm. It's figuring out a more comprehensive type inferencing algorithm, while keeping the high quality of error messages in the current Scala compiler. –  Jörg W Mittag Oct 3 '12 at 5:21
1  
Wouldn't the correct return for case Nil actually be an empty List[Int]()? In which case a sufficiently smart compiler could figure it out. That's all playing Devil's Advocate though, I suppose. –  KChaloux Dec 12 '12 at 15:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.