If I define a simple stringToInt function and store it as a val, everything works as expected, e.g.
scala> def stringToInt1: (String => Int) = _.toInt
stringToInt1: String => Int
scala> stringToInt1("1")
res0: Int = 1
However, if I then make that implicit, it causes a stack overflow:
scala> implicit def stringToInt2: (String => Int) = _.toInt
stringToInt2: String => Int
scala> stringToInt2("1")
java.lang.StackOverflowError
at .stringToInt2(<console>:7)
at $anonfun$stringToInt2$1.apply(<console>:7)
at $anonfun$stringToInt2$1.apply(<console>:7)
...
At first I suspected that this was because the underscore wasn't resolving to what I expected, but that's not the case, as this style of implicit val works fine for the following simple function:
scala> implicit def plusTwo: (Int => Int) = _ + 2
plusTwo: Int => Int
scala> plusTwo(2)
res2: Int = 4
If I define the parameter explicitly, no stack overflow:
scala> implicit def stringToInt3(s: String) = s.toInt
stringToInt3: (s: String)Int
scala> stringToInt3("1")
res3: Int = 1
(If trying this yourself and this last case stack overflows, restart the scala console and redo this last step)
So my question is, why is the original implicit not correctly resolving?
Edit
Ok digging a little deeper here, it seems that the problem is with the implicit conversion from String to StringOps. If we cut that out, it works fine:
scala> import scala.collection.immutable.StringOps
import scala.collection.immutable.StringOps
scala> implicit def stringToInt4: (String => Int) = new StringOps(_).toInt
stringToInt4: String => Int
scala> stringToInt4("1")
res4: Int = 1
But why would that implicit conversion be causing the issue?
Adding to the other replies.
There is no toInt method on String. Scala has to find an implicit conversion that will yield a type that has a toInt method.
Usually the StringOps conversion provides this toInt.
However Int has a toInt too, so scala finds your conversion from String => Int and decides that it has precedence over the StringOps conversion, thus applying it recursively.
This is why StringToInt4 works, as you explicitly tell the compiler what conversion you want. Maybe you could write it as: implicit def stringToInt5: (StringOps => Int) = _.toInt or check how implicits are resolved and how one takes precedence over the other.
Note what you are doing here:
scala> def stringToInt1: (String => Int) = _.toInt
stringToInt1: String => Int
You are defining a method (using def) that takes no parameters and returns a function from String to Int. Are you doing it this way on purpose, or is it just because you don't exactly understand the syntax?
You could have created a val instead:
val stringToInt1: (String => Int) = _.toInt
Now, stringToInt1 is a val that contains a function to convert String to Int.
With your stringToInt2, Scala is recursively applying the method. I don't know why it does that in the case of stringToInt2 but not with plusTwo.
Note that stringToInt3 is not the same thing as stringToInt1 and stringToInt2. It's a method that takes a String and returns an Int, not a method that takes no parameters and returns a function from String to Int.
Related
I have the following two methods in Scala:
def myFunc: Int => String = { age =>
"Here " + age
}
def myFunc2 (age: Int) : String = {
"Here" + age
}
Is there any difference in these two methods? (other than the names of course). The syntax looks quite different to me. Is it just a matter of style? Is one prefered over the other?
Yes, there is a difference. The former is a method which takes no arguments and returns a function of type Function1[Int, String]. The latter is a method taking a String and returning an Int.
In Scala, methods with arity-0 can be declared and invoked without parenthesis, so invoking myFunction(1) and myFunction2(1) looks the same.
If we'd convert both methods to functions, you'd see the difference in the fact that the former would take the shape of Function0[Function1[Int, String]], while the latter would be Function1[Int, String]:
myFunc: Int => String
myFunc2: (age: Int)String
scala> myFunc _
res6: () => Int => String = <function0>
scala> myFunc2 _
res7: Int => String = <function1>
Being relatively new at Scala, I was playing around with partially-applied function syntax on sbt console. I ran into a very weird issue in which I do not understand Scala's behavior.
The example is contrived and would unlikely be encountered in reality. That said, here it is. Suppose I define the following function:
scala> def f(x: Int, y: Int) = "%d %d".format(x, y)
Now if I type in
scala> f(1, _:Int)(2)
res: Int => Char = <function1>
The result is a Int => Char function, which is very unusual. In other words, Scala is (temporarily) treating f(1, _:Int) as a String (vs. its actual type: Int => String) when applying the parameter (i.e., 2).
If, instead, parentheses are used, what I expect to happen occurs:
scala> (f(1, _:Int))(2)
res: String = 1 2
However, this does not appear to be an order-of-operations issue, as I cannot find a way to add parentheses to achieve the unexpected behavior (i.e., having the result be of type Int => Char).
Any ideas?
At first about the result type of:
scala> f(1, _:Int)(2)
res: Int => Char = <function1>
Check this out:
scala> val str = "hello"
str: String = hello
scala> str(2)
res12: Char = l
I think this is clear.
No to the function itself, as it also easy. When you are lifting it to a function with an underscore you are lifting not only f, but also with a call (2) on a string (first result), which is why you get:
res: Int => Char = <function1>
Added
More explicit version. You function f is of type (Int, Int) => String, when you write f(1, _: Int), you are partially applying it to the argument one and returning a function of type Int => String, where Int is the second argument. Then your argument (2) call apply method on the result string from the function Int => String which returns you a Char, from here you get function of type Int => Char, where Int is a second argument to your f function and Char is a char from the resulting string
In the second case, where you have:
scala> (f(1, _:Int))(2)
res: String = 1 2
by parenthesis you are spliting this into to things, the first one is a function Int => String and (2) calls this function, you are passing an argument 2 into this function Int => String:
val ff = f(1, _: Int)
val res = ff(2)
I am new to Scala, and trying to understand the following codes (derived from an example in the Beginning Scala book)
scala> def w42(f: Int => Int) = f(42) //(A)
w42: (f: Int => Int)Int
scala> w42 (1 +) //(B)
res120: Int = 43
I do not understand how "1 +" at point (B) is consider as a function (take 1 Int parameter, and return an Int) that satisfies the w42 definition at point (A)?
Would you mind please explain or point me to some documents that have the answer?
Simple. In Scala 1 + 2 is just a syntax sugar over 1.+(2). This means Int has a method named + that accepts Int:
final class Int extends AnyVal {
def +(x: Int): Int = //...
//...
}
This is why you can use 1 + as if it was a function. Example with less unexpected method naming:
scala> def s42(f: String => String) = f("42")
s42: (f: String => String)String
scala> s42("abc".concat)
res0: String = abc42
BTW Technically speaking, eta-expansion is also involved to convert method to a function.
I wonder why there doesn't exist a literal for partial function types. I have to write
val pf: PartialFunction[Int, String] = {
case 5 => "five"
}
where an literal like :=> would be shorter:
val pf: Int :=> String = {
case 5 => "five"
}
Partial functions are often used and in Scala already some "special" feature, so why no special syntax for it?
Probably in part because you don't need a literal: you can always write your own :=> as a type infix operator if you want more concise syntax:
scala> type :=>[A, B] = PartialFunction[A, B]
defined type alias $colon$eq$greater
scala> val pf: Int :=> String = { case 5 => "five" }
pf: :=>[Int,String] = <function1>
scala> pf.isDefinedAt(0)
res0: Boolean = false
scala> pf.isDefinedAt(5)
res1: Boolean = true
I'm not one of the designers of the Scala language, though, so this is more or less a guess about the "why?". You might get better answers over at the scala-debate list, which is a more appropriate venue for language design questions.
def foo(x: Int, f: Unit => Int) = println(f())
foo(2, { Unit => 3 + 4 })
// case 1
def loop: Int = 7
foo(2, loop) // does not compile
changing loop to
// case 2
def loop(): Int = 7
foo(2, loop) // does not compile
changing loop to
// case 3
def loop(x: Unit): Int = 7 // changing according to Don's Comments
foo(2, loop) // compiles and works fine
Shouldn't case 1 and case 2 also work? Why are they not working?
Defining foo as
def foo(x: Int, y: () => Int)
then case 2 works but not case 1.
Arent they all supposed to work, defining the functions either way?
Also I think () => Int in foo is a bad style, y:=> Int does not work. Comments?
Scala distinguishes between the following things:
Functions/methods with no parameter lists ("by-name parameter" if a function)
Functions with one empty parameter list
Functions with one parameter of type Unit
None of these are equivalent, although as a convenience Scala allows you to elide empty parameter lists. (Incidentally, two empty parameter lists are also not the same.)
So, even though Unit is written (), this is not the same as the function argument parens () for a function or method. Instead, think of () as a Tuple0.
So, if you say f: Unit => Int, what you mean is "f takes one parameter, but it's a really boring parameter because it is Unit, which must always be the same boring Tuple0 value ()". What you're writing is really short for f: (Unit) => Int.
If you say f: () => Int, then you mean that "f takes no parameters and produces an Int".
If you say f: => Int, then you mean that "delay the execution of whatever statement produces an Int value until we use it in this code (and re-evaluate it each time)". Functionally, this ends up being basically the same as f: () => Int (and internally is converted into the same Function0 class), but it has a different usage, presumably to allow for a more compact form of closures (you always omit the => in the calling code).
()=>Int is Function0[Int] while Unit=>Int is Function1[Unit,Int]
scala> val function0: () => Int = () => 5
function0: () => Int = <function0>
scala> val function1: Unit => Int = u => 5
function1: (Unit) => Int = <function1>
scala> function0()
res0: Int = 5
scala> function1("anything")
res1: Int = 5
scala> function1(100)
res2: Int = 5
scala>
Also note that () is an object of Unit
scala> function1(())
res11: Int = 5
scala> function1 ()
res12: Int = 5
scala> function1()
res13: Int = 5
scala> val unit = ()
unit: Unit = ()
scala> function1(unit)
res15: Int = 5
scala> function1 apply unit
res16: Int = 5
scala>
In case 1 and 2 above, the return value of loop rather than loop itself is type checked for the second argument to foo and fails: Int != Unit => Int
The change to loop has a typo.