Two ways of defining functions in Scala. What is the difference? - function

Here is a little Scala session that defines and tries out some functions:
scala> def test1(str: String) = str + str;
test1: (str: String)java.lang.String
scala> test1("ab")
res0: java.lang.String = abab
works nicely.
scala> val test2 = test1
<console>:6: error: missing arguments for method test1 in object $iw;
follow this method with `_' if you want to treat it as a partially applied function
val test2 = test1
^
oops.
scala> val test2 = test1 _
test2: (String) => java.lang.String = <function1>
scala> test2("ab")
res1: java.lang.String = abab
works well!
Now, I've seen the _ syntax when folding (_ + _, etc). So as I understand it _ basically means "an argument". So test1 _ basically means a function with an argument, which is given to test1". But why isn't that exactly the same as just test1? Why is there a difference if I append a _?
So I kept exploring...
scala> val test3 = (str: String) => str + str
test3: (String) => java.lang.String = <function1>
scala> test3("ab")
res2: java.lang.String = abab
scala> val test4 = test3
test4: (String) => java.lang.String = <function1>
Here it works without _! What's the difference between a defed function, and a valed function?

The def declares a method within a surrounding object/class/trait, similar to the way you define methods in Java. You can only use defs within other objects/classes/traits. In the REPL, you cannot see the surrounding object because it's "hidden", but it does exist.
You cannot assign a def to a value, because the def is not a value - it's a method in the object.
The (x: T) => x * x declares and instantiates a function object, which exists at runtime. Function objects are instances of anonymous classes which extend FunctionN traits. FunctionN traits come with an apply method. The name apply is special, because it can be omitted. Expression f(x) is desugared into f.apply(x).
The bottomline is - since function objects are runtime values which exist on the heap, you can assign them to values, variables and parameters, or return them from methods as return values.
To solve the issue of assigning methods to values (which can be useful), Scala allows you to use the placeholder character to create a function object from a method. Expression test1 _ in your example above actually creates a wrapper function around the method test1 - it is equivalent to x => test1(x).

There's no difference between a def'ed function and a val'ed function:
scala> def test1 = (str: String) => str + str
test1: (String) => java.lang.String
scala> val test2 = test1
test2: (String) => java.lang.String = <function1>
scala> val test3 = (str: String) => str + str
test3: (String) => java.lang.String = <function1>
scala> val test4 = test2
test4: (String) => java.lang.String = <function1>
See? All of these are functions, which is indicated by the X => Y type they have.
scala> def test5(str: String) = str + str
test5: (str: String)java.lang.String
Do you see an X => Y type? If you do, go see an ophthalmologist, because there's none. The type here is (X)Y, commonly used to denote a method.
Actually, test1, test2, test3 and test4 are all methods, which return functions. test5 is a method which returns a java.lang.String. Also, test1 through test4 do not take parameters (only test1 could, anyway), while test5 does.
So, the difference is pretty simple. In the first case, you tried to assign a method to a val, but did not fill in the parameters the method take. So it failed, until you added a trailing underscore, which meant turn my method into a function.
In the second example you had a function, so you didn't need to do anything else.
A method is not a function, and vice versa. A function is an object of one of the FunctionN classes. A method is a handle to some piece of code associated with an object.
See various questions about methods vs functions on Stack Overflow.

The underscore means different things in different contexts. But it can always be thought of as the thing that would go here, but doesn't need to be named.
When applied in place of parameters, the effect is to lift the method to a function.
scala> def test1(str: String) = str + str;
test1: (str: String)java.lang.String
scala> val f1 = test1 _
f1: (String) => java.lang.String = <function1>
Note, the method has become a function of type (String) => String.
The distinction between a method and a function in Scala is that methods are akin to traditional Java methods. You can't pass them around as values. However functions are values in their own right and can be used as input parameters and return values.
The lifting can go further:
scala> val f2 = f1 _
f2: () => (String) => java.lang.String = <function0>
Lifting this function results in another function. This time of type () => (String) => (String)
From what I can tell, this syntax is equivalent to substituting all of the parameters with an underscore explicitly. For example:
scala> def add(i: Int, j: Int) = i + j
add: (i: Int,j: Int)Int
scala> val addF = add(_, _)
addF: (Int, Int) => Int = <function2>
scala> val addF2 = add _
addF2: (Int, Int) => Int = <function2>

Related

How does addition function parameters appeared in scala?

I am reading example about monad transformers in scalaz. Here is a piece of code:
scala> def myName(step: String): Reader[String, String] = Reader {step + ", I am " + _}
myName: (step: String)scalaz.Reader[String,String]
scala> def localExample: Reader[String, (String, String, String)] = for {
a <- myName("First")
b <- myName("Second") >=> Reader { _ + "dy"}
c <- myName("Third")
} yield (a, b, c)
localExample: scalaz.Reader[String,(String, String, String)]
scala> localExample("Fred")
res0: (String, String, String) = (First, I am Fred,Second, I am Freddy,Third, I am Fred)
How does it happen, that localExample can take a parameter? Oo There is not any parameters list in definition
localExample: Reader[String, (String, String, String)] just return type is specified. Also the same question about
myName function, it also has more function parameters then mentioned in its definition.
The key is in the return type that is specified, which is an instance of the Reader monad. Roughly, the reader monad is like a wrapper around a function from - in the case of myName - String to String, so it is a bit like a function defined as:
def myName(step: String): String => String
For localExample, the return type is now a "wrapper around a function from String to Triple of String" (quotes used because this is something of a simplified sense of what the Reader monad is).
In both cases, the return type is - sort of - a function that can take a (String) parameter with which to generate a final result, and it is this sort-of-a function that is taking the parameter passed to localExample in the call localExample("Fred"). Essentially like calling localExample().apply("Fred").
There is more to monads like the Reader than just the above (which I'm not sure I feel expert enough to explain properly right now), but hopefully that's enough to answer your question.

Why are Scala class methods not first-class citizens?

I've just started Scala and am tinkering in worksheets. For example:
def merp(str: String) : String = s"Merrrrrrrp $str"
val merp2 = (str: String) => s"Merrrrrrrp $str"
val merp3 = (str: String) => merp(str)
val merp4 = merp _
merp("rjkghleghe")
merp4("rjkghleghe")
And the corresponding worksheet results:
merp: merp[](val str: String) => String
merp2: String => String = <function1>
merp3: String => String = <function1>
merp4: String => String = <function1>
res0: String = Merrrrrrrp rjkghleghe
res1: String = Merrrrrrrp rjkghleghe
Saying, for example, val merp5 = merp produces an error, because apparently methods cannot be values the way functions can. But I can still pass methods as arguments. I demonstrate this in the following code snippet, adapted from a similar SO question:
def intCombiner(a: Int, b: Int) : String = s"herrrrrrp $a derrrrrrp $b"
def etaAbstractor[A, B](combineFoo: (A, B) ⇒ String, a: A, b: B) = combineFoo(a, b)
etaAbstractor(intCombiner, 15, 16)
worksheet result:
intCombiner: intCombiner[](val a: Int,val b: Int) => String
etaAbstractor: etaAbstractor[A,B](val combineFoo: (A, B) => String,val a: A,val b: B) => String
res10: String = herrrrrrp 15 derrrrrrp 16
Is methods-not-being-first-class a limitation, perhaps imposed by Scala's JVM interaction, or is it a decision in the language's design?
Why do I need to roll my own eta abstractions, as in merp3?
Is merp4 also an eta abstraction, or is it something sneakily similar?
Why does my etaAbstractor work? Is Scala quietly replacing intCombiner with intCombiner _?
Theoretical, computer sciencey answers are welcome, as are pointers to any relevant points in the language specification. Thanks!
Disclaimer: I'm not a computer scientist, but I will try to guess:
Method is a part of an object and doesn't exist outside of it. You can't pass method alone. Closure is another (equivalent?) way of encapsulating state, by converting an object method to a standalone function (which is by the way just another object with apply() method in Scala) you are creating a closure. This process is known as eta-expansion. §3.3.1, §6.26.5
You don't have to. You can also write val merp3 : (String => String) = merp. §6.26.5
Yes, merp4 is eta-expansion too. §6.7
§6.26.2
The reason it works with etaAbstractor is that the compiler can infer that a function (not a function invocation) is required.
If I had to guess why the underscore is required where a function type cannot be inferred, I'd think that it's to improve error reporting of a common class of errors (getting functions where invocations are intended). But again, that's just a guess.
In the JVM, a method is not an object, whereas a first-class function must be one. So the method must be boxed into an object to convert it to a function.

Overcoming type erasure in Scala when pattern matching on Objects which may be different Sets or any type of Object

Is there any way of pattern matching objects where the objects may be Set[Foo] or Set[Bar] when the matching object can be any Object.
Given the below code, trying to pattern match on Set[Bar] will result in a match of Set[Foo] because of type erasure.
import play.api.libs.json._
import scala.collection.immutable.HashMap
case class Foo(valOne: Int, valTwo: Double)
object Foo {
implicit val writesFoo = Json.writes[Foo]
}
case class Bar(valOne: String)
object Bar {
implicit val writesBar = Json.writes[Bar]
}
case class TestRequest(params: Map[String, Object])
object TestRequest {
import play.api.libs.json.Json.JsValueWrapper
implicit val writeAnyMapFormat = new Writes[Map[String, Object]] {
def writes(map: Map[String, Object]): JsValue = {
Json.obj(map.map {
case (s, a) => {
val ret: (String, JsValueWrapper) = a match {
case _: String => s -> JsString(a.asInstanceOf[String])
case _: java.util.Date => s -> JsString(a.asInstanceOf[String])
case _: Integer => s -> JsString(a.toString)
case _: java.lang.Double => s -> JsString(a.toString)
case None => s -> JsNull
case foo: Set[Foo] => s -> Json.toJson(a.asInstanceOf[Set[Foo]])
case bar: Set[Bar] => s -> Json.toJson(a.asInstanceOf[Set[Bar]])
case str: Set[String] => s -> Json.toJson(a.asInstanceOf[Set[String]])
}
ret
}}.toSeq: _*)
}
}
implicit val writesTestRequest = Json.writes[TestRequest]
}
object MakeTestRequest extends App {
val params = HashMap[String, Object]("name" -> "NAME", "fooSet" -> Set(Foo(1, 2.0)), "barSet" -> Set(Bar("val1")))
val testRequest = new TestRequest(params)
println(Json.toJson(testRequest))
}
Trying to serialise the TestRequest will result in:
Exception in thread "main" java.lang.ClassCastException: Bar cannot be cast to Foo
Delegating the pattern matching of Sets to another method in an attempt to get the TypeTag,
case _ => s -> matchSet(a)
results in the type, unsurprisingly, of Object.
def matchSet[A: TypeTag](set: A): JsValue = typeOf[A] match {
case fooSet: Set[Foo] if typeOf[A] =:= typeOf[Foo] => Json.toJson(set.asInstanceOf[Set[Foo]])
case barSet: Set[Bar] if typeOf[A] =:= typeOf[Bar] => Json.toJson(set.asInstanceOf[Set[Bar]])
}
The runtime error being:
Exception in thread "main" scala.MatchError: java.lang.Object (of class scala.reflect.internal.Types$ClassNoArgsTypeRef)
A workaround could be to check the instance of the first element in the Set but this seems inefficient and ugly. Could also match on the key eg fooSet or barSet but if the keys are the same name eg both called set, then this wouldn't work.
In 2.11 s there any way to get at the type/class the Set has been created with?
You could use Shapeless typeable. Note that this is still not 100% safe (e.g. empty lists of different types cannot be distinguished at runtime, because that information literally doesn't exist); under the hood it's doing things like checking the types of the elements using reflection, just with a nicer interface on top.
In general it's better to carry the type information around explicitly, e.g. by using a a case class (or a shapeless HMap) rather than an untyped Map. Less good, but still better than nothing, is using wrapper case classes for the different types of Set that are possible, so that each one is a different type at runtime.
(Also half the point of the pattern match is to avoid the asInstanceOf; you should use e.g. foo rather than a.asInstanceOf[Set[Foo]])

Scala type parameters by declaring the type inside the function

I'm just starting to learn Scala, coming from a Java background. I have been trying to understand type parameters in functions and inference of types. This is a standard example in the Scala docs:
class Decorator(left: String, right: String) {
def layout[A](x: A) = left + x.toString() + right
}
object FunTest extends Application {
def apply(f: Int => String, v: Int) = f(v)
val decorator = new Decorator("[", "]")
println(apply(decorator.layout, 7))
}
If I try to apply a type parameter to the apply function and keep v a strong type, a type mismatch occurs. Why doesn't the type get inferred here?
def apply[B](f: B => String, v: String) = f(v) //Type mismatch
def apply[B](f: B => String, v: B) = f(v) //Works fine
Thanks
Let's take a look at apply without it's body:
def apply[B](f: B => String, v: String)
That reads "apply is a function (method) parameterized on a type B, that takes a function from B to String, and a String".
Think of B as a type variable; it will need to be instantiated at some point. That point is not the declaration of apply. It is when apply is, well, applied to ;-)
By this contract, usage like this must be allowed:
def g(i: Int): String = "i is " + i
apply(g, "foo") // Here the type variable `B` is "instantiated" to the type Int,
But given that you have a body like f(v), just substituting, we see the contradiction:
Substitute
f(v)
With
g("foo") // can't compile; g takes a B, which is an Int

How to test that an object is not a function in scala

My problem is quite simple : I want to have an implicit conversion of value to function if they are not already function. I plan to use a type safe pattern by requesting the instantiation of an implicit parameter (if the valueis a function the implicit creation fails).
However I do not see how to test that a value is not a function
I learned type safe pattern from user Beryllium in one of my previous question. See :
Type safe method chaining that doesn't allow repeats of operations
The implicit I've implemented is working, but too well. I want to transform not function expression to specific-application-default function automatically
implicit def defaultExecutionUnitParameterNReturn(a: Any): Unit => MyDefaultReturn =
{u : Unit => a }.andThen(_ => defaultReturn())
However my application would fail if the user implements "a" as a function
So my first idea was something like
implicit def defaultExecutionUnitParameterNReturn[A](a: A)(implicit e : A =!= Function) Unit => MyDefaultReturn =
{u : Unit => a }.andThen(_ => defaultReturn())
where implicit =!=[A,B] fails if A and B are the same type.
But "Function" does not exists
You need to place your implicit conversions in 2 traits
trait Implicits extends ImplicitsLow {
implicit def convertFunction[T, R](f: T => R) = ???
}
trait ImplicitsLow {
implicit def convert[T](t: T) = ???
}
Then you can observe that the function conversion is used in preference to the value one:
val result1: String = (i: Int) => i + 1
val result2: String = 1
// prints (function, value)
println((result1, result2))
Investigate below code snipped. This is standard implicit convertion example. toFunnction0 takes anything and converts it into Function0[R] or just simplified () => R.
implicit def toFunnction0[R](r: => R): Function0[R] = () => r
def iWantFunction0(f0: () => String) = {
f0()
}
def testFun = {println("computing string in testFun..."); "ABC"} //every time when called block of code will run
val abcVal = "ABC" //this is computed only once
iWantFunction0(testFun)
//here abcVal is not a function, so implicit works.
//toFunnction0 is in scope, so compiler will translate it into
//iWantFunction0(toFunnction0(abcVal))
iWantFunction0(abcVal)