Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 6 years ago.
Improve this question
I am newbie to Scala. I have a method just as below :
def process(func: Context => T) = {
val context = getContext() // This method provides me the context
func(context)
}
Now if I want to call this method. I have two helper methods
def runContext1(context: Context): String = {
"hello world"
}
def runContext2(): (Context) => String = {
context => "hello world"
}
def test1() = {
process(context => {
"hello world"
})
}
def test2() = {
process(runContext1)
}
def test3() = {
process(runContext2())
}
test2() does not work and throws a NullPointerException whereas test3() works.
Differences between test1(), test2() and test3() // As per my understanding test1() uses closure with anonymous functions. test2() and test3() are closures with named functions. Correct me if I am wrong and tell me if there are other differences
I want to know why test3() works and test2() does not.
What is the contract of runContext2()? I do not understand runContext2(): (Context) => String.
Your problem is somewhere in the implementation of test2 method. All of the code you posted should work (except for the fact that test1() is missing a closing parenthesis, but that's a typo).
Regarding your first question, yes, you are right in sense that those are closures because they "close over" definitions of process, runContext1 and runContext2. Whenever a method uses something defined outside of its scope, that's a closure. If that value changes on the outside, method will see that change. Further reading: link. And yes, test1 uses an anonymous function, while test2 and test3 use named ones.
Now, about your third question. The thing is, runContext2() is a method taking nothing and returning a function. Returned function takes a context and returns a string. It could have been a val too (in that case you would of course need to omit the empty parenthesis since vals don't take arguments):
val runContextVal: (Context) => String = {
context => "hello world"
}
Note that your method process() takes a function, so in fact our runContextVal would be the only one actually obeying the contract when passed to process method:
process(runContextVal)
All other invocations of process() have a method passed to it (defined using keyword def) instead of a function. This is not something compiler would allow per se. However, it's smart enough to perform something called eta expansion which is basically a simple transformation of a parameterless method into a function. Key idea is fairly simple - every value, e.g. 42 or "foo", can be thought of as a function which takes nothing and returns that value, e.g. () => 42. Furthermore, a function that takes a parameter (such as val f = (x: Int) => Int) can be thought of as a function that takes a parameter and returns your function applied to that parameter (e.g. (x: Int) => f(x)). Function for squaring numbers (let's call it sqr()) is the same as a function n => sqr(n), isn't it? Check out some other online materials for extra details (e.g. here, here or here).
Note however that if you wanted to create a function value from your runContext1 method, you would run into trouble:
val fun2 = runContext2 // works
val fun1 = runContext1 // ERROR!
If a method is parameterless or has an empty parameter (not the same thing), then eta-expansion is performed automatically. However, if it has one or more actual parameters (like runContext1 has Context) then we need to give the compiler a hand. We either need to explicitly state the value type:
val fun1: Context => String = runContext1
or make a partially applied function:
val fun1 = runContext1 _
If this is all new to you, don't be overwhelmed. Just write methods like you normally would (e.g. how runContext1 is written) and use eta expansion only when (if?) you need it.
Related
I started learning Scala only a day ago, now I'm testing a few random codes to see how it behaves. I find it a quite interesting programming language, especially for its SCALAbility.
Any way, while trying some code, I "accidentally" ran this:
var myVal = println("test")
println(myVal)
and I was surprised that it runs successfully without any errors, and the output was simply:
test
()
so I tried to find out what data type was given to this variable
println(myVal.getClass)
and it was
void
What I understood is that, as we all know, the println() method returns void which is logically nothing and cannot be assigned, but I guess it's possible in Scala to do so (even though there is no type for variables called void).
So, if I suppose this is possible, I must have nothing into my variable, it must be empty, because it is void, why do I have () as output? and what will be the type myVal?
println("test") is an expression in Scala just like any other expression which means it evaluates to a value of particular type. println("test") returns a value () of type Unit. The value () might look a bit unusual initially, but it is nevertheless just a regular value. Consider the following
val x: Int = 42
val u: Unit = ()
The type Unit does not carry much semantic value. It tells us a side-effect was executed, but does not pin down exactly what kind of side-effect it was. Imagine compiler desugars definition of
def println(x: Any): Unit = Console.println(x)
to something like
def println(x: Any): Unit = {
Console.println(x) // execute side-effect
return () // return value
}
Note the return ().
In this comment, #Ben suggested that call by name is equivalent to call by value where values are zero-argument functions. If I understood correctly,
def callByName(x: => Int) = {
// some code
}
callByName(something())
is equivalent to
def callByValue(x: () => Int) = {
// same code as above, but all occurrences of x replaced with x()
}
callByValue(()=>something())
(Edit: I fixed mistake in signature as pointed out by #MichaelZajac, #LukaJacobowitz: originally, it said callByValue(x: Int).)
In other words, the whole "call by name" concept is just syntactic sugar: everything it does can be achieved (with a few extra keystrokes) using "call by value". If true, it makes it very easy to understand call by name; in fact, I've used this technique in python (python has first-class functions).
However, further down in the comments, the discussion became somewhat more confusing, and I was left with the feeling that it's not quite so simple.
So is there something more substantive to "call by name"? Or is it just an automatic creation of zero-argument functions by the compiler?
I'm assuming you meant your callByValue function to take a () => Int instead of just an Int as otherwise it wouldn't make a lot of sense.
It's pretty much exactly what you think. The compiler generates a Function0 instance. You can see this pretty nicely when you decompile Scala code with Javap.
Another thing of note is, that the generated Function0 will be reevaluated every time you use the by-name parameter inside your function, so if you only want it to be computed once you'll want to do something like this:
def callByName(x: => Int) = {
val a = x
// do something with a here
}
Here is some more information on the whole concept.
Also you can see how Scala compiles by-name parameters quite neatly in this question:
def getX[T <: X](constr: ⇒ T): Unit = {
constr
}
decompiled in Java is equivalent to:
public <T extends X> void getX(Function0<T> constr) {
constr.apply();
}
Yes, but your example isn't quite right. The signature of callByValue, as written in your question, will evaluate x before callByValue is invoked.
The following would be roughly equivalent to a call-by-name:
def callByValue(x: () => Int) = {
// same code as above, but all occurrences of x replaced with x()
}
The distinction is important, because your version of callByValue would only accept Ints, not functions that return Ints. It also wouldn't compile if you followed the procedure of replacing x with x().
But yes, a call-by-name parameter of => A is roughly equivalent to () => A, except that the former is simply more convenient to use. I say roughly because they are different types, and their applications are slightly different. You can specify () => A to be the type of something, but not => A. And of course with x: () => A, you must manually call x() instead of x.
I ran across a function that looks like this:
def doSomethingQuestionable(config: someConfig, value: String)(default: => String) : String
What is interesting is the parameterless function that gets passed in as second argument group. In the code base, the method is only ever called with a config and two strings, the latter being some default value, but as a String, not a function. Within the code body of the method, default is passed on to a method that takes 3 string arguments. So the function "default" only resolves down to a string within the body of this method.
Is there any benefit, apart from a currying usage which does not happen with this method in the code base I am going through, of defining the method this way? Why not just define it with 3 string arguments in a single argument group?
What am I missing? Some compiler advantage here? Keep in mind, I am assuming that no currying will ever be done with this, since it is a large code base, and it is not currently done with this method.
The point is to have a potentially expensive default string that is only created when you need it. You write the code as if you're creating the string to pass in, but because it's a by-name parameter ('=> String') it will actually be turned into a function that will be transparently called whenever default is referenced in the doSomethingQuestionable method.
The reason to keep it separate is in case you do want a big block of code to create that string. If you never do and never will, it may as well be
def doSomethingQuestionable(config: someConfig, value: String, default: => String): String
If you do, however,
def doSomethingQuestionable(cfg, v){
// Oh boy, something went wrong
// First we need to check if we have a database accessible
...
// (Much pain ensues)
result
}
is way better than embedding the code block as one argument in a multi-argument parameter list.
This is a parameterless function returning a String:
() => String
Which is not what you have. This,
=> <WHATEVER>
is a parameter being passed by-name instead of by-value. For example:
=> String // A string being passed by-name
=> () => String // A parameterless function returning string being passed by-name
The difference between these modes is that, on by-value, the parameter is evaluated and the resulting value is passed, whereas on by-name, the parameter is passed "as is", and evaluated each time it is used.
For example:
var x = 0
def printValue(y: Int) = println(s"I got $y. Repeating: $y.")
def printName(y: => Int) = println(s"I got $y. Repeating: $y.")
printValue { x += 1; x } // I got 1. Repeating: 1.
printName { x += 1; x } // I got 2. Repeating: 3.
Now, as to why the method splits that into a second parameter, it's just a matter of syntactic pleasantness. Take the method foldLeft, for example, which is similarly defined. You can write something like this:
(1 to 10).foldLeft(0) { (acc, x) =>
println(s"Accumulator: $acc\tx: $x\tacc+x: ${acc+x}")
acc+x
}
If foldLeft was defined as a single parameter list, it would look like this:
(1 to 10).foldLeft(0, { (acc, x) =>
println(s"Accumulator: $acc\tx: $x\tacc+x: ${acc+x}")
acc+x
})
Not much different, granted, but worse looking. I mean, you don't write this thing below, do you?
if (x == y, {
println("Same thing")
}, {
println("Different thing"
})
I am new to Scala, and am learning it by going over some Play code. I have had a good read of the major concepts of Scala and am comfortable with functional programming having done some Haskell and ML.
I am really struggling to read this code, at the level of the syntax and the programming paradigms alone. I understand what the code is supposed to do, but not how it does it because I can't figure out the syntax.
// -- Home page
def index(ref: Option[String]): Action[AnyContent] = Prismic.action(ref) { implicit request =>
for {
someDocuments <- ctx.api.forms("everything").ref(ctx.ref).submit()
} yield {
Ok(views.html.index(someDocuments))
}
}
(Prismic is an API separate to Play and is not really that relevant). How would I describe this function (or is it a method??) to another developer over the phone: in other words, using English. For example in this code:
def add(a: Int, b: Int): Int = a + b
I would say "add is a function which takes two integers, adds them together and returns the result as another integer".
In the Play code above I don't even know how to describe it after getting to "index is a function which takes an Option of a String and returns an Action of type AnyContent by ....."
The bit after the '=' and then the curly braces and the '=>' scare me! How do I read them? And is the functional or OO?
Thanks for your assistance
Let's reduce it to this:
def index(ref: Option[String]): Action[AnyContent] = Prismic.action(ref)(function)
That's better, isn't it? index is a function from Option of String to Action of AnyContent (one word), which calls the action method of the object Prismic passing two curried parameters: ref, the parameter that index received, and a function (to be described).
So let's break down the anonymous function:
{ implicit request =>
for {
someDocuments <- ctx.api.forms("everything").ref(ctx.ref).submit()
} yield {
Ok(views.html.index(someDocuments))
}
}
First, it uses {} instead of () because Scala allows one to drop () as parameter delimiter if it's a single parameter (there are two parameter lists, but each has a single parameter), and that parameter is enclosed in {}.
So, what about {}? Well, it's an expression that contains declarations and statements, with semi-colon inference on new lines, whose value is that of the last statement. That is, the value of these two expressions is the same, 3:
{ 1; 2; 3 }
{
1
2
3
}
It's a syntactic convention to use {} when passing a function that extends for more than one line, even if, as in this case, that function could have been passed with just parenthesis.
The next thing confusing is the implicit request =>, Let's pick something simpler:
x => x * 2
That's pretty easy, right? It takes one parameter, x, and returns x * 2. In our case, it is the same thing: the function takes one parameter, request, and returns this:
for (someDocuments <- somethingSomething())
yield Ok(views.html.index(someDocuments))
That is, it calls some methods, iterate over the result, and map those results into a new value. This is a close equivalent to Haskell's do notation. You can rewrite it like below (I'm breaking it down into multiple lines for readability):
ctx
.api
.forms("everything")
.ref(ctx.ref)
.submit()
.map(someDocuments => Ok(views.html.index(someDocuments)))
So, back to our method definition, we have this:
def index(ref: Option[String]): Action[AnyContent] = Prismic.action(ref)(
implicit request =>
ctx
.api
.forms("everything")
.ref(ctx.ref)
.submit()
.map(someDocuments => Ok(views.html.index(someDocuments)))
)
The only remaining question here is what that implicit is about. Basically, it makes that parameter implicitly available through the scope of the function. Presumably, at least one of these method calls require an implicit parameter which is properly fielded by request. I could drop the implicit there an pass request explicitly, if I knew which of these methods require it, but since I don't, I'm skipping that.
An alternate way of writing it would be:
def index(ref: Option[String]): Action[AnyContent] = Prismic.action(ref)({
request =>
implicit val req = request
ctx
.api
.forms("everything")
.ref(ctx.ref)
.submit()
.map(someDocuments => Ok(views.html.index(someDocuments)))
})
Here I added {} back because I added a declaration to the body of the function, though I decided not to drop the parenthesis, which I could have.
Something like this:
index is a function which takes an Option of a String and returns an Action of type AnyContent. It calls the method action that takes as a first argument an Option and as a second argument a method that assumes an implicit value request of type Request is in scope. This method uses a For-comprehension that calls the submit method which returns an Option or a Future and then in case its execution is successful, it yields the result Ok(...) that will be wrapped in the Action returned by the action method of Prismic.
Prismic.action is a method that takes 2 groups of arguments (a.k.a. currying).
The first is ref
The second is { implicit request => ...}, a function defined in a block of a code
more information on Action
I've read a lot of code snippets in scala that make use of the symbol =>, but I've never really been able to comprehend it. I've tried to search in the internet, but couldn't find anything comprehensive. Any pointers/explanation about how the symbol is/can be used will be really helpful.
(More specifially, I also want to know how the operator comes into picture in function literals)
More than passing values/names, => is used to define a function literal, which is an alternate syntax used to define a function.
Example time. Let's say you have a function that takes in another function. The collections are full of them, but we'll pick filter. filter, when used on a collection (like a List), will take out any element that causes the function you provide to return false.
val people = List("Bill Nye", "Mister Rogers", "Mohandas Karamchand Gandhi", "Jesus", "Superman", "The newspaper guy")
// Let's only grab people who have short names (less than 10 characters)
val shortNamedPeople = people.filter(<a function>)
We could pass in an actual function from somewhere else (def isShortName(name: String): Boolean, perhaps), but it would be nicer to just place it right there. Alas, we can, with function literals.
val shortNamedPeople = people.filter( name => name.length < 10 )
What we did here is create a function that takes in a String (since people is of type List[String]), and returns a Boolean. Pretty cool, right?
This syntax is used in many contexts. Let's say you want to write a function that takes in another function. This other function should take in a String, and return an Int.
def myFunction(f: String => Int): Int = {
val myString = "Hello!"
f(myString)
}
// And let's use it. First way:
def anotherFunction(a: String): Int = {
a.length
}
myFunction(anotherFunction)
// Second way:
myFunction((a: String) => a.length)
That's what function literals are. Going back to by-name and by-value, there's a trick where you can force a parameter to not be evaluated until you want to. The classic example:
def logger(message: String) = {
if(loggingActivated) println(message)
}
This looks alright, but message is actually evaluated when logger is called. What if message takes a while to evaluate? For example, logger(veryLongProcess()), where veryLongProcess() returns a String. Whoops? Not really. We can use our knowledge about function literals to force veryLongProcess() not to be called until it is actually needed.
def logger(message: => String) = {
if(loggingActivated) println(message)
}
logger(veryLongProcess()) // Fixed!
logger is now taking in a function that takes no parameters (hence the naked => on the left side). You can still use it as before, but now, message is only evaluated when it's used (in the println).