We Keep Coding

What would a compose method in the BiFunction interface look like?

The Function interface has the compose() and andThen() methods while the BiFunction interface only has the andThen() method. My question is simply how could the corresponding method be implemented? I'll try to represent this graphically.
The single letters are parameterized types as defined by Java's Function and BiFunction interfaces. Arrows are the flow of inputs and outputs. Boxes with connected arrows are functions. The dotted box just shows how the apply method is used.

The Function's Compose() and andThen() methods are straightforward since a Function has one input and one output and therefore can only be strung sequentially with another in two ways.
Since a BiFunction has one output, the "after" function has to be something with only one corresponding input, and Function fits the bill. And since it has two inputs, the "before" function needs to be something with two outputs? You can't have a method return two things, so there seemingly can't be a "before". The return type of each of these methods is the same as the interface they are defined in, so the proposed method should return a BiFunction.
My proposal then is a method that takes two Functions as input and returns a BiFunction. I'm not sure what else it could even be. It couldn't be two BiFunctions because then the return type would have to be a QuaterFunction.
Here is the code as it would be written in the Java Library:
public interface BiFunction<T, U, R> {
// apply()...
default <V, W> BiFunction<V, W, R> compose(
Function<? super V, ? extends T> beforeLeft,
Function<? super W, ? extends U> beforeRight) {
Objects.requireNonNull(beforeLeft);
Objects.requireNonNull(beforeRight);
return (V v, W w) -> apply(beforeLeft.apply(v), beforeRight.apply(w));
}
// andThen()...
}
Here is the finished graph:
Here it is in use:
BiFunction<Integer, Integer, Integer> add = Integer::sum;
Function<Integer, Integer> abs = Math::abs;
BiFunction<Integer, Integer, Integer> addAbs = add.compose(abs, abs);
System.out.println(addAbs.apply(-2, -3));
// output: 5
If you want to actually test this, you can do something like this:
public interface BiFunctionWithCompose<T, U, R> extends BiFunction<T, U, R> {...
Or like this:
package myutil;
public interface BiFunction<T, U, R> extends java.util.function.BiFunction<T, U, R> {...
I have no idea if this will be useful to anyone, but it was really fun to think through and write. Have a wonderful day.

Common generic method to handle operations on subclasses of java.lang.Number

I have a class MyGen which takes two generic arguments and has a method getValue()
public interface MyGen<E,T> {
T getValue();
}
Usually the second generic type would be either Long or Integer.
Then, I wrote a method to combine the objects when the second generic type is Long as below:
public static <E extends MyGen<?, Long>> long combineValue(Set<E> set) {
return set.stream()
.map(MyGen::getValue)
.reduce(0L, (a,b) -> a | b);
}
Now I want to have a similar method when the second type is an Integer. So I tried updating the above same method to :
public static <E extends MyGen<?, ? extends Number>> long combineValue(Set<E> set) {
return (long) set.stream()
.map(MyGen::getValue)
.reduce((a,b) -> a | b) // error1
.orElse(0); // error2
}
But the following errors are displayed:
error1
The operator | is undefined for the argument type(s) capture#4-of ?
extends java.lang.Number, capture#4-of ? extends java.lang.Number
error2
The method orElse(capture#4-of ? extends Number) in the type
Optional<capture#4-of ? extends Number> is not applicable for the
arguments (int)
Is there any way to handle both Long and Integer in the same method or could it be done only using two separate methods?

You seem to be fine about the return value of this common method being long. In that case, it is possible, because you can get a long from a Number using longValue:
public static long combineValue(Set<? extends MyGen<?, ? extends Number>> set) {
return set.stream()
.map(MyGen::getValue)
.mapToLong(Number::longValue)
.reduce(0L, (a,b) -> a | b);
}
You basically turn every number into longs first, and then do the reduction.

Java Lambda to comparator conversion - intermediate representation

I'm trying to make sense of how Comparator.comparing function works. I created my own comparing method to understand it.
private static <T,U extends Comparable<U>> Comparator<T> comparing(Function<T,U> f) {
BiFunction<T,T,Integer> bfun = (T a, T b) -> f.apply(a).compareTo(f.apply(b));
return (Comparator<T>) bfun;
}
The last line in this function throws an exception.
However, if I change this function to
private static <T,U extends Comparable<U>> Comparator<T> comparing(Function<T,U> f) {
return (T a, T b) -> f.apply(a).compareTo(f.apply(b));
}
It works just fine as expected.
What is the intermediate functional interface which the second attempt uses, which is able to convert the lambda to Comparator?

What is the intermediate functional interface which the second attempt uses, which is able to convert the lambda to Comparator?
The Comparator itself.
Within the second method, you have defined a Comparator, not an intermediate object that has been cast to the Comparator.
The last line in this function throws an exception.
Yes, it should.
If two classes are functional interfaces and have similar methods (with the identical signatures and the same return type), it doesn't mean that they can be used interchangeably.
An interesting trick - you may make a Comparator<T> by referring to the BiFunction<T, T, Integer> bfun's method apply:
private static <T,U extends Comparable<U>> Comparator<T> comparing(Function<T,U> f) {
final BiFunction<T,T,Integer> bfun = (T a, T b) -> f.apply(a).compareTo(f.apply(b));
return bfun::apply; // (a, b) -> bfun.apply(a, b);
}

The intermediate functional interface in your second attempt is simply Comparator<T>:
You can see this because your code-snippet is equivalent to the following:
private static <T,U extends Comparable<U>> Comparator<T> comparing(Function<T,U> f) {
Comparator<T> comparator = (T a, T b) -> f.apply(a).compareTo(f.apply(b));
return comparator;
}

How generics really works as in parameters?

I'm little confused about how the generics works? I'm learning about function API in java and there I just test Function interface and got confused about compose method that how the generics is working in compose method.
Reading the generics on the java official tutorial website I realize that if we have any generic type in the method return or parameters we have to declare that type in the signature of method as explained below.
Here is the method I read in official docs tutorial.
public static <K, V> boolean compare(Pair<K, V> p1, Pair<K, V> p2) {
return p1.getKey().equals(p2.getKey()) &&
p1.getValue().equals(p2.getValue());
}
Above method have two types, K, V which are declared in the signature after the static keyword as but when I read java Function API there is one method called compose and the signature of the compose is as
default <V> Function<V, R> compose(Function<? super V, ? extends T> before) {
Objects.requireNonNull(before);
return (V v) -> apply(before.apply(v));
}
1) The first question where is the T & R declared? which are being used in the return type and in the parameter. Or my understanding is wrong?
Then I read more in generics tutorials and then I try to understand the concept of super and extends in generics and read here then I test compose method more and then confused again about how the super and extends works in the compose method?
public static void main(String... args){
Function<Integer, String> one = (i) -> i.toString();
Function<String, Integer> two = (i) -> Integer.parseInt(i);
one.compose(two);
}
As above I have declared two Function with lamdas. One is having Integer input and String output the other one is reversed from it.
2) The second question is that how Integer and String are related to extends and super? There is no relation between String and Integer class no one is extending each other then how it is working?
I tried my best to explain my question/problem. Let me know what you didn't understand I will try again.

Where are T and R defined?
Remember, compose is declared in the Function interface. It can not only use generic parameters of its own, but also the type's generic parameters. R and T are declared in the interface declaration:
interface Function<T, R> {
...
}
What are ? extends and ? super?
? is wildcard. It means that the generic parameter can be anything. extends and super give constraints to the wildcard. ? super V means that whatever ? is, it must be a superclass of V or V itself. ? extends T means that whatever ? is, it must be a subclass of T or T itself.
Now let's look at this:
Function<Integer, String> one = (i) -> i.toString();
Function<String, Integer> two = (i) -> Integer.parseInt(i);
one.compose(two);
From this, we can deduce that T is Integer and R is String. What is V? V must be some type such that the constraints Function<? super V, ? extends T> is satisfied.
We can do this by substituting the argument we passed in - Function<String, Integer> - to get String super V and Integer extends Integer.
The second constraint is satisfied already while the first constraint now says that String must be a super class of V or String itself. String cannot have subclasses so V must be String.
Hence, you can write something like:
Function<String, String> f = one.compose(two);
but not
Function<Integer, String> f = one.compose(two);
When you compose a Function<Integer, String> and a Function<String, Integer> you cannot possibly get a Function<Integer, String>. If you try to do this, V is automatically inferred to be Integer. But String super Integer is not satisfied, so the compilation fails. See the use of the constraints now? It is to avoid programmers writing things that don't make sense. Another use of the constraints is to allow you to do something like this:
Function<A, B> one = ...
Function<C, SubclassOfB> two = ...
Function<SubclassOfC, B> f = one.compose(two);
There is no relationship between Integer and String in this case, it's all about V.

1) The compose function is part of Interface Function<T,R>. As you can see in documentation for this interface:
Type Parameters:
T - the type of the input to the function
R - the type of the result of the function
2) The super and extends constraints in questions aren't applied to T & R, they're applied to the generic type parameters of a function that you pass in as an argument to the compose function.
Basically this means that if you have:
Function<ClassA, ClassB> one;
Function<SomeSuperClassOfC, SomeSubclassOfA> two;
then it's valid to call
Function<ClassC, ClassB> three = one.compose(two)

