I have several generic functions with the same signature:
def f1[A, B](v: A, f: (A, B) => B): B = ...
def f2[A, B](v: A, f: (A, B) => B): B = ...
And I need to define a function g that can accept any of these functions (f1 f2):
def g(f: ????) = ...
g internally uses multiple argument types, so I can not parameterize it like that:
def g[A, B](f: (A, (A, B) => B) => B) = ...
There isn't really a much better way to do it in Scala 2. Although your solution is a bit strange because FunctionHolder's apply method will return a function object and doesn't accept any arguments itself – that's a bit more complicated than it needs to be. So you can do this instead:
trait FunctionHolder {
def apply[A, B](v: A, f: (A, B) => B): B
}
def g(f: FunctionHolder) = …
But this isn't really all that much better.
In Scala 3, there are polymorphic function types to do this in a cleaner way:
def g(f: [A, B] => (A, (A, B) => B) => B) = …
That said, I'm not convinced that that type signature is really what you want. Remember, when you define a function with type parameters, it needs to work for all possible type parameters that the user might supply. This can't be done for this signature…
def f1[A, B](v: A, f: (A, B) => B): B
… because when I have a function like that, I can easily write an expression of type Nothing:
f1[Unit, Nothing]((), (a: Unit, b: Nothing) => b)
and it's not possible to write an expression of type Nothing unless you cheat (e. g. throw an exception or enter an infinite loop or something like that). So the type signature tells me you're cheating 😉
If you want to know more about this kind of reasoning, search for “Theorems for free!”
After wandering a bit, come up with following:
g(new FunctionHolder {
def apply[A, B](): (A, (A, B) => B) => B = f1
})
def g(f: FunctionHolder) = f()(..., (a, b) => ...)
abstract class FunctionHolder {
def apply[A, B](): (A, (A, B) => B) => B
}
But that just does not look right.
Hope there are more concise ways to do that
Related
Is there a standard way to complete a partial function PartialFunction[A, B]? Something like this:
completePartialFunction(pf: PartialFunction[A, B], z: B): A => B
or
completePartialFunction2(pf: PartialFunction[A, B], f: A => B): A => B
Yes, it's actually very simple:
def complete[A, B](pf: PartialFunction[A, B])(f: A => B): A => B =
pf.applyOrElse(_, f)
You can use lift method on PartialFunction, that returns Option[B]. So when the function is not defined for the input, None is returned. You can find more in the scaladocs.
Other solution that comes to my mind is when you're using cats or scalaz. You can then check whether the function is defined for the argument and when not, return empty from the Monoid[B] that you should pass (probably implicitly) to completePartialFunction.
If I understand the question, you want to use f() to supplement pf() so that all possible values of type A are covered.
def completePartialFunction2[A,B](pf : PartialFunction[A,B]
,f : A => B): A => B =
(a:A) => if (pf.isDefinedAt(a)) pf(a) else f(a)
Another simple version:
def completePartialFunction[A, B](pf: PartialFunction[A, B], f: A => B): A => B
= pf orElse { case a: A => f(a) }
I am having problems understanding this code from the Book FP in Scala. Here is the code:
trait Monoid[A] {
def op(a1: A, a2: A): A
def zero: A
}
def endoMonoid[A]: Monoid[A => A] = new Monoid[A => A] {
def op(f: A => A, g: A => A) = f compose g
val zero = (a: A) => a
}
def foldMap[A, B](as: List[A], m: Monoid[B])(f: A => B): B =
as.foldLeft(m.zero)((b, a) => m.op(b, f(a)))
// The function type `(A, B) => B`, when curried, is `A => (B => B)`.
// And of course, `B => B` is a monoid for any `B` (via function composition).
def foldRight[A, B](as: List[A])(z: B)(f: (A, B) => B): B =
foldMap(as, endoMonoid[B])(f.curried)(z)
foldMap is expecting a function f: A => B.
In foldRight, when f is curried you have A => (B => B), so I suppose f.curried is working because it is the same as (A => B => B), so foldRight is passing in to foldMap what it expect (a function with type A => B), then, what happends next is that foldMap is called and its returning a function B => B, and that's when z comes into play in (f.curried)(z) you call the function B => B with the argument z to get the final B.
Am I right? it is a litle complicated to reason about this code for me.
NOTE: Here is a scalafiddle if you want to play with it.
Well, you seem to be mostly comprehensive to me. Nevertheless, I would clarify some points:
I'd rather say "so I suppose f.curried is working because A => (B => B) is the same as (A => B => B)" (it is ambiguous here and you're talking about f.curried result type basically, not with z)
I'd rather put a point instead of a comma here: "foldMap is expecting a function f: A => B . In foldRight, ... " and pretty much every where else. Shorter phrases, clearer explanation.
what could be an error, (and what is confusing to you?) is that (f.curried)(z) doesn't work on its own and is not called after foldMap(as, endoMonoid[B]). It's first foldMap(as, endoMonoid[B])(f.curried) which is called and then (z). The first returns B => B and called with the second returns B.
I would like to convert an expression such as: a.meth(b) to a function of type (A, B) => C that performs that exact computation.
My best attempt so far was along these lines:
def polish[A, B, C](symb: String): (A, B) => C = { (a, b) =>
// reflectively check if "symb" is a method defined on a
// if so, reflectively call symb, passing b
}
And then use it like this:
def flip[A, B, C](f : (A, B) => C): (B, A) => C = {(b, a) => f(a,b)}
val op = flip(polish("::"))
def reverse[A](l: List[A]): List[A] = l reduceLeft op
As you can pretty much see, it is quite ugly and you have to do a lot of type checking "manually".
Is there an alternative ?
You can achieve it easily with plain old subtype polymorphism. Just declare interface
trait Iface[B, C] {
def meth(b: B): C
}
Then you could implement polish easily
def polish[B, C](f: (Iface[B, C], B) => C): (Iface[B, C], B) => C = { (a, b) =>
f(a, b)
}
Using it is completely typesafe
object IfaceImpl extends Iface[String, String] {
override def meth(b: String): String = b.reverse
}
polish((a: Iface[String, String], b: String) => a meth b)(IfaceImpl, "hello")
Update:
Actually, you could achieve it using closures only
def polish[A, B, C](f: (A, B) => C): (A, B) => C = f
class Foo {
def meth(b: String): String = b.reverse
}
polish((_: Foo) meth (_: String))(new Foo, "hello")
Or without helper function at all :)
val polish = identity _ // Magic at work
((_: Foo) meth (_: String))(new Foo, "hello")
Say you have an EitherT that looks something like this:
type StateListOfString[+T] = State[List[String], T]
type MyEitherT = EitherT[StateListOfString, Int, Boolean]
If you have a for-comprehension that could return a left:
my computation = for {
a <- thingThatCouldReturnLeft
b <- otherThingThatCouldReturnLeft
} yield b
How can you follow up with a for-comprehension that manipulates state before itself returning the left?
I think I want something very close to orElse, but orElse doesn't have access to the value of the left:
def orElse[AA >: A, BB >: B](x: => EitherT[F, AA, BB])(implicit F: Bind[F]): EitherT[F, AA, BB] = {
If it took something like (x: => Int => EitherT[F, AA, BB]) instead of just (x: => EitherT[F, AA, BB]), it would work.
I had tried starting with:
for {
a <- myComputation.isLeft
// OK, now I have something sensible, and I can follow up with something like
// a leftMap
But if I start by calling isLeft, it looks like the computation is run at least twice, once for the isLeft, and again when I call something like leftMap.
What's the right thing to use here?
Looking at the sources of orElse it seems that it can be naturally generalized as
import scala.language.higherKinds
def onLeft[F[+_],A,B](x: => EitherT[F, A, B])
(y: A => EitherT[F, A, B])
(implicit F: Bind[F]): EitherT[F, A, B] =
{
val g = x.run
EitherT(F.bind(g) {
case -\/(l) => y(l).run
case \/-(_) => g
})
}
This is basically the same thing as swapping left/right and then using monadic binding
def onLeft1[F[+_],A,B](x: => EitherT[F, A, B])
(y: A => EitherT[F, A, B])
(implicit F: Monad[F]): EitherT[F, A, B] =
x.swap.flatMap((a: A) => y(a).swap).swap
but of course the first variant is more efficient (and also a bit more general in F).
If I have a function:
f : A => B => C
I can define an implicit conversion such that this can be used where a function (A, B) => C is expected. This goes in the other direction also.
Why are these conversions not implicit (or available implicitly)? I am assuming that bad things could happen for some value of bad things. What value is this?
I don't think anything bad will happen. The conversion is completely unambiguous. Worst case, Scala will not be able to figure out that the implicit conversion applies.
implicit def curryImplicitly[A,B,C](f: (A, B) => C) =
(a: A) => (b: B) => f(a, b)
implicit def uncurryImplicitly[A,B,C](f: A => B => C) =
(a: A, b: B) => f(a)(b)
Then again, these would also be helpful.
implicit def flipImplicitly[A,B,C](f: (A, B) => C) =
(b: B, a: A) => f(a, b)
implicit def flipImplicitlyCurried[A,B,C](f: A => B => C) =
(b: B) => (a: A) => f(a)(b)
But those aren't transitive, so you need these:
implicit def flipAndCurry[A,B,C](f: (A, B) => C) =
(b: B) => (a: A) => f(a, b)
implicit def flipAndUncurry[A,B,C](f: A => B => C) =
(b: B, a: A) => f(a)(b)
But now the conversion is ambiguous. So it's not all roses.
Let's know how it works out in practise. You might need equivalents for Function3, Function4, etc.
You don't want them implicitly available by default (always-on) because then the type system has trouble helping you out when you have overloaded with arguments of a bunch of similar types:
A => B => C
D => C // D is allowed to be a tuple (A,B)...
(A,B) => C // If I have this, to whom should I convert?
Part of the advantage of strong typing is warning you when you've done something foolish. Trying too hard to make things work reduces the benefits. Here, if the conversions were done automatically, you might not call the method you meant to call.
Having them available implicitly upon request is fine, but it's not that hard to do it yourself if you need it. This is something that I would use quite rarely; I wouldn't put it in my top ten or probably even top hundred things that I'd like in the library (in part because I might prefer the automatic conversion to a tuple instead of the automatic currying/uncurrying).