Attempting to get (&) added to Data.Function led to a rather profound amount of disagreement last time it was brought up, so eventually we just let the status quo continue. -Edward

On Oct 9, 2013, at 2:52 PM, Oren Ben-Kiki wrote:

& is already used for this purpose by the Lens library...

...

On Wed, Oct 9, 2013 at 9:51 PM, Wvv wrote: It's looking very strange, that such easy function as flipped function application is still absent at the base.

x # f = f x infixl 1 # -- infix (#) must conflict neither ($), nor (.)

We could add it to Data.Functions and probably to Prelude.

It is very useful function to get rid of parentheses (1); "object looking" record style (2); left-to-right function reading style (3); nice looking last argument-data (4)

1) xs # map $ someLong function x # some . function . composition 2) car # color 3) myString # lines # map words # concat # filter myFilter # unwords 4) eitherData # either (left long function) (right long function)

Many of possible names are already busy. I made the review of possible names:

# - free; disadvantage: possible conflicts with Magic Hash ## - free; disadvantage: heavy looking; possible conflicts with Magic Hash `to` - free; disadvantage: not easy to read composite functions <: - free; & - free; (conflict with fgl package) disadvantage: looking like boolean operator .: - free; .:. - free; disadvantage: many dots <-| - free; disadvantage: long name <+ - free; <~ - free; :~ - free; -|- - free; disadvantage: bad looking; % - busy: Data.Ratio %% - free; disadvantage: heavy looking; ^ - busy: Prelude .^. - free; ^^^ - free; disadvantage: long name |.| - free; disadvantage: strange looking; *$ - free; disadvantage: looking like ($) <| - busy: Data.Sequence < - busy: Prelude << - busy: Text.Html; Text.XHtml.* from html and xhtml package <<< - busy: Control.Category * - busy: Prelude ** - busy: Prelude *** - busy: Control.Arrow <*> - busy: Control.Applicative <**> - busy: Control.Applicative !! - busy: Prelude -| - busy: Control.Parallel.Strategies your suggestion - free;

