Function Composition

[John Nilsson]

And my argument was that the name "compose" is equally valid for x ↦
(g∘f)(x) as for x ↦ (f*;*g)(x) if you ask math people. While Scala people
would use "g compose f" or "g andThen f"
I argue that the common use of ∘ for function composition should be
discouraged in all contexts. If Java promotes the other form by only having
a single composition operation in applicative order it would be a good
thing for everyone.
OTOH if the end result is endless debates such as this the net cost might
be higher than what it's worth ;-P

The argument that ∘ is "natural" because (g∘f)(x) = g(f(x)) is kind of
silly in my mind, the parentheses are there for a reason. If anything is
unatural there it is the g(f(x)) syntax which could very well be replace by
something like x↦f;g to make things "natural"

Oh, well. I'm just arguing for the sake of arguing now, I'm not even sure
I'll ever use Java professionally again, so you shouldn't take my optioning
as representative of anything...

There is one thing I would say favours the "andThen" position, and that is
that "compose" is a name from the wrong abstraction level. It would be more
correct to inherit this from something like "Category" (as in category
theory) - if such a thing would be possible to express in Java - and
implement it in terms of "andThen", which is more specific to the problem
domain of functions.


BR,
John


On Wed, Jan 2, 2013 at 3:08 AM, Jed Wesley-Smith <jed at wesleysmith.io> wrote:

> (forgot to post to the list)
>
> The reason f compose g is "natural" is that you get x -> f(g(x))
>
> If you want the alternate f andThen g then you get x -> g(f(x))
>
> As I gave as reference in the original email:
>
> http://en.wikipedia.org/wiki/Function_composition_(computer_science)
>
> as well as the usual math definition:
>
> http://en.wikipedia.org/wiki/Function_composition
>
> for further reference, here's rosettacode:
>
> http://rosettacode.org/wiki/Function_composition
>
> Yes, Scala does use compose/andThen – this is likely to be a specific
> and particular source of confusion and issues as it is a particularly
> likely place Java programmers will have contact with the idiom.
>
> This notion of compose is very well established.
>
> cheers,
> jed.
>
> On 2 January 2013 11:29, John Nilsson <john at milsson.nu> wrote:
> > Btw, compose and andThen feels like Scala to me. So there's some
> precedence
> > for that choice of names. Did you have any other source in mind? Besides
> the
> > proliferation of the ∘ in math texts I can't really think of any specific
> > common understanding of "compose" meaning some specific thing, I don't
> think
> > Scala qualifies as "common" at this time.
> > So my argument was that even the math people can agree to interpret
> > "compose" as ";", while less commonly used, it's the same operation.
> > Given that we both agree that "andThen" should be used instead, why even
> > have the other? And if there is only the one, why not call it by it's
> > natural name "compose"?
> >
> > BR,
> > John
> >
> >
> > On Wed, Jan 2, 2013 at 1:17 AM, Jed Wesley-Smith <jed at wesleysmith.io>
> wrote:
> >>
> >> Well, I'm not arguing the merits of one or the other, indeed I'd like
> >> both (and I usually use the andThen/; form). I'd just argue that this
> >> is a well established name/form and there is value (as in least
> >> surprise) in following the precedent.
> >>
> >> Function<A, B> f = …
> >> Function<B, C> g = …
> >>
> >> Function<A, C> c = g.compose(f);
> >> Function<A, C> d = f.andThen(g);
> >>
> >> I'd argue the second form reads better anyway!
> >>
> >> cheers,
> >> jed.
> >>
> >> On 2 January 2013 11:07, John Nilsson <john at milsson.nu> wrote:
> >> > For what it's worth. I think the math people got it wrong with "∘".
> The
> >> > other operation they call compose: ";" - which has applicative order -
> >> > feels
> >> > more natural. So one vote for keeping compose as ";". Also, this is
> the
> >> > composition operation for statements Java programmers have been using
> >> > for
> >> > years with no complaint, so why arbitrarily switch to "∘" for function
> >> > composition?
> >> > Besides even the math people revert to applicative order when
> modelling
> >> > function composition as a category.
> >> >
> >> > BR,
> >> > John
> >> >
> >> >
> >> > On Wed, Jan 2, 2013 at 12:40 AM, Jed Wesley-Smith <jed at wesleysmith.io
> >
> >> > wrote:
> >> >>
> >> >> hello lambdarians!
> >> >>
> >> >> Just noticed that the java.util.function.Function.compose method is
> >> >> round the wrong way (according to the common definition of function
> >> >> composition*).
> >> >>
> >> >> The current lambda definition:
> >> >>
> >> >>
> >> >>
> >> >>
> http://hg.openjdk.java.net/lambda/lambda/jdk/file/858e2f478d62/src/share/classes/java/util/function/Function.java
> >> >>
> >> >> has f.compose(g) mean apply f and then apply g, whereas the usual
> >> >> (most other languages and the literature) has f ∘ g mean apply g and
> >> >> then apply f.
> >> >>
> >> >> The form that Function has currently is commonly known as andThen.
> So,
> >> >> you could rename the current method andThen and add a new compose
> >> >> method that works in the usual manner.
> >> >>
> >> >> cheers,
> >> >> jed.
> >> >>
> >> >> * references:
> >> >> http://en.wikipedia.org/wiki/Function_composition
> >> >> http://en.wikipedia.org/wiki/Function_composition_(computer_science)
> >
> >
>