I'm having hard times trying to create a Scala Test to checks this function:
def curry[A,B,C](f: (A,B) => C): A => (B => C) =
a => b => f(a,b)
The first thought I had was to validate if given a function fx passed into curry(fx) function, will return a curried version of it.
Any tips?
One way to test it, is to pass different f's to it and see if you are getting back the function you expect. For example, you can test an f that returns the arguments as a tuple:
def f(x: String, y: Int) = (x, y)
curry(f)("4")(7) must be(("4", 7))
IMO, testing it for a few different functions f and for a few different a and b would be more than sufficiently assuring that something as trivial as this works as intended.
Related
I was recently reading Category Theory for Programmers and in one of the challenges, Bartosz proposed to write a function called memoize which takes a function as an argument and returns the same one with the difference that, the first time this new function is called, it stores the result of the argument and then returns this result each time it is called again.
def memoize[A, B](f: A => B): A => B = ???
The problem is, I can't think of any way to implement this function without resorting to mutability. Moreover, the implementations I have seen uses mutable data structures to accomplish the task.
My question is, is there a purely functional way of accomplishing this? Maybe without mutability or by using some functional trick?
Thanks for reading my question and for any future help. Have a nice day!
is there a purely functional way of accomplishing this?
No. Not in the narrowest sense of pure functions and using the given signature.
TLDR: Use mutable collections, it's okay!
Impurity of g
val g = memoize(f)
// state 1
g(a)
// state 2
What would you expect to happen for the call g(a)?
If g(a) memoizes the result, an (internal) state has to change, so the state is different after the call g(a) than before.
As this could be observed from the outside, the call to g has side effects, which makes your program impure.
From the Book you referenced, 2.5 Pure and Dirty Functions:
[...] functions that
always produce the same result given the same input and
have no side effects
are called pure functions.
Is this really a side effect?
Normally, at least in Scala, internal state changes are not considered side effects.
See the definition in the Scala Book
A pure function is a function that depends only on its declared inputs and its internal algorithm to produce its output. It does not read any other values from “the outside world” — the world outside of the function’s scope — and it does not modify any values in the outside world.
The following examples of lazy computations both change their internal states, but are normally still considered purely functional as they always yield the same result and have no side effects apart from internal state:
lazy val x = 1
// state 1: x is not computed
x
// state 2: x is 1
val ll = LazyList.continually(0)
// state 1: ll = LazyList(<not computed>)
ll(0)
// state 2: ll = LazyList(0, <not computed>)
In your case, the equivalent would be something using a private, mutable Map (as the implementations you may have found) like:
def memoize[A, B](f: A => B): A => B = {
val cache = mutable.Map.empty[A, B]
(a: A) => cache.getOrElseUpdate(a, f(a))
}
Note that the cache is not public.
So, for a pure function f and without looking at memory consumption, timings, reflection or other evil stuff, you won't be able to tell from the outside whether f was called twice or g cached the result of f.
In this sense, side effects are only things like printing output, writing to public variables, files etc.
Thus, this implementation is considered pure (at least in Scala).
Avoiding mutable collections
If you really want to avoid var and mutable collections, you need to change the signature of your memoize method.
This is, because if g cannot change internal state, it won't be able to memoize anything new after it was initialized.
An (inefficient but simple) example would be
def memoizeOneValue[A, B](f: A => B)(a: A): (B, A => B) = {
val b = f(a)
val g = (v: A) => if (v == a) b else f(v)
(b, g)
}
val (b1, g) = memoizeOneValue(f, a1)
val (b2, h) = memoizeOneValue(g, a2)
// ...
The result of f(a1) would be cached in g, but nothing else. Then, you could chain this and always get a new function.
If you are interested in a faster version of that, see #esse's answer, which does the same, but more efficient (using an immutable map, so O(log(n)) instead of the linked list of functions above, O(n)).
Let's try(Note: I have change the return type of memoize to store the cached data):
import scala.language.existentials
type M[A, B] = A => T forSome { type T <: (B, A => T) }
def memoize[A, B](f: A => B): M[A, B] = {
import scala.collection.immutable
def withCache(cache: immutable.Map[A, B]): M[A, B] = a => cache.get(a) match {
case Some(b) => (b, withCache(cache))
case None =>
val b = f(a)
(b, withCache(cache + (a -> b)))
}
withCache(immutable.Map.empty)
}
def f(i: Int): Int = { print(s"Invoke f($i)"); i }
val (i0, m0) = memoize(f)(1) // f only invoked at first time
val (i1, m1) = m0(1)
val (i2, m2) = m1(1)
Yes there is pure functional ways to implement polymorphic function memoization. The topic is surprisingly deep and even summons the Yoneda Lemma, which is likely what Bartosz had in mind with this exercise.
The blog post Memoization in Haskell gives a nice introduction by simplifying the problem a bit: instead of looking at arbitrary functions it restricts the problem to functions from the integers.
The following memoize function takes a function of type Int -> a and
returns a memoized version of the same function. The trick is to turn
a function into a value because, in Haskell, functions are not
memoized but values are. memoize converts a function f :: Int -> a
into an infinite list [a] whose nth element contains the value of f n.
Thus each element of the list is evaluated when it is first accessed
and cached automatically by the Haskell runtime thanks to lazy
evaluation.
memoize :: (Int -> a) -> (Int -> a)
memoize f = (map f [0 ..] !!)
Apparently the approach can be generalised to function of arbitrary domains. The trick is to come up with a way to use the type of the domain as an index into a lazy data structure used for "storing" previous values. And this is where the Yoneda Lemma comes in and my own understanding of the topic becomes flimsy.
I tried to do research but still not yet figure out what is the terminology of Scala, related to lower case a,b as per the code below
def curry[A, B, C](f: (A, B) => C): A => (B => C) = a => b => f(a, b)
Why is that a,b appears on the right hand side?
I know that it is a part of Algebraic Data Type but still could not find a match definition for this.
Update based on Tim's answer, "Scala knows the type of a and b from the return type A => (B => C). a is type A, b is type B."
I want to ask about how Scala knows the type of a and b, i.e: the mechanism behind? What is the terminology of this?
I guess this is a language feature. Please suggest a foundation guideline to fully understand and practice to gain intuition when reading these complex code.
Update from Mario Galic's comment: ... Scala compiler can perform type inference based on the signature of curry ... Please clarify: if the left hand side (i.e the signature) is too obvious, why we need to have the right hand side definition? I mean, there is only 1 way to infer the logic of the left hand side, then, what is the need of creating the right hand side content?
P/S: I wish that I could mark each feedback as the answer because each provides different aspect which helps me to fully grasp the meaning.
It might help to add full type annotations
def curry[A, B, C](f: (A, B) => C): A => (B => C) =
(a: A) => ((b: B) => f(a, b): C)
Note how curry is a method that takes a function as input and also returns a function as output. You might be wondering where do a and b come from in the output function
(a: A) => ((b: B) => f(a, b): C)
but note that they are just the means of declaring the parameters of the output function. You are free to give them any name, for example the following would also work
(x: A) => ((y: B) => f(x, y): C)
The key is to understand that functions are first class values in Scala, so you can pass them in as arguments to other functions and return them as return values from other functions, in the same way you would do with familiar values like say integer 42. Writing value 42 is straightforward, but writing down function value is more verbose since you have to specify the parameters like a and b but nevertheless conceptually it is still just a value. Hence we could say curry is a method that takes a value and returns a value, but these values happen to be function values.
As we all know, it's pretty easy to create a tuple: (1,'a'). And the type of said tuple is pretty simple: (Int,Char). That type designation, however, is a convenient alternative for the more verbose type designation Tuple2[Int,Char]. In fact, the tuple creation itself is a convenient alternate syntax to the more direct new Tuple2(1,'a').
It's a similar story with functions.
The type designation Char => Int is a convenient alternative to the more verbose Function1[Char,Int]. And, after studying the ScalaDocs page, we learn that a simple function like...
val ctoi = (c:Char) => c.toInt
...is the equivalent of...
val ctoi = new Function1[Char, Int] {
def apply(c: Char): Int = c.toInt
}
So, armed with this information, we can now translate...
def curry[A,B,C](f: (A, B) => C): A => (B => C) =
a => b => f(a, b)
...into its equivalent...
def curry[A,B,C](f: Function2[A,B,C]): Function1[A,Function1[B,C]] =
new Function1[A,Function1[B,C]] {
def apply(a:A) = new Function1[B,C] {def apply(b:B) = f(a,b)}
}
With this it's a little easier to see how a => b => ..., while a bit confusing at first, is actually a very convenient way to designate the names of the arguments being passed in to the hidden apply() methods.
The question doesn't really make sense, but in case this helps here is a breakdown of that line:
def curry[A, B, C](f: (A, B) => C): A => (B => C) = a => b => f(a, b)
This splits into a definition and an implementation with = inbetween. The definition is
def curry[A, B, C](f: (A, B) => C): A => (B => C)
Breaking it down further, A, B, and C are type parameters, meaning that any three types can be used when calling this function.
Next comes the single argument to the function:
f: (A, B) => C
The value of this argument is a function that takes two values (one of type A and one of type B) are returns a single value of type C.
Next comes the type of the result:
A => (B => C)
This is a function that takes a single argument of type A and returns a function that takes a single argument of type B and returns a result of type C.
So curry is a function that takes a function of type (A, B) => C) and returns a function of type A => (B => C). This implements the process known as currying (hence the name).
Now for the implementation (the other side of the =):
a => b => f(a, b)
Adding some brackets might make this clearer:
a => (b => f(a, b))
This is a function that take a and returns b => f(a, b). a is the argument for this function. So that leaves this
b => f(a, b)
This is a simple function with an argument b that returns f(a, b).
Scala knows the type of a and b from the return type A => (B => C). a is type A, b is type B.
I understand how does a curried function work in practice.
def plainSum(a: Int)(b: Int) = a + b
val plusOne = plainSum(1) _
where plusOne is a curried function of type (Int) => Int, which can be applied to an Int:
plusOne(10)
res0: Int = 11
Independently, when reading the book (Chapter 2) Functional Programming in Scala, by Chiusano and Bjarnason, it demonstrated that the implementation of currying a function f of two arguments into a function of one argument can be written in the following way:
def curry[A, B, C](f: (A, B) => C): A => (B => C) =
a: A => b: B => f(a, b)
Reference: https://github.com/fpinscala/fpinscala/blob/master/answers/src/main/scala/fpinscala/gettingstarted/GettingStarted.scala#L157-L158
I can understand the above implementation, but have a hard time associating the signature with the plainSum and plusOne example.
The 1 in the plainSum(1) _ seems to correspond to the type parameter A, and the function value plusOne seems to correspond to the function signature B => C.
How does the Scala compiler apply the above curry signature when seeing the statement plainSum(1) _?
You are conflating partially applying a function with currying. In Scala, they some differences:
A partially applied function passes less arguments than provided in the application with the rest of the arguments, represented by the placeholder(_), is partially applied on the next call.
Currying is when a higher order function takes a function of N arguments and transforms it into a one-arg chains of functions.
The plusOne example is naturally curried out of the box by virtue of the multi-parameter list which takes a function of one argument successively and return the last argument.
Your mistake is that you are trying to use currying twice when this notation()() already gives you currying.
Meanwhile you can achieve same effect by currying the plainSum signature to the curry function like so:
def curry[A, B, C](f: (A, B) => C): A => (B => C) =
(a: A) => (b: B) => f(a, b)
def plainSum(a: Int, b: Int) = a + b
val curriedSum = curry(plainSum)
val add2 = curriedSum(2)
add2(3)
Both(partial application and currying) shouldn't be confused with another concept called partial functions.
Note: The red book, fpinscala, tried creating those abstraction as done in the Scala library without the syntactic sugar.
I am very very new to Scala. I am reading a book called functional programming in scala by Paul Chiusano and Rúnar Bjarnason. So far I am finding it interesting. I see a solution for curry and uncurry
def curry[A,B,C](f: (A, B) => C): A => (B => C)= {
a => b => f(a,b)
}
def uncurry[A,B,C](f: A => B => C): (A, B) => C = {
(a,b) => f(a)(b)
}
In Curry I understand f(a,b) which results in value of type C but in uncurry I do not understand f(a)(b). Can anyone please tell me how to read f(a)(b) or how is this resulting to a type of C or please refer me some online material that can explain this to me?
Thanks for your help.
Basically the return type of f(a) is a function of type B => C lets call this result g.
If you then call g(b) you obtain a value of type C.
f(a)(b) can be expanded to f.apply(a).apply(b)
In the uncurry method you take a so-called "curried" function, meaning that instead of having a function that evaluates n arguments, you have n functions evaluating one argument, each returning a new function until you evaluate the final one.
Currying without a specific support from the language mean you have to do something like this:
// curriedSum is a function that takes an integer,
// which returns a function that takes an integer
// and returns the sum of the two
def curriedSum(a: Int): Int => Int =
b => a + b
Scala however provides further support for currying, allowing you to write this:
def curriedSum(a: Int)(b: Int): Int = a + b
In both cases, you can partially apply curriedSum, getting a function that takes an integer and sums it to the number you passed in originally, like this:
val sumTwo: Int => Int = curriedSum(2)
val four = sumTwo(2) // four equals 4
Let's go back to your case: as we mentioned, uncurry takes a curried function and turns it into a regular function, meaning that
f(a)(b)
can read as: "apply parameter a to the function f, then take the resulting function and apply the parameter b to it".
In case if somebody is looking for an explanation. This link explains it better
def add(x:Int, y:Int) = x + y
add(1, 2) // 3
add(7, 3) // 10
After currying
def add(x:Int) = (y:Int) => x + y
add(1)(2) // 3
add(7)(3) // 10
In the first sample, the add method takes two parameters and returns the result of adding the two. The second sample redefines the add method so that it takes only a single Int as a parameter and returns a functional (closure) as a result. Our driver code then calls this functional, passing the second “parameter”. This functional computes the value and returns the final result.
Whilst I understand what a partially applied/curried function is, I still don't fully understand why I would use such a function vs simply overloading a function. I.e. given:
def add(a: Int, b: Int): Int = a + b
val addV = (a: Int, b: Int) => a + b
What is the practical difference between
def addOne(b: Int): Int = add(1, b)
and
def addOnePA = add(1, _:Int)
// or currying
val addOneC = addV.curried(1)
Please note I am NOT asking about currying vs partially applied functions as this has been asked before and I have read the answers. I am asking about currying/partially applied functions VS overloaded functions
The difference in your example is that overloaded function will have hardcoded value 1 for the first argument to add, i.e. set at compile time, while partially applied or curried functions are meant to capture their arguments dynamically, i.e. at run time. Otherwise, in your particular example, because you are hardcoding 1 in both cases it's pretty much the same thing.
You would use partially applied/curried function when you pass it through different contexts, and it captures/fills-in arguments dynamically until it's completely ready to be evaluated. In FP this is important because many times you don't pass values, but rather pass functions around. It allows for higher composability and code reusability.
There's a couple reasons why you might prefer partially applied functions. The most obvious and perhaps superficial one is that you don't have to write out intermediate functions such as addOnePA.
List(1, 2, 3, 4) map (_ + 3) // List(4, 5, 6, 7)
is nicer than
def add3(x: Int): Int = x + 3
List(1, 2, 3, 4) map add3
Even the anonymous function approach (that the underscore ends up expanding out to by the compiler) feels a tiny bit clunky in comparison.
List(1, 2, 3, 4) map (x => x + 3)
Less superficially, partial application comes in handy when you're truly passing around functions as first-class values.
val fs = List[(Int, Int) => Int](_ + _, _ * _, _ / _)
val on3 = fs map (f => f(_, 3)) // partial application
val allTogether = on3.foldLeft{identity[Int] _}{_ compose _}
allTogether(6) // (6 / 3) * 3 + 3 = 9
Imagine if I hadn't told you what the functions in fs were. The trick of coming up with named function equivalents instead of partial application becomes harder to use.
As for currying, currying functions often lets you naturally express transformations of functions that produce other functions (rather than a higher order function that simply produces a non-function value at the end) which might otherwise be less clear.
For example,
def integrate(f: Double => Double, delta: Double = 0.01)(x: Double): Double = {
val domain = Range.Double(0.0, x, delta)
domain.foldLeft(0.0){case (acc, a) => delta * f(a) + acc
}
can be thought of and used in the way that you actually learned integration in calculus, namely as a transformation of a function that produces another function.
def square(x: Double): Double = x * x
// Ignoring issues of numerical stability for the moment...
// The underscore is really just a wart that Scala requires to bind it to a val
val cubic = integrate(square) _
val quartic = integrate(cubic) _
val quintic = integrate(quartic) _
// Not *utterly* horrible for a two line numerical integration function
cubic(1) // 0.32835000000000014
quartic(1) // 0.0800415
quintic(1) // 0.015449626499999999
Currying also alleviates a few of the problems around fixed function arity.
implicit class LiftedApply[A, B](fOpt: Option[A => B]){
def ap(xOpt: Option[A]): Option[B] = for {
f <- fOpt
x <- xOpt
} yield f(x)
}
def not(x: Boolean): Boolean = !x
def and(x: Boolean)(y: Boolean): Boolean = x && y
def and3(x: Boolean)(y: Boolean)(z: Boolean): Boolean = x && y && z
Some(not _) ap Some(false) // true
Some(and _) ap Some(true) ap Some(true) // true
Some(and3 _) ap Some(true) ap Some(true) ap Some(true) // true
By having curried functions, we've been able to "lift" a function to work on Option for as many arguments as we need. If our logic functions had not been curried, then we would have had to have separate functions to lift A => B to Option[A] => Option[B], (A, B) => C to (Option[A], Option[B]) => Option[C], (A, B, C) => D to (Option[A], Option[B], Option[C]) => Option[D] and so on for all the arities we cared about.
Currying also has some other miscellaneous benefits when it comes to type inference and is required if you have both implicit and non-implicit arguments for a method.
Finally, the answers to this question list out some more times you might want currying.