Function Composition

Tue Jan 1 21:41:12 PST 2013

I don't see why. *java guys* write f(v);g(v); all the time expecting the
result to be the same as g(f(v)), I'm pretty convinced most java
programmers would be very upset if it wasn't (and most are once they
encounter threads...)

BR,
John

On Wed, Jan 2, 2013 at 6:34 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> 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)
> >> >
> >> >
> >>
> >
>