Flipped function application

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
57 messages Options
123
Wvv
Reply | Threaded
Open this post in threaded view
|

Flipped function application

Wvv
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
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Oren Ben-Kiki-2
& is already used for this purpose by the Lens library...


On Wed, Oct 9, 2013 at 9:51 PM, Wvv <[hidden email]> 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.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Edward Kmett-2
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 <[hidden email]> wrote:

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


On Wed, Oct 9, 2013 at 9:51 PM, Wvv <[hidden email]> 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.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Wvv
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Wvv
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 <[hidden email]> wrote:
>
> & is already used for this purpose by the Lens library...
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Dan Burton
In reply to this post by Edward Kmett-2
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 <[hidden email]> 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 <[hidden email]> wrote:

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


On Wed, Oct 9, 2013 at 9:51 PM, Wvv <[hidden email]> 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.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Edward Kmett-2
In reply to this post by Wvv
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 <[hidden email]> 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 &lt;
>
>> haskell-oren@
>
>> &gt; 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-tp5738131p5738138.html
> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Edward Kmett-2
In reply to this post by Dan Burton
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

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


On Wed, Oct 9, 2013 at 9:51 PM, Wvv <[hidden email]> 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.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Niklas Haas
In reply to this post by Wvv
On Wed, 9 Oct 2013 11:51:39 -0700 (PDT), Wvv <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Wvv
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Wvv
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Henning Thielemann

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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Edward Kmett-2
In reply to this post by Wvv
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 <[hidden email]> 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 &lt;
>
>> vitea3v@
>
>> &gt; 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-tp5738131p5738150.html
> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Wvv
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Wvv
In reply to this post by Henning Thielemann
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Andreas Abel
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-tp5738131p5738167.html
> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> _______________________________________________
> Libraries mailing list
> [hidden email]
> 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/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Erik Hesselink
On Thu, Oct 10, 2013 at 9:25 AM, Andreas Abel <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Johan Tibell-2
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 <[hidden email]> wrote:
On Thu, Oct 10, 2013 at 9:25 AM, Andreas Abel <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Jon Fairbairn
In reply to this post by Niklas Haas
Niklas Haas <[hidden email]> writes:

> On Wed, 9 Oct 2013 11:51:39 -0700 (PDT), Wvv <[hidden email]> 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.

Agreed

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

Hear, hear.

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.

--
Jón Fairbairn                                 [hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Flipped function application

Simon Peyton Jones
In reply to this post by Dan Burton

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

 

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:[hidden email]] On Behalf Of Dan Burton
Sent: 09 October 2013 20:23
To: Edward Kmett
Cc: [hidden email]
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 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 <[hidden email]> 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 <[hidden email]> wrote:

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

 

On Wed, Oct 9, 2013 at 9:51 PM, Wvv <[hidden email]> 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.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

 

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

 


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Milan Straka
In reply to this post by Andreas Abel
Hi all,

> -----Original message-----
> From: Andreas Abel <[hidden email]>
> Sent: 10 Oct 2013, 16:25
>
> 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 (&).

I am also in favor of adding flipped function application, with (|>)
my first choice.

I have been programming in F# for some time now and find the (|>)
operator quite useful and readable.

Cheers,
Milan Straka
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Roman Cheplyaka-2
In reply to this post by Jon Fairbairn
* Jon Fairbairn <[hidden email]> [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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flipped function application

Dan Doel
In reply to this post by Simon Peyton Jones
On Thu, Oct 10, 2013 at 4:46 AM, Simon Peyton-Jones
<[hidden email]> 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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123