I think the discussion regarding objects vs. functions is a red herring. If the question is, "Is a lambda a function or an object?" the answer should be yes.
That's the point of first-class functions: they aren't treated differently than any other type. Java already manages to mostly ignore the differences between Object and primitive types (and Scala does even better), so whether a lambda is a subclass of Object or is a new primitive type or something else isn't really important for the language. What is important is that you can put your lambdas in collections, pass them around to be called, call them, and do anything else you might want to do with either an object or a method.
Scala accomplishes this by using a wrapper object that has a method called apply
which can be invoked with just ()
, making it look just like a method call. This works splendidly; much of the time you don't need to even care whether you have a method or are calling the apply of a function object.
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.
Best Answer
In Scala, the
*
is a valid identifier. One could write:With the result being:
One could write a class named
*
as such:So with that being the case, when I have a class
*
in the packageus.hexcoder
and I write:You would be saying that you wish to import a class with the name
*
. Because of this, Scala needed to use another symbol to indicate a wildcard import. For whatever reason, they decided to use_
as the wildcard symbol.