I prefer (#) , then (.:) and then (<:).

What do you prefer?

Possible looking (copy to your editor to taste them):

2.1 # max 50 # cos # tan # negate # ceiling

2.1 ## max 50 ## cos ## tan ## negate ## ceiling

2.1 `to` max 50 `to` cos `to` tan `to` negate `to` ceiling

2.1 <: max 50 <: cos <: tan <: negate <: ceiling

2.1 & max 50 & cos & tan & negate & ceiling

2.1 .: max 50 .: cos .: tan .: negate .: ceiling

2.1 .:. max 50 .:. cos .:. tan .: negate .:. ceiling

2.1 <-| max 50 <-| cos <-| tan <-| negate <-| ceiling

2.1 <+ max 50 <+ cos <+ tan <+ negate <+ ceiling

2.1 <~ max 50 <~ cos <~ tan <~ negate <~ ceiling

2.1 % max 50 % cos % tan % negate % ceiling

2.1 %% max 50 %% cos %% tan %% negate %% ceiling

2.1 .^. max 50 .^. cos .^. tan .^. negate .^. ceiling

2.1 :~ max 50 :~ cos :~ tan :~ negate :~ ceiling

2.1 |.| max 50 |.| cos |.| tan |.| negate |.| ceiling

2.1 -|- max 50 -|- cos -|- tan -|- negate -|- ceiling

-- View this message in context: http://haskell.1045720.n5.nabble.com/Flipped-function-application-tp5738131.... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

It wasn't the name that was the source of conflict, but rather a rather die hard cadre of folks who felt that it was redundant and gratuitous. (&) actually polled the best out of the candidate names by far, but it was more that about 40% of those polled were against adding it under any name, even to such an out of the way place. Personally I'd rather have it there than not. However, I feel a need to balance that personal desire against the clear lack of consensus, and even to some extent the need to manage the appearance that I'd be using my shiny new position as the core libraries committee chair to ram through unpopular changes. We have enough real work to do over the course of the next year that I'd rather not expend all of the committee's "political capital" on something this trivial. I have very little desire to relive that proposal. -Edward

On Oct 9, 2013, at 3:08 PM, Wvv wrote:

If (&) is so conflict, we can add different name, (<:) for example.

Edward Kmett wrote

...

Attempting to get (&) added to Data.Function led to a rather profound amount of disagreement last time it was brought up, so eventually we just let the status quo continue.

-Edward

...

On Oct 9, 2013, at 2:52 PM, Oren Ben-Kiki <

...

haskell-oren@

...

> wrote:

...

& is already used for this purpose by the Lens library...

_______________________________________________ Libraries mailing list

...

Libraries@

...

http://www.haskell.org/mailman/listinfo/libraries

-- View this message in context: http://haskell.1045720.n5.nabble.com/Flipped-function-application-tp5738131p... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

When I tallied the vote after last time adding it as (&) won more than half the vote, but it was clearly something that evoked a very strong response out of a sizeable portion of the community, so we backed down. At the time there was no maintainer for base. Now we have the core libraries committee. All the alternate names polled much worse than (&), so bike shedding the name won't fix it. ;) How about this: I'll ask the core libraries committee for a judgment, but recuse myself. -Edward

On Oct 9, 2013, at 3:23 PM, Dan Burton wrote:

What were the arguments against (&)? Were they about that choice of symbol in particular, or about the presence of such an operator at all? If the former, then we can keep putting different colors on the bikeshed until we find one everyone likes. If the latter, then I guess we just stick with telling people to import it from lens or diagrams or whatever.

I believe my previous participation in that discussion was to promote (|>), but at this point I don't really care what it's called, I just think that this operator under any symbolic name should be present in an easily accessible location, preferably in base libs.

-- Dan Burton

...

On Wed, Oct 9, 2013 at 12:00 PM, Edward Kmett wrote: Attempting to get (&) added to Data.Function led to a rather profound amount of disagreement last time it was brought up, so eventually we just let the status quo continue.

-Edward

...

On Oct 9, 2013, at 2:52 PM, Oren Ben-Kiki wrote:

& is already used for this purpose by the Lens library...

...

On Wed, Oct 9, 2013 at 9:51 PM, Wvv wrote: It's looking very strange, that such easy function as flipped function application is still absent at the base.

x # f = f x infixl 1 # -- infix (#) must conflict neither ($), nor (.)

We could add it to Data.Functions and probably to Prelude.

It is very useful function to get rid of parentheses (1); "object looking" record style (2); left-to-right function reading style (3); nice looking last argument-data (4)

1) xs # map $ someLong function x # some . function . composition 2) car # color 3) myString # lines # map words # concat # filter myFilter # unwords 4) eitherData # either (left long function) (right long function)

Many of possible names are already busy. I made the review of possible names:

# - free; disadvantage: possible conflicts with Magic Hash ## - free; disadvantage: heavy looking; possible conflicts with Magic Hash `to` - free; disadvantage: not easy to read composite functions <: - free; & - free; (conflict with fgl package) disadvantage: looking like boolean operator .: - free; .:. - free; disadvantage: many dots <-| - free; disadvantage: long name <+ - free; <~ - free; :~ - free; -|- - free; disadvantage: bad looking; % - busy: Data.Ratio %% - free; disadvantage: heavy looking; ^ - busy: Prelude .^. - free; ^^^ - free; disadvantage: long name |.| - free; disadvantage: strange looking; *$ - free; disadvantage: looking like ($) <| - busy: Data.Sequence < - busy: Prelude << - busy: Text.Html; Text.XHtml.* from html and xhtml package <<< - busy: Control.Category * - busy: Prelude ** - busy: Prelude *** - busy: Control.Arrow <*> - busy: Control.Applicative <**> - busy: Control.Applicative !! - busy: Prelude -| - busy: Control.Parallel.Strategies your suggestion - free;

