I've been working on learning the ins and outs of scala, and recently I've come across something I'm curious about.
As I understand, if I want to pass a block of code that is effectively lazily evaluated to a function, (without evaluating it on the spot) I could type:
def run(a: =>Int):Int = {...}
In this sense, the function run receives a block of code, that is yet to be evaluated, which it evaluates and returns the computed Int of. I then tried to extend this idea to the List data structure. Typing:
def run(a: List[=>Int]) = {...}
This however, returns an error. I was wondering why this is disallowed. How, other than by this syntax can I pass a list of unevaluated blocks of code?
=>Int is the syntax for by name parameters. =>Int is not a type, so it can't be used as a parameter to List. However, ()=>Int is a type. It's the type of nullary functions that return Int. So this works:
def run(a: List[()=>Int]) = {...}
by-name parameter is not a first-class type in Scala.
List[()=>Int] is one of the solution. otherwise, You can use following Lazy data structure.
https://gist.github.com/1164885
https://github.com/scalaz/scalaz/blob/v6.0.4/core/src/main/scala/scalaz/Name.scala#L99-107
https://github.com/scalaz/scalaz/blob/v7.0.0-M7/core/src/main/scala/scalaz/Name.scala#L37-L60
https://github.com/scala/scala/blob/v2.10.0/src/reflect/scala/reflect/internal/transform/Transforms.scala#L9-23
https://github.com/harrah/xsbt/blob/v0.12.1/compile/api/SafeLazy.scala
https://github.com/okomok/ken/blob/0.1.0/src/main/scala/com/github/okomok/ken/Lazy.scala
https://github.com/playframework/Play20/blob/2.1-RC1/framework/src/play/src/main/scala/play/api/libs/functional/Util.scala#L3-L11
Related
I'm new to Scala. I am writing a method which sends a request of type RQ to a server, and receives a response of type Response[RSP]. The simplified version: I define a method to make a call:
def invoke[RQ, RSP](request: RQ): Response[RSP] = {....}
When I invoke the method, all parameters can be inferred if I specify the type of the receiving variable, like this:
val result: Response[Double] = invoke("Hello")
But if I just say invoke("Hello") without assigning it to anything, it won't compile. I have to supply the 2 generic types (e.g invoke[String, Double]("Hello") ). My question is: The String can be inferred from the parameter. Is there a way to write the call specifying only the RSP generic? Something in the lines of : invoke[ , Double]("Hello") ?
No.
This is a feature that has been asked about a number of times. Future versions of Scala may support a syntax similar to named arguments for methods:
invoke[RSP = Double]("Hello")
At the moment, there is nothing much you can do except restructure your code so that the method has only one type parameter, and the second comes from the surrounding context.
The more interesting question is: why do you even care about the return type if you just throw away the result anyway? It looks like your method violates the Command-Query Separation Principle. If your method simply returned Unit, you wouldn't need the second type parameter, and all would work fine. If you actually used the return value, the type inferencer would at least have a chance to infer the second type parameter from the context. But the fact that you have a type parameter for the return value but ignore the return value means that there is no context for the type inferencer to look at.
More explicitly, can this code produce any errors in any scenrios:
def foreach[U](f :Int=>U) = f.asInstanceOf[Int=>Unit](1)
I know it works, and I have a vague idea why: any function, as an instance of a generic type, must define an erased version of apply and jvm performs type check only when the object is actually to be returned to a code where it had a concrete type (often miles away). So, in theory, as long as I never look at the returned value, I should be safe. I don't have an enough low-level understandings of java byte code, let alone scalac, to have any certainty about it.
Why would I want to do it? Look at the following example:
val b = new mutable.Buffer[Int]
val ints = Seq(1, 2, 3, 4)
ints foreach { b += _ }
It's a typical scala construct, as far as imperative style can be typical. foreach in this example takes an Int as an argument, and as scalac knows it to be an Int, it will create a closure with a specialized apply(x :Int). Unfortunately, its return type in this case is a mutable.Buffer[Int], which is an AnyRef. As far as I was able to see, scalac will never invoke a specialized apply providing an AnyVal argument if the result is an AnyRef (and vice versa). This means, that even if the caller applies the function to Int, underneath the function will box the argument and invoke the erased variant. Here of course it doesn't matter as they are boxed within the List anyway, but I'm talking about the principle.
For this reason I prefer to define this type of method as foreach(f :X=>Unit), rather than foreach[O](f: X=>O) as it is in TraversableOnce. If the input sequence in the example had such a signature, everything would compile just as fine, and the compiler would ignore the actual type of the expression and generate a function with Unit return type, which - when applied to an unboxed Int - would invoke directly void apply(Int x), without boxing.
The problem arises with interoperability - sometimes I need to call a method expecting a function with a Unit return type and all I have is a generic function returning Odin knows what. Of course, I could just write f(_) to box it in another function object instead of passing it directly, but it to large extent makes the whole optimisation of small tight loops moot.
I am nearly completely new to Scala, a few months on. I noticed some wild signatures. I have worked through generics with contrapositive/copositive/extensions/invariance, and most of the basics. However, I continue to find some of the method signatures a bit confusing. While I find examples and know what the signatures produce, I am still a bit at a loss as to some of the functionality. Googling my questions has left me with no answers. I do have the general idea that people like to beat the basic CS 1 stuff to death. I have even tried to find answers on the scala website. Perhaps I am phrasing things like "expanded method signature" and "defining function use in scala signature" wrong. Can anyone explain this signature?
futureUsing[I <: Closeable, R](resource: I)(f: I => Future[R])(implicit ec: ExecutionContext):Future[R]
My guess is that after the initial generics and parameter declaration with a parameter of type I, the body is defined and the final portion is any objects specific to the function or that must be looked up in an implicit scope (are they destroyed afterwards?). Can anyone layout an expanded method signature so I know what code I am using? Is there a particular order the last two parts must be in?
Note
After a bunch more searching, I found a few valid responses I can throw together:
-Scala - Currying and default arguments
-why in Scala a function type needs to be passed in separate group of arguments into a function
There is no set ordering just that implicits must be last. Placement is about dependency which flows left to right as someone down the list in one of the above answers pointed out. Why I cannot have implicits first and everything depending on them afterwards is odd since having nothing available causes an error and things will likely depend on a given implicit.
However, I am still a bit confused. When specifying f: I => Future[R], and needing to supply the last argument, lets pretend it would be any implicit, would I need to do something more like:
futureUsing(resourceOfI)({stuff => doStuff(stuff)})(myImplicit)
Is this even correct?
Could I do:
futureUsing(resourceOfI)(myImplicit)({stuff => doStuff(stuff)})
Why? I am really trying to get at the underlying reasons rather than just a binary yes or no.
Final Note
I just found this answer. It appears the order cannot be changed. Please correct me if I am wrong.
Scala: Preference among overloaded methods with implicits, currying and defaults
Can anyone explain this signature?
futureUsing[I <: Closeable, R]
futureUsing works with two separate types (two type parameters). We don't know exactly what types they are, but we'll call one I (input), which is a (or derived from) Closable, and the other R (result).
(resourse: I)
The 1st curried argument to futureUsing is of type I. We'll call it resourse.
(f: I => Future[R])
The 2nd curried argument, f, is a function that takes an argument of type I and returns a Future that will (eventually) contain something of type R.
(implicit ec: ExecutionContext)
The 3rd curried argument, ec, is of type ExecutionContext. This argument is implicit, meaning if it isn't supplied when futureUsing is invoked, the compiler will look for an ExecutionContext in scope that has been declared implicit and it will pull that in as the 3rd argument.
:Future[R]
futureUsing returns a Future that contains the result of type R.
Is there a specific ordering to this?
Implicit parameters are required to be the last (right most) parameters. Other than that, no, resourse and f could have been declared in either order. When invoked, of course, the order of arguments must match the order as declared in the definition.
Do I need ... implicits to drag in?
In the case of ExecutionContext let the compiler use what's available from import scala.concurrent.ExecutionContext. Only on rare occasions would you need something different.
...how would Scala use the 2nd curried argument...
In the body of futureUsing I would expect to see f(resourse). f takes an argument of type I. resourse is of type I. f returns Future[R] and so does futureUsing so the line f(resourse) might be the last statement in the body of futureUsing.
I am doing the Scala Coursera course, and lectures seem to be missing an explanation of how multiple parameter lists really work.
He makes claims like the averageDamp() function below could be called with just the first argument (f), allowing you to call it with the second later. It seems though that you need to do partial binding explicitly by following the call with "_".
However, if the partial binding call is being passed into another function that accepts a function with a signature matching the partially bound function, it will implicitly accept it, no "_" necessary.
Yet he doesn't use the term partial binding at all, just saying there is a special syntax in Scala for basically returning a closure, when in reality it is just partial binding. Or not?
scala> def averageDamp(f: Double => Double)(x: Double) = (x+f(x))/2
scala> def fixedPoint(f: Double => Double)(x: Int) = f(x)+1
scala> fixedPoint(averageDamp(x=>x+1))(2)
res29: Double = 3.5
scala> averageDamp(x=>x+1)
<console>:19: error: missing arguments for method averageDamp;
follow this method with `_' if you want to treat it as a partially applied function
averageDamp(x=>x+1)
A non-partial binding version of averageDamp might be like:
def averageDamp(f: Double => Double): (Double => Double) =
def inner(x: Double): Double =
(x+f(x))/2
inner
I guess my question is...is the multi-parameter list version of averageDamp() being passed into another function just implicit partial binding...or is this really some kind of special Scala syntax for returning an inner function/closure?
Yet he doesn't use the term partial binding at all, just saying there is a special syntax in Scala for basically returning a closure, when in reality it is just partial binding... is the multi-parameter list version of averageDamp() being passed into another function just implicit partial binding...or is this really some kind of special Scala syntax for returning an inner function/closure?
Why do you think it's one or the other? Supplying only some of parameter lists is a special syntax for partial application (not "binding", usually) of methods with multiple parameter lists.
I am trying to understand database connections in Scala using the default Anorm library in play framework. Play has a sample example "Computer Database" where one of the functions tries to retrieve a computer from the DB:
DB.withConnection { implicit connection =>
SQL("select * from computer where id = {id}").on('id -> id).as(Computer.simple.singleOpt)
}
If I look at the function signature of withConnection it is this:
def withConnection [A] (block: (Connection) ⇒ A)(implicit app: Application): A
Execute a block of code, providing a JDBC connection. The connection and all created statements are automatically released.
**block** Code block to execute.
My question is how to map each value of function call to function definition? For example what is A (is it the whole SQL query, but what does the return type mean then?). What the implicit app in this case? Where is it defined?
admittedly this example is confusing, since it combines several language features
type parameters (generics)
currying (=two argument lists)
anonymous inline function (function block)
implicit arguments (which are picked up from the context)
As always, when matters start to become complicated, lets' sort it out one by one
(1) A is a type parameter. This is replaced by a suitable type on each invocation of the function. Since A is mentioned at two locations in the argument list and in the return type, this means that whatever type you use, the result type of the passed-in function block will be the same than the overall return type. You could explicitly define A when using the function, but typically you can leave it out, since the compiler can infer the actual type used.
(2) currying is easy to understand. This function here just has two parameter lists. Which means you can apply this function in several steps. First apply the left parameter list:
def myBlock(connection:Connection):SQL =
SQL("select ......" .....
val pf = DB.withConnection(myBlock)
Question: what kind of Object is pf ? what is ists type?
Answer: it is a function, taking one argument, an Application object
Thus the type of pf would be Application => SQL since in the first, partial application of the function, we just passed in another function with return type SQL, thus type parameter A is inferred to be SQL
(3) but in the code above, we've defined the function myBlock in a conventional fashion, and we gave it explicitly the name "myBlock". This isn't necessary. We can define the same function just inline, using the block syntax.
(4) and now the confusing, "magic" part, the implicits. This is a very special feature of Scala, where the compiler allows you to omit some values, or arguments (in our case). You may not omit arbitrary arguments, but only arguments marked as implicit. When you do so, the compiler doesn't immediately generate an error; rather it looks in the current scope, if he can find some suitable other object with the same name.
Effectively this means, that in your example, there must somehow be an value "connection" of type Connection, and there must be a value "application" of type Application. Both values must be visible somehow in the current scope -- that is, either as parameter, as value in an enclosing scope, or as value in the companion object, or you might have brought them into scope explicitly with an import statement. The purpose of this language feature is just to save you typing those obvious arguments (application and connection9 again and again