6

In Java 8 the new package java.util.function contains a lot of functional interfaces. The documentation for that package (http://docs.oracle.com/javase/8/docs/api/java/util/function/package-summary.html) makes several references to "function shapes":

  • There are several basic function shapes, including Function (unary function from T to R), Consumer (unary function from T to void), Predicate (unary function from T to boolean), and Supplier (nilary function to R).
  • Function shapes have a natural arity based on how they are most commonly used. The basic shapes can be modified by an arity prefix to indicate a different arity, such as BiFunction (binary function from T and U to R).
  • There are additional derived function shapes which extend the basic function shapes, including UnaryOperator (extends Function) and BinaryOperator (extends BiFunction).

I had never heard of the term "function shape" before, and I can barely find a reference to it anywhere except in the documentation above, but since that is Oracle's formal documentation on functional interfaces I'd like to understand it.

Can anyone provide a definition of "function shape", and invent an example? Is it a general term in Computer Science, or does it relate only to Java 8? And how is function shape related to a function descriptor (such as (T) -> boolean for the Predicate<T> interface)?

UPDATE The two comments below from Brian Goetz answer the questions I raised in this post.

skomisa
  • 16,436
  • 7
  • 61
  • 102
  • The only (informal) reference to shape in the JLS is at the bottom of [15.12.2.1](http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.1). – assylias Oct 11 '14 at 10:39
  • "shape" is also mentioned in [JSR 335](https://jcp.org/aboutJava/communityprocess/final/jsr335/index.html), Part F; but it is always put in quotation marks, and there is no explicit definition for it. – stakx - no longer contributing Oct 11 '14 at 14:56
  • The references in JLS and JSR335 to "shape" are in identical sentences, and the reference was presumably copied from one document to the other. From the context it seems that "function shape" somehow relates to run-time evaluation (whereas a "function descriptor" is obviously known at compilation). – skomisa Oct 11 '14 at 16:03
  • It is an informal term used to group functions into families based on how they are used. The first bulleted paragraph you quote basically says all you need to know -- that we use "shape" to distinguish families of functions based on their typical usage patterns and user's expectations (Predicate, Supplier, BinaryOperator, etc.) There's nothing magic or deep here. – Brian Goetz Oct 11 '14 at 19:00
  • @BrianGoetz OK, fair enough. So from that it seems that all functional interfaces with the same "shape" will necessarily have the same function descriptor, right? Or am I still missing something here? – skomisa Oct 11 '14 at 19:56
  • No, they won't, because the descriptor takes into account the types (and arity). So while Supplier and IntSupplier have the same shape (produces something from nothing), they have different function descriptors. – Brian Goetz Oct 11 '14 at 20:19

2 Answers2

3

A function shape is basically what its inputs and outputs look like, in terms of the type parameters:

  • A unary function takes one input and returns one output [T→R]
  • A binary function takes two inputs and returns one output [(T,U)→R]
  • A ternary function takes three inputs and returns one output [(T,U,V)→R]
  • A supplier (also known as a nullary function) takes no input and returns one output [()→R]
  • A consumer takes one input and doesn't return any output [T→()]
  • A unary predicate takes one input and returns one output of boolean type [T→bool]
  • A binary predicate takes two inputs and returns one output of boolean type [(T,U)→bool]
  • A unary operator takes one input and returns one output of the same type [T→T]
  • A binary operator takes two inputs of the same type and returns one output of the same type [(T,T)→T]

There are many other shapes, but those are common ones.

C. K. Young
  • 219,335
  • 46
  • 382
  • 435
  • 1
    But if that were the case then Function and Predicate would have the same shape: they both take one input and return one output [1→1]. Yet the documentation quoted above explicitly describes those interfaces as having different shapes. You may be on the right lines, but I'm not sure that types can be ignored. – skomisa Oct 11 '14 at 06:56
  • 2
    @skomi That's true, perhaps it is better to roll types into the discussion. Especially since, there are general unary functions (`T -> U`), predicates (`T -> bool`), and operators (`T -> T`), each of which has a different feel to the other. Lemme amend my post. – C. K. Young Oct 11 '14 at 07:06
  • @stakx Your definition seems close that of "function descriptor", as defined in JSR335: "The function descriptor of a functional interface I is a method type—type parameters, formal parameter types, return types, and thrown types—that can be used to legally override the abstract method(s) of I". That's fine, but invites the question: what's the difference between a "function shape" and a "function desccriptor"? – skomisa Oct 11 '14 at 07:20
  • 1
    @skomi I think function shape is more abstract, whereas function descriptor has a formal concrete definition (as mentioned in JSR 335). – C. K. Young Oct 11 '14 at 07:22
  • Ah, OK! So using one of your examples above: [(T,U)→R] is a specific "function shape", and the BiFunction functional interface would be a concrete example of that function shape being used, since its abstract method apply() takes two parameters and returns a result? – skomisa Oct 11 '14 at 07:34
  • I'm quite a few years late in accepting your answer! My apologies. On revisiting this issue I see that I updated my question to state that Brian Goetz had answered it through comments under the question, but your answer is along the same lines and more complete, and preceded his comments. – skomisa Oct 29 '21 at 18:37
2

I didn't find any reference to an official or widely accepted definition of the term "function shape", so what follows is my own interpretation.

A "function shape" appears to be its "type signature" including the return type, i.e. the sum description of:

  • an ordered list / tuple of the types of its parameters, and
  • its return type

(That is, basically everything about a function except function name, parameter names, and body.) I suspect that they didn't use the term "signature" because it already has a different meaning in Java — it doesn't include the return type. So they invented a new term.

In functional programming languages, "type signature" usually includes the return type. Signatures are helpful in understanding what a function might do, so they are often written down explicitly. For example, the signature (or "function shape" in Java's terms) for the new BiFunction might be written down as (T, U) -> R, where the first part is a tuple representing the parameter list, and the second part is the return type.

I therefore disagree with this other answer: I think that the types matter and are not foregone. If they were foregone, then several types defined in that new namespace would have exactly the same function shape (e.g. Supplier, Predicate, Function). If that were so, then why would the documentation choose to explain these new types with the mismatching concept of function shapes? That doesn't make sense. (The answer has since been edited.)

Here are a couple more examples of functional type signatures for the new Java functional interfaces:

BiFunction<T,U,R>,            (T, U) -> R
BinaryOperator<T,U,R>         (T, U) -> R
BiPredicate<T,U>              (T, U) -> boolean
Consumer<T>                   T      -> ()            note: `()` means `void`
Function<T,R>                 T      -> R
IntFunction<R>                int    -> R
Predicate<T>                  T      -> boolean
Supplier<R>                   ()     -> R
UnaryOperator<T,R>            T      -> R
Community
  • 1
  • 1
stakx - no longer contributing
  • 83,039
  • 20
  • 168
  • 268
  • 1
    Did you mean "T, U -> R" rather than "T -> U -> R"? – skomisa Oct 11 '14 at 07:08
  • 2
    @skomi Yes, it is (T,U)->R, but, for people who are used to using currying languages (like Haskell), it would indeed be T->U->R. – C. K. Young Oct 11 '14 at 07:09
  • 1
    @skomi: I've removed that part of my answer in the mean time. No, I actually meant `T -> U -> R`, since functional progrmaming languages usually allow currying, and I was speaking of functional programming in general. But since currying is not relevant to Java, your suggestion `(T, U) -> R` would indeed be more appropriate. Thanks for the correction! – stakx - no longer contributing Oct 11 '14 at 07:10
  • 1
    @stakx I primarily use Scheme, which is functional but not currying. So I tend to use non-currying notation. :-) – C. K. Young Oct 11 '14 at 07:11
  • The responses from you and Chris are leading me to think that a "function shape" corresponds to a function descriptor in the same way that a method signature corresponds to an actual method. A function shape is devoid of context, but a function descriptor cannot be devoid of context - it necessarily relates to a specific abstract method of a specific functional interface. So in your examples, "(T, U) -> R" (in isolation) is a function shape, but "BiFunction (T, U) -> R" is a specific example of a functional interface using that shape, and has the function descriptor "(T, U) -> R". – skomisa Oct 11 '14 at 08:02
  • I'm not sure I understood the first part of your comment, but I agree with your conclusion (starting with _"So in your examples, …"_). – stakx - no longer contributing Oct 11 '14 at 08:21