I will try to explain from zero;
interface Function<T, R> - this is interface with one method, which must be implemented R apply (T);
in Java prior to 8 we must write:
Function<Integer, String> one = new Function<Integer, String>() {
#Override
public String apply(Integer i) {
return i.toString();
}
};
now you can use it:
String resultApply = one.apply(5);
now, I think, you get the idea.

What are get() and unit() in this definition of applicative functor?

I am trying to code up some functors, monads, and applicatives in java. i found a few and picked the one below.
In terms category theory, what is get() returning?
The unit() seems like some kind of identity, but from what to what? Or perhaps this is a constructor?
I saw one definition of functor that had a get(). What would this be returning?
abstract class Functor6<F,T> {
protected abstract <U> Function<? extends Functor6<F,T>,? extends Functor6<?,U>> fmap(Function<T,U> f);
}
abstract class Applicative<F,T>extends Functor6<F,T> {
public abstract <U> U get(); // what is this in terms of category theory?
protected abstract <U> Applicative<?,U> unit(U value); // what is this in terms of category theory?
protected final <U> Function<Applicative<F,T>,Applicative<?,U>> apply(final Applicative<Function<T,U>,U> ff) {
return new Function<Applicative<F,T>,Applicative<?,U>>() {
public Applicative<?,U> apply(Applicative<F,T> ft) {
Function<T,U> f=ff.get();
T t=ft.get();
return unit(f.apply(t));
}
};
}
}