I prefer (#) , then (.:) and then (<:).

What do you prefer?

Possible looking (copy to your editor to taste them):

2.1 # max 50 # cos # tan # negate # ceiling

2.1 ## max 50 ## cos ## tan ## negate ## ceiling

2.1 `to` max 50 `to` cos `to` tan `to` negate `to` ceiling

2.1 <: max 50 <: cos <: tan <: negate <: ceiling

2.1 & max 50 & cos & tan & negate & ceiling

2.1 .: max 50 .: cos .: tan .: negate .: ceiling

2.1 .:. max 50 .:. cos .:. tan .: negate .:. ceiling

2.1 <-| max 50 <-| cos <-| tan <-| negate <-| ceiling

2.1 <+ max 50 <+ cos <+ tan <+ negate <+ ceiling

2.1 <~ max 50 <~ cos <~ tan <~ negate <~ ceiling

2.1 % max 50 % cos % tan % negate % ceiling

2.1 %% max 50 %% cos %% tan %% negate %% ceiling

2.1 .^. max 50 .^. cos .^. tan .^. negate .^. ceiling

2.1 :~ max 50 :~ cos :~ tan :~ negate :~ ceiling

2.1 |.| max 50 |.| cos |.| tan |.| negate |.| ceiling

2.1 -|- max 50 -|- cos -|- tan -|- negate -|- ceiling

-- View this message in context: http://haskell.1045720.n5.nabble.com/Flipped-function-application-tp5738131.... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Thu, Oct 10, 2013 at 4:46 AM, Simon Peyton-Jones wrote:

F# uses (|>). Maybe (#) is good. To me (&) looks too commutative because it’s usually used for conjunction.

I mentioned this on the core list, but I'll mention it here, too: I don't like (|>), because once you have this operator, you also might as well have the functorial version. We have ($) and (<$>), and lens has (&) and (<&>). The latter is useful for functorial 'for blocks': myFunctorValue <&> \x -> ...complex expression... I actually think it's (significantly) more useful than (&). But, I think (<|>>) is a pretty awful name for it, so I'd prefer a name that makes both palatable. -- Dan

We want to combine all of them, like xs # map $ (+ 3) . snd And xs $$ map $ (+ 3) . snd - don't look nice. By the way, ($$) is already heavy use at pretty, conduit, enumerator, snap-core By the way, in OCaml we have next syntax for objects: object #field so, (#) isn't against ML In Data.Sequence is already defined (|>), (<|) and (:>). But not (<:) In Platform, fgl package, Data.Graph.Inductive.Graph is already defined (&). If there are many disadvantages to use (#), (&) or (|>) we could use something more neutral, like (.:) : xs .: map $ (+ 3) . snd (.:) is free. It is only use in some packages, like aeson. David Menendez-2 wrote

On Thu, Oct 10, 2013 at 10:13 AM, Dan Doel <

dan.doel@

> wrote:

...

On Thu, Oct 10, 2013 at 4:46 AM, Simon Peyton-Jones <

simonpj@

> wrote:

...

...

F# uses (|>). Maybe (#) is good. To me (&) looks too commutative because it’s usually used for conjunction.

I mentioned this on the core list, but I'll mention it here, too:

I don't like (|>), because once you have this operator, you also might as well have the functorial version. We have ($) and (<$>), and lens has (&) and (<&>). The latter is useful for functorial 'for blocks':

myFunctorValue <&> \x -> ...complex expression...

I actually think it's (significantly) more useful than (&). But, I think (<|>>) is a pretty awful name for it, so I'd prefer a name that makes both palatable.

I'm still not convinced we need flipped application in general[1], and I'm sure we don't need new name suggestions at this point, but:

Consider <**> :: f a -> f (a -> b) -> f b.

That suggests <$$> :: f a -> (a -> b) -> f b by analogy, so maybe $$ :: a -> (a -> b) -> b? This avoids the downsides of & while maybe being less ugly to combine with things than |>. Also, it looks like $, suggesting they're related.

[1]: Although it's certainly convenient for some idioms, like working with lenses.

-- Dave Menendez <

dave@

> <http://www.eyrie.org/~zednenem/>;

_______________________________________________ Libraries mailing list

Libraries@

http://www.haskell.org/mailman/listinfo/libraries

-- View this message in context: http://haskell.1045720.n5.nabble.com/Flipped-function-application-tp5738131p... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

We've found with lens in practice it is actually quite useful to have (&) bind just a touch tighter than ($), but yes, we do tend to discourage users from mashing them together: makeMyLenses = makeLensesWith $ defaultRules & ... & ... & ... -Edward On Thu, Oct 10, 2013 at 2:18 PM, David Menendez wrote:

On Thu, Oct 10, 2013 at 1:08 PM, Wvv wrote:

...

We want to combine all of them, like

xs # map $ (+ 3) . snd

And xs $$ map $ (+ 3) . snd - don't look nice.

That's actually a pretty good example of why this is a bad idea. You can't know which argument is being applied first unless you know the precedence levels.

In fact, according to the fixity you initially proposed, that translates to

(xs # map) $ (+3) . snd

The corrected version, xs # (map $ (+3) . snd), isn't much better. Even with the parentheses, it's needlessly confusing. ($) and (#) should never appear in the same expression, or at least they shouldn't apply arguments to the same function. It would be like using (.) and (>>>) together.

-- Dave Menendez http://www.eyrie.org/~zednenem/

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 10/10/13 1:08 PM, Wvv wrote:

(.:) is free. It is only use in some packages, like aeson.

Actually (.:) is pretty heavily used to mean: (f .: g) x y = f (g x y) because: (.:) = (.) . (.) A cursory search shows it in: * http://hackage.haskell.org/package/pointless-fun-1.1.0.1/docs/Data-Function-... * http://hackage.haskell.org/package/custom-prelude-0.2.2.0/docs/CustomPrelude... and it's probably been defined elsewhere too. I know it shows up on irc regularly. -- Live well, ~wren

I quite like that. ($$), that is. Better than (&) Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of | Twan van Laarhoven | Sent: 10 October 2013 18:20 | To: libraries@haskell.org | Subject: Re: Flipped function application | | On 10/10/13 16:16, David Menendez wrote: | > we don't need new name suggestions at this point, but: | > | > Consider <**> :: f a -> f (a -> b) -> f b. | > | > That suggests <$$> :: f a -> (a -> b) -> f b by analogy, so maybe $$ | :: a -> (a | > -> b) -> b? This avoids the downsides of & while maybe being less | ugly to | > combine with things than |>. Also, it looks like $, suggesting | they're related. | > | | As a data point: I have in fact used <$$> as (flip fmap) before, with | this exact | reasoning. | | | | Twan | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries

I hope it does sneak into Prelude, if at all. Having to import a module just for (#) is already going to make it rarely used, but allowing name clashes (since most library authors only care about compatibility with Prelude) would make the matters even worse. wrote:

as long as the operator doesn't sneak into prelude (and thus consuming namespace for everyone), i don't really care >what its called (or if we get it.)

On Thu, Oct 10, 2013 at 1:23 PM, Simon Peyton-Jones wrote:

...

I quite like that. ($$), that is. Better than (&)

Simon

| -----Original Message-----

| From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of

| Twan van Laarhoven

| Sent: 10 October 2013 18:20

| To: libraries@haskell.org

| Subject: Re: Flipped function application

|

| On 10/10/13 16:16, David Menendez wrote:

| > we don't need new name suggestions at this point, but:

| >

| > Consider <**> :: f a -> f (a -> b) -> f b.

| >

| > That suggests <$$> :: f a -> (a -> b) -> f b by analogy, so maybe $$

| :: a -> (a

| > -> b) -> b? This avoids the downsides of & while maybe being less

| ugly to

| > combine with things than |>. Also, it looks like $, suggesting

| they're related.

| >

|

| As a data point: I have in fact used <$$> as (flip fmap) before, with

| this exact

| reasoning.

|

|

|

| Twan

A year ago, I might have opposed the proposal altogether, but diagrams has convinced me that it's quite useful.

It's almost the same for myself. I thought that I should dislike the lens library, but after being able to write code like this: grid & atCoord oldCoord . entity .~ NoEntity & atCoord newCoord . entity .~ RobotEntity rob And I think it would read even better like this: grid # atCoord oldCoord . entity .= NoEntity # atCoord newCoord . entity .= RobotEntity rob Yes, having to use '~' instead of '=' is the thing that currently bothers me the most about the lens library, because IMHO the usage in the State-Monad should be the lesser used one, should be the less encouraged one, and the "nicer" operator should be reserved for the more common case. Being able to use '.=' in the State-Monad seems mostly to be nice for writing tutorials =). Greetings, Daniel

...

...

...

...

Edward Kmett writes:

I'd be willing to risk the pain of switching to = for the functional versions of the functions rather than ~ if a majority of users wanted it that way.

+1 for (.=). -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

That isn't subject to the libraries@ proposal process. It is however, actively being debated over in #haskell-lens and on https://github.com/ekmett/lens/issues/347 On Fri, Oct 11, 2013 at 8:44 PM, Artyom Kazak wrote:

On Sat, 12 Oct 2013 03:59:15 +0400, John Wiegley wrote:

Edward Kmett writes:

...

...

...

...

...

>

I'd be willing to risk the pain of switching to = for the functional versions of the functions rather than ~ if a majority of users wanted it that way.

+1 for (.=).

Maybe it should be made a separate proposal?

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries

On Fri, Oct 11, 2013 at 05:02:26PM +0200, Dag Odenhall wrote:

I like (&) better than (#) because it reads like x and apply f to it, but I could probably get used to (#) too.

Perhaps I've been just doing too much C/C++ programming and therefore dislike '&', but also in the Haskell world there're the operators '&&' and '.&.', so '&' has for myself the connotation of taking two things of the same kind and combine them in a way. So I would prefer '#', but most likely could also live with '&'. Greetings, Daniel

On Oct 10, 2013 3:47 AM, "Simon Peyton-Jones" wrote:

I believe my previous participation in that discussion was to promote

(|>), but at this point I don't really care what it's called, I just think that this operator under any symbolic name should be present in an easily accessible location, preferably in base libs.

I agree with the sentiment! The OO folk uses this style all the time!

(thing .op1 .op2) meaning op2 (op1 thing).

I don't understand this reasoning. Why should Haskell have strongly baked-in support for OO style? And take up a rare 1- or 2-char op name? Especially since it can be provided by a library? But then, I still have a suspicion that Edward is a massive troll trying to embed Java in Haskell, so this might just be my bias.

F# uses (|>). Maybe (#) is good. To me (&) looks too commutative

because it’s usually used for conjunction.

Resolving this kind of no-perfect-solution-but-we-need-a-solution thing

is what the core libraries committee is for. Let’s ask them if they’d consider taking it on.

Simon

From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Dan

Sent: 09 October 2013 20:23 To: Edward Kmett Cc: libraries@haskell.org Subject: Re: Flipped function application

What were the arguments against (&)? Were they about that choice of symbol in particular, or about the presence of such an operator at all? If

Burton the former, then we can keep putting different colors on the bikeshed until we find one everyone likes. If the latter, then I guess we just stick with telling people to import it from lens or diagrams or whatever.

I believe my previous participation in that discussion was to promote

(|>), but at this point I don't really care what it's called, I just think that this operator under any symbolic name should be present in an easily accessible location, preferably in base libs.

-- Dan Burton

On Wed, Oct 9, 2013 at 12:00 PM, Edward Kmett wrote:

...

Attempting to get (&) added to Data.Function led to a rather profound

amount of disagreement last time it was brought up, so eventually we just let the status quo continue.

...

-Edward

On Oct 9, 2013, at 2:52 PM, Oren Ben-Kiki

wrote:

...

...

& is already used for this purpose by the Lens library...

On Wed, Oct 9, 2013 at 9:51 PM, Wvv wrote:

...

It's looking very strange, that such easy function as flipped function application is still absent at the base.

x # f = f x infixl 1 # -- infix (#) must conflict neither ($), nor (.)

We could add it to Data.Functions and probably to Prelude.

It is very useful function to get rid of parentheses (1); "object

looking"

...

...

record style (2); left-to-right function reading style (3); nice looking last argument-data (4)

1) xs # map $ someLong function x # some . function . composition 2) car # color 3) myString # lines # map words # concat # filter myFilter # unwords 4) eitherData # either (left long function) (right long function)

Many of possible names are already busy. I made the review of possible names:

# - free; disadvantage: possible conflicts with Magic Hash ## - free; disadvantage: heavy looking; possible conflicts with Magic Hash `to` - free; disadvantage: not easy to read composite functions <: - free; & - free; (conflict with fgl package) disadvantage: looking like boolean operator .: - free; .:. - free; disadvantage: many dots <-| - free; disadvantage: long name <+ - free; <~ - free; :~ - free; -|- - free; disadvantage: bad looking; % - busy: Data.Ratio %% - free; disadvantage: heavy looking; ^ - busy: Prelude .^. - free; ^^^ - free; disadvantage: long name |.| - free; disadvantage: strange looking; *$ - free; disadvantage: looking like ($) <| - busy: Data.Sequence < - busy: Prelude << - busy: Text.Html; Text.XHtml.* from html and xhtml package <<< - busy: Control.Category * - busy: Prelude ** - busy: Prelude *** - busy: Control.Arrow <*> - busy: Control.Applicative <**> - busy: Control.Applicative !! - busy: Prelude -| - busy: Control.Parallel.Strategies your suggestion - free;

I prefer (#) , then (.:) and then (<:).

What do you prefer?

Possible looking (copy to your editor to taste them):

2.1 # max 50 # cos # tan # negate # ceiling

2.1 ## max 50 ## cos ## tan ## negate ## ceiling

2.1 `to` max 50 `to` cos `to` tan `to` negate `to` ceiling

2.1 <: max 50 <: cos <: tan <: negate <: ceiling

2.1 & max 50 & cos & tan & negate & ceiling

2.1 .: max 50 .: cos .: tan .: negate .: ceiling

2.1 .:. max 50 .:. cos .:. tan .: negate .:. ceiling

2.1 <-| max 50 <-| cos <-| tan <-| negate <-| ceiling

2.1 <+ max 50 <+ cos <+ tan <+ negate <+ ceiling

2.1 <~ max 50 <~ cos <~ tan <~ negate <~ ceiling

2.1 % max 50 % cos % tan % negate % ceiling

2.1 %% max 50 %% cos %% tan %% negate %% ceiling

2.1 .^. max 50 .^. cos .^. tan .^. negate .^. ceiling

2.1 :~ max 50 :~ cos :~ tan :~ negate :~ ceiling

2.1 |.| max 50 |.| cos |.| tan |.| negate |.| ceiling

2.1 -|- max 50 -|- cos -|- tan -|- negate -|- ceiling

-- View this message in context: http://haskell.1045720.n5.nabble.com/Flipped-function-application-tp5738131.... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Wed, 9 Oct 2013, Wvv wrote:

Because we are talking about 2 lines of code (15 non-space symbols) outside of the core, the question is a bit different: do you want to guide the process, or do you prefer to see how this process become completely non-controllable?

Please read the last discussion on the topic before repeating it: http://www.haskell.org/pipermail/libraries/2012-November/018565.html

As in the last discussion, I am in favor of adding a flipped function application operator. My pick would be (|>), but I'd also support (&). Let's not reject this proposal this time, otherwise we'll have it back in a couple of months... My take is that if a feature is repeatedly asked for (independently), it can't be that bad and should be added... Cheers, Andreas On 2013-10-10 15:29, Wvv wrote:

Thank you very much!

We could divide negative arguments :

1) Aesthetic ugliness.

Flipped function application is a part of Haskell 98. And it is not more ugly, then eta-reduction or currying. I think Dynamic is much more ugly, but it is a part of Platform and it even develops, and this is nice! If (#) is so ugly, no one order to use it.

2) Flipped function application is so powerful, that everyone use it instead of ($) and (.).

If we are looking at code, who use OCaml-Batteries code, no, it is still OCaml, not Haskell.

3) At least newcomers use (#) instead of ($) and (.).

First, if we "hide" it in Data.Functions, then it is not so easy to find it. Second, in any case, if newcomers use it and see, how Haskell is easy, because Haskell code look like his/her favorite Java/C++/Ruby/... - I think it is a big advantage, not a disadvantage at all.

4) Code with Flipped function application looks like OOP

"class" and "return" also looks like OOP and imperative programs. If someone like OOP so much, that it use (#) and Haskell instead of programming his favorite OOP language - this is nice!

Am I miss something?

Henning Thielemann wrote

...

Please read the last discussion on the topic before repeating it:

http://www.haskell.org/pipermail/libraries/2012-November/018565.html _______________________________________________ Libraries mailing list

...

Libraries@

...

http://www.haskell.org/mailman/listinfo/libraries

-- View this message in context:

http://haskell.1045720.n5.nabble.com/Flipped-function-application-tp5738131p... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich http://www.tcs.informatik.uni-muenchen.de/~abel/

I'm against this proposal. If we think normal function composition (with the order of the functions "reversed"), is harder to read, then having both flipped and normal functions application is even worse, as you now have to both and switch your mindset every time you come across code that does the opposite of the code you just read. On Thu, Oct 10, 2013 at 12:31 AM, Erik Hesselink wrote:

On Thu, Oct 10, 2013 at 9:25 AM, Andreas Abel wrote:

...

My take is that if a feature is repeatedly asked for (independently), it can't be that bad and should be added...

I strongly oppose this line of reasoning. Every feature has a cost: cognitive (you have to know about it), maintenance, restricting the name space for library authors (and remember that not all Haskell code is on hackage...) etc. Especially with the core language and base, I think the default should be to be conservative.

Also, I don't think these kinds of things should be a majority rule. And especially one where the most vocal have the most votes...

Erik _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Thu, 10 Oct 2013 21:12:28 +0400, Wvv wrote:

Is it hard to read?

xs # map $ (+ 3) . snd

Or do you prefer next?

map ((+3).snd) xs

To be honest, I find the former harder to read. It can’t be established objectively, though, as most people are already used to `map f xs` and can read it without any mental effort. On the other hand, I can see myself getting used to `xs # map $ (+ 3) . snd` (by reading it right-to-left: (+3).snd... through “map-interface”... applies to xs; which is why I prefer <$>, by the way).

On 10/10/13 3:42 AM, Johan Tibell wrote:

I'm against this proposal. If we think normal function composition (with the order of the functions "reversed"), is harder to read, then having both flipped and normal functions application is even worse, as you now have to both and switch your mindset every time you come across code that does the opposite of the code you just read.

+1 (to this -1). -- Live well, ~wren

I've referred this question to the core libraries committee for a binding decision about including it or not, and recused myself from the discussion. We should get some closure about this issue this way. The previous proposal was unilaterally withdrawn, but there still appear to be stalwarts on both sides. That is about all I can reasonably do. -Edward

On Oct 9, 2013, at 5:53 PM, Wvv wrote:

Because we are talking about 2 lines of code (15 non-space symbols) outside of the core, the question is a bit different: do you want to guide the process, or do you prefer to see how this process become completely non-controllable?

I really-really don't understand when at some languages people say "It's nice language, but don't use build lib, use extension/battery lib". Sometimes it became even dramatic, like D language, when extended library (Tango) was incompatible (at D1 times) with the standard one.

This is looks like OCaml has neither (.), nor ($). Fortunately, OCaml-Batteries add :

val (|>) : 'a -> ('a -> 'b) -> 'b val (<|) : ('a -> 'b) -> 'a -> 'b val (|-) : ('a -> 'b) -> ('b -> 'c) -> 'a -> 'c val (-|) : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b val flip : ('a -> 'b -> 'c) -> 'b -> 'a -> 'c val curry : ('a * 'b -> 'c) -> 'a -> 'b -> 'c val uncurry : ('a -> 'b -> 'c) -> 'a * 'b -> 'c val const : 'a -> 'b -> 'a

I don't want Haskell be like OCaml and use Data.Lens/other package for using simplest (&/#/<:/|>/..) function!

Niklas Haas wrote

...

On Wed, 9 Oct 2013 11:51:39 -0700 (PDT), Wvv <

...

vitea3v@

...

> wrote:

...

It's looking very strange, that such easy function as flipped function application is still absent at the base.

I'm not convinced the stylistic differences to ($) are really worth adding it as a distinct combinator, at least for general-purpose code.

It works nicely for lens because it lets you mimic the appearance of record update syntax, but it might not be the best idea to introduce it as an entirely separate idiom - seeing as it could cause lots of unnecessary code complexity and confusion. _______________________________________________ Libraries mailing list

...

Libraries@

...

http://www.haskell.org/mailman/listinfo/libraries

-- View this message in context: http://haskell.1045720.n5.nabble.com/Flipped-function-application-tp5738131p... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

* Jon Fairbairn [2013-10-10 09:45:05+0100]

And mimicking record syntax is mimicking something that’s backwards anyway. The syntax should have been “{fld=val} rec”, and “{fld=val}” should just be a function like any other.

Interesting. What's your take on the record construction and record pattern syntaxes? Roman