Function Composition

[Zhong Yu]

Whatever it is called, isn't it easier for *java guys* to remember

    (f.xxx(g)).apply(v) == f(g(v))

than

    (f.xxx(g)).apply(x) == g(f(v))

?

On Tue, Jan 1, 2013 at 9:37 PM, John Nilsson <john at milsson.nu> wrote:
> 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)
>> >
>> >
>>
>