Some Haskell may help. Firstly, a functor:
class Functor f where
fmap :: (a -> b) -> f a -> f b
We can read this as saying if a type f is a Functor then there must have an fmap function, which takes a function of type a -> b and a value oif type f a to yield an f b. I.e. the type allows the function to be applied to the value within it.
Java doesn't have support for higher-kinded types, which would be required to define a functor type as above, so instead we have to approximate it:
interface Functor6<F, T> {
<U> Function<? extends Functor6<F, T>, ? extends Functor6<?, U>> fmap(Function<T, U> f);
}
Here the generic type parameter F is the Functor type, equivalent to f in the Haskell definition, and T is the contained type (as is U), equivalent to a (and b) in the Haskell definition. In the absence of HKTs we have to use wildcard to refer to the functor type (? extends Functor6<F, T>).
Next, Applicative:
class (Functor f) => Applicative f where
pure :: a -> f a
<*> :: f (a -> b) -> f a -> f b
I.e., for a type f to be an applicative it must be a functor, have a pure operation which lifts a value into the applicative f, and an apply operation (<*>) which, given a function (a -> b) inside an f and an a inside an f, can apply the function to the value to yield a b inside an f.
Here's your Java equivalent, simplified using some Java 8 features, and with some types corrected:
interface Applicative<F, T> extends Functor6<F, T> {
T get();
<F, U> Applicative<F, U> unit(U value);
default <U> Function<Applicative<F, T>, Applicative<F, U>> apply(Applicative<?, Function<T, U>> ff) {
return ft -> {
Function<T, U> f = ff.get();
T t = ft.get();
return unit(f.apply(t));
};
}
}
If we take it line by line:
interface Applicative<F, T> extends Functor6<F, T> {
says an Applicative is a Functor. This:
T get();
appears to be a means of getting access to the value within the applicative. This may work for specific cases, but does not in general work. This:
<F, U> Applicative<F, U> unit(U value);
is supposed to be equivalent to the pure function in the Haskell definition. It ought to be static, otherwise you need an applicative value in order to be able to call it, however making it static would prevent it from being overridden in the actual applicative implementation. There is no simple way to solve this in Java.
Then you have the apply method, which by rights is supposed to be equivalent to <*> in Haskell. As we can see it just gets the function f out of the applicative and then its argument, and returns an applicative containing the result of applying the function to the argument.
This is where the wheels really come off. The details of how an applicative applies a function to a value is specific to each applicative and can't be generalised like this.
In short, this approach is wrong. That's not to say you can't implement applicative functors in Java - you can and it's quite easy, but what you can't do is state within the language that they are applicatives, as you can do in Haskell (using type classes).