# Proposal: Add (&) to Data.Function

69 messages
1234
Open this post in threaded view
|

## Proposal: Add (&) to Data.Function

 It is a common idiom to write a sequence of composed combinators in reverse order to the way they would be written with (\$) or (.). That naturally expresses the idea of the combinators as operations being  applied in the given order. This comes up so often, and is commonly used so many times in a single expression, that Control.Arrow.>>> is far too wordy, and even a two-  character operator is awkward. Surprisingly, until recently the operator (&) was still not used in any of the popular libraries, and its name naturally expresses the idea we are  looking for. This operator has now been defined in the lens package. We hereby propose to move it to its natural home for more general use, Data.Function. As in the lens package, we define the operator as a flipped version of  (\$), but with slightly higher precedence for better interaction with (\$), and with left associativity. This definition has already proven useful and convenient even in the presence of the large  and varied corpus  of combinators and operators in the lens package. (There it was formerly known as (%), but that clashed with the usual meaning of (%) from Data.Ratio.) infixl 1 &  (&) :: a -> (a -> b) -> b a & f = f a {-# INLINE (&) #-}Discussion period: 2 weeks Thanks,Yitz _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 Just to bring up some prior art, from what I've heard, F# calls this |>. In Clojure the -> function takes a value and a series of functions, and applies them in order from left to right, e.g. (-> 5 zero? not) ;;=> true. Obviously, In OO languages, this is usually accomplished by chaining calls foo.bar().baz().quux(). I agree that Haskell should provide this idiom. I find & to be a strange name for it, but to be honest, it's no stranger than \$ so I say go for it. I would suggest | to mimic the unix pipe, but this obviously clashes with Haskell guard syntax. I think |> is a reasonable name, but Data.Sequence has already claimed it. -- Dan BurtonOn Tue, Nov 20, 2012 at 9:59 AM, Yitzchak Gale <[hidden email]> wrote:>>  It is a common idiom to write a sequence of composed combinators in >  reverse order to the way they would be written with (\$) or (.). That>  naturally expresses the idea of the combinators as operations being>  applied in the given order.>>  This comes up so often, and is commonly used so many times in a single >  expression, that Control.Arrow.>>> is far too wordy, and even a two->  character operator is awkward.>>  Surprisingly, until recently the operator (&) was still not used in any >  of the popular libraries, and its name naturally expresses the idea we are >  looking for. This operator has now been defined in the lens package. We>  hereby propose to move it to its natural home for more general use,>  Data.Function.>>  As in the lens package, we define the operator as a flipped version of >  (\$), but with slightly higher precedence for better interaction with>  (\$), and with left associativity. This definition has already proven>  useful and convenient even in the presence of the large  and varied corpus >  of combinators and operators in the lens package. (There it was formerly>  known as (%), but that clashed with the usual meaning of (%) from>  Data.Ratio.)>>  infixl 1 &>  (&) :: a -> (a -> b) -> b >  a & f = f a>  {-# INLINE (&) #-}>> Discussion period: 2 weeks >> http://hackage.haskell.org/trac/ghc/ticket/7434 >> Thanks,> Yitz>> _______________________________________________> Libraries mailing list> [hidden email]> http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 On Tue, Nov 20, 2012 at 9:19 AM, Dan Burton wrote: I agree that Haskell should provide this idiom. I find & to be a strange name for it, but to be honest, it's no stranger than \$ so I say go for it. I would suggest | to mimic the unix pipe, but this obviously clashes with Haskell guard syntax. I think |> is a reasonable name, but Data.Sequence has already claimed it. I also like |> for the color of this shed, as there's prior art for it. > but Data.Sequence has already claimed it.We should use namespaces for these things instead of trying to come up with globally unique names (be they symbols). Trying to be globally unique doesn't scale to large codebases and eventually gives =>@@@@#\$>. ;) _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Yitzchak Gale I strongly support to have a standard, succinct notation for arg-fun-application.  Here are my two reservations about your proposal: 1. First, I think there should be a type class of functions, such that the application operator can be overloaded.  (Should also happen for \$). 2. (&) just has a too strong connotation of conjunction to stand for application.  ML has (|>) which also looks a bit similar to (>>=), see, e.g. http://isabelle.in.tum.de/repos/isabelle/file/Isabelle2011-1/src/Pure/General/basics.MLAndreas On 20.11.2012 17:59, Yitzchak Gale wrote: >   It is a common idiom to write a sequence of composed combinators in >   reverse order to the way they would be written with (\$) or (.). That >   naturally expresses the idea of the combinators as operations being >   applied in the given order. > >   This comes up so often, and is commonly used so many times in a single >   expression, that Control.Arrow.>>> is far too wordy, and even a two- >   character operator is awkward. > >   Surprisingly, until recently the operator (&) was still not used in any >   of the popular libraries, and its name naturally expresses the idea we are >   looking for. This operator has now been defined in the lens package. We >   hereby propose to move it to its natural home for more general use, >   Data.Function. > >   As in the lens package, we define the operator as a flipped version of >   (\$), but with slightly higher precedence for better interaction with >   (\$), and with left associativity. This definition has already proven >   useful and convenient even in the presence of the large  and varied corpus >   of combinators and operators in the lens package. (There it was formerly >   known as (%), but that clashed with the usual meaning of (%) from >   Data.Ratio.) > >   infixl 1 & >   (&) :: a -> (a -> b) -> b >   a & f = f a >   {-# INLINE (&) #-} > > Discussion period: 2 weeks > > http://hackage.haskell.org/trac/ghc/ticket/7434> > Thanks, > Yitz > > > _______________________________________________ > 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 Oettingenstr. 67, D-80538 Munich, GERMANY [hidden email] http://www2.tcs.ifi.lmu.de/~abel/_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Dan Burton On 20.11.2012 18:19, Dan Burton wrote: > I think |> is a reasonable name, but > Data.Sequence has already claimed it. Well, disown Data.Sequence.  Application is more important than some data type. Cheers, Andreas > On Tue, Nov 20, 2012 at 9:59 AM, Yitzchak Gale <[hidden email] > > wrote: >  > >  >  It is a common idiom to write a sequence of composed combinators in >  >  reverse order to the way they would be written with (\$) or (.). That >  >  naturally expresses the idea of the combinators as operations being >  >  applied in the given order. >  > >  >  This comes up so often, and is commonly used so many times in a single >  >  expression, that Control.Arrow.>>> is far too wordy, and even a two- >  >  character operator is awkward. >  > >  >  Surprisingly, until recently the operator (&) was still not used in any >  >  of the popular libraries, and its name naturally expresses the idea > we are >  >  looking for. This operator has now been defined in the lens package. We >  >  hereby propose to move it to its natural home for more general use, >  >  Data.Function. >  > >  >  As in the lens package, we define the operator as a flipped version of >  >  (\$), but with slightly higher precedence for better interaction with >  >  (\$), and with left associativity. This definition has already proven >  >  useful and convenient even in the presence of the large  and varied > corpus >  >  of combinators and operators in the lens package. (There it was formerly >  >  known as (%), but that clashed with the usual meaning of (%) from >  >  Data.Ratio.) >  > >  >  infixl 1 & >  >  (&) :: a -> (a -> b) -> b >  >  a & f = f a >  >  {-# INLINE (&) #-} >  > >  > Discussion period: 2 weeks >  > >  > http://hackage.haskell.org/trac/ghc/ticket/7434>  > >  > Thanks, >  > Yitz >  > >  > _______________________________________________ >  > Libraries mailing list >  > [hidden email] >  > http://www.haskell.org/mailman/listinfo/libraries>  > > > > _______________________________________________ > 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 Oettingenstr. 67, D-80538 Munich, GERMANY [hidden email] http://www2.tcs.ifi.lmu.de/~abel/_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Dan Burton "Haskell" called this operator (#) about 12 years ago - see Peter Thiemann's WASH and Eric Meijer and colleagues MS Agent scripting. I'd much prefer (#) if it didn't interfere with GHC's magic hash, I suspect the above authors were using Hugs... On 20 November 2012 17:19, Dan Burton <[hidden email]> wrote: > Just to bring up some prior art, from what I've heard, F# calls this |>. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Johan Tibell-2 On 20.11.2012 18:25, Johan Tibell wrote: > On Tue, Nov 20, 2012 at 9:19 AM, Dan Burton <[hidden email] > > wrote: > >     I agree that Haskell should provide this idiom. I find & to be a >     strange name for it, but to be honest, it's no stranger than \$ so I >     say go for it. I would suggest | to mimic the unix pipe, but this >     obviously clashes with Haskell guard syntax. I think |> is a >     reasonable name, but Data.Sequence has already claimed it. > > > I also like |> for the color of this shed, as there's prior art for it. > >  > but Data.Sequence has already claimed it. > > We should use namespaces for these things instead of trying to come up > with globally unique names (be they symbols). Trying to be globally > unique doesn't scale to large codebases and eventually gives =>@@@@#\$>. ;) +1 -- Andreas Abel  <><      Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY [hidden email] http://www2.tcs.ifi.lmu.de/~abel/_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Johan Tibell-2 On Tue, Nov 20, 2012 at 9:25 AM, Johan Tibell wrote: I also like |> for the color of this shed, as there's prior art for it. I also like |> due to it being already somewhat familiar. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Stephen Tetley-2 (#) is also used by the diagrams library, mainly for using functions as if they were "attributes".In the context of lens, this is discussed a bit here: https://github.com/ekmett/lens/issues/17 On Tue, Nov 20, 2012 at 9:31 AM, Stephen Tetley wrote: "Haskell" called this operator (#) about 12 years ago - see Peter Thiemann's WASH and Eric Meijer and colleagues MS Agent scripting. I'd much prefer (#) if it didn't interfere with GHC's magic hash, I suspect the above authors were using Hugs... On 20 November 2012 17:19, Dan Burton <[hidden email]> wrote: > Just to bring up some prior art, from what I've heard, F# calls this |>. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 And the results of the IRC discussion on lens: https://github.com/ekmett/lens/issues/100I do think that this looks nicer, for whatever reason.  While the mnemonic of "mod"ulus can suggest modify once you know that, (&) somewhat naturally suggests "and then" ... "and then".  I still prefer (#) for overall consistency and history, but other than its conjunction connotations, (&) is mnemonically better. It'll be funny to mix diagrams and lens code - (&) is used for sticking coordinates together for points / vectors - while (#) would stand in for (&). On Tue, Nov 20, 2012 at 10:17 AM, Michael Sloan wrote: (#) is also used by the diagrams library, mainly for using functions as if they were "attributes".In the context of lens, this is discussed a bit here: https://github.com/ekmett/lens/issues/17 On Tue, Nov 20, 2012 at 9:31 AM, Stephen Tetley wrote: "Haskell" called this operator (#) about 12 years ago - see Peter Thiemann's WASH and Eric Meijer and colleagues MS Agent scripting. I'd much prefer (#) if it didn't interfere with GHC's magic hash, I suspect the above authors were using Hugs... On 20 November 2012 17:19, Dan Burton <[hidden email]> wrote: > Just to bring up some prior art, from what I've heard, F# calls this |>. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 & also means bitwise-and to most of the world's programmers, so it may be more confusing for beginners. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Michael Sloan I'm a strong +1 for accepting this proposal as it stands.I'm decidedly lukewarm / a weak -1 on switching it to (|>). Another popular color of this bikeshed, (#) as is used in diagrams, interacts very poorly with MagicHash and has a very high precedence that ruins it for most dsl purposes. We had it as (|>) in lens for a while and it didn't read well. It is often used in long compositions and the extra character adds up when chained several times.```-- >>> zipper ("hello","world") & down _1 & fromWithin traverse & focus .~ 'J' & rightmost & focus .~ 'y' & rezip -- ("Jelly","world") isoRules = defaultRules   & handleSingletons .~ True   & singletonRequired .~ True   & singletonAndField .~ True ```Both of those examples read much better with & than (|>). We had switched to % from (|>) to be consistent with the other (+=) (*=) operators where (%=) was being read as 'mod-equals' as a bit of a pun, and could be seen as the application of the % operator to the target.  However this led to issues with a vocal minority who objected to it changing the meaning of 4 % 3 on lambdabot when combined with NumInstances.We converted to (&) because of its incredible terseness and general lack of use across hackage. For DSL purposes, to me it is key that this operator be as succinct as possible and (&) is remarkably underutilized in haskell libraries today, due to the fact that (|) is taken by syntax, and our C-inspired brains tend to pair them. -EdwardOn Tue, Nov 20, 2012 at 1:27 PM, Michael Sloan wrote: And the results of the IRC discussion on lens: https://github.com/ekmett/lens/issues/100 I do think that this looks nicer, for whatever reason.  While the mnemonic of "mod"ulus can suggest modify once you know that, (&) somewhat naturally suggests "and then" ... "and then".  I still prefer (#) for overall consistency and history, but other than its conjunction connotations, (&) is mnemonically better. It'll be funny to mix diagrams and lens code - (&) is used for sticking coordinates together for points / vectors - while (#) would stand in for (&). On Tue, Nov 20, 2012 at 10:17 AM, Michael Sloan wrote: (#) is also used by the diagrams library, mainly for using functions as if they were "attributes".In the context of lens, this is discussed a bit here: https://github.com/ekmett/lens/issues/17 On Tue, Nov 20, 2012 at 9:31 AM, Stephen Tetley wrote: "Haskell" called this operator (#) about 12 years ago - see Peter Thiemann's WASH and Eric Meijer and colleagues MS Agent scripting. I'd much prefer (#) if it didn't interfere with GHC's magic hash, I suspect the above authors were using Hugs... On 20 November 2012 17:19, Dan Burton <[hidden email]> wrote: > Just to bring up some prior art, from what I've heard, F# calls this |>. _______________________________________________ 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
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Johan Tibell-2 They are already stymied by the fact that | is used as part of the syntax, so it isn't bitwise-or. =POn Tue, Nov 20, 2012 at 1:37 PM, Johan Tibell wrote: & also means bitwise-and to most of the world's programmers, so it may be more confusing for beginners. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Edward Kmett-2 On Tue, Nov 20, 2012 at 10:39 AM, Edward Kmett wrote: We converted to (&) because of its incredible terseness and general lack of use across hackage. For DSL purposes, to me it is key that this operator be as succinct as possible and (&) is remarkably underutilized in haskell libraries today, due to the fact that (|) is taken by syntax, and our C-inspired brains tend to pair them. That seems fairly convincing to me. Count me as a +1 on Yitz's original proposal of & *or* on |> instead, whichever wins in the court of popular opinion. I assume this will have the not-very exciting type of(a -> b) -> (b -> c) -> a -> c? _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Edward Kmett-2 >>>>> Edward Kmett <[hidden email]> writes: > We had switched to % from (|>) to be consistent with the other (+=) (*=) > operators where (%=) was being read as 'mod-equals' as a bit of a pun, and > could be seen as the application of the % operator to the target.  Yes, a strong positive in favor of & of |> is that it allows the lens library to offer the highly useful variants &= and &~, which have obvious (and related) meanings to someone using lens.  |>= and |>~ would get a bit awkward in comparison. -- John Wiegley FP Complete                         Haskell tools, training and consulting http://fpcomplete.com               johnw on #haskell/irc.freenode.net _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Bryan O'Sullivan On Tue, Nov 20, 2012 at 1:44 PM, Bryan O'Sullivan wrote: On Tue, Nov 20, 2012 at 10:39 AM, Edward Kmett wrote: We converted to (&) because of its incredible terseness and general lack of use across hackage. For DSL purposes, to me it is key that this operator be as succinct as possible and (&) is remarkably underutilized in haskell libraries today, due to the fact that (|) is taken by syntax, and our C-inspired brains tend to pair them. That seems fairly convincing to me. Count me as a +1 on Yitz's original proposal of & *or* on |> instead, whichever wins in the court of popular opinion. I assume this will have the not-very exciting type of(a -> b) -> (b -> c) -> a -> c? (&) :: a -> (a -> b) -> b it is just  flip (\$)>>> ("hello","world")  &  _1.traverse %~ toUpper  & _2 .~ 42("HELLO",42)could be written _2 .~ 42 \$ _1.traverse .~ toUpper \$ ("hello","world")but that goes in the opposite direction of the corresponding code for working with the state monad with lenses: foo = do   _1.traverse %= toUpper   _2 .~ "42"-Edward _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by John Wiegley-3 On 20.11.2012 19:46, John Wiegley wrote: >>>>>> Edward Kmett <[hidden email]> writes: > >> We had switched to % from (|>) to be consistent with the other (+=) (*=) >> operators where (%=) was being read as 'mod-equals' as a bit of a pun, and >> could be seen as the application of the % operator to the target. > > Yes, a strong positive in favor of & of |> is that it allows the lens library > to offer the highly useful variants &= and &~, which have obvious (and > related) meanings Well, the obvious meaning of &= is bitwise-and-with, like in    x &= 0xff7f; isn't it? ;-) > to someone using lens.  |>= and |>~ would get a bit awkward > in comparison. The symbol |> combines the pipe | with an arrow > indicating the direction of information flow.  And it is used in ML already.  Hard to beat. -- Andreas Abel  <><      Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY [hidden email] http://www2.tcs.ifi.lmu.de/~abel/_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by John Wiegley-3 On Tue, Nov 20, 2012 at 10:46 AM, John Wiegley wrote: Yes, a strong positive in favor of & of |> is that it allows the lens library to offer the highly useful variants &= and &~, which have obvious (and related) meanings to someone using lens.  |>= and |>~ would get a bit awkward in comparison.I don't think embedding APL in Haskell should be a guiding principle. ;) _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries
Open this post in threaded view
|

## Re: Proposal: Add (&) to Data.Function

 In reply to this post by Andreas Abel >>>>> Andreas Abel <[hidden email]> writes: > Well, the obvious meaning of &= is bitwise-and-with, like in >   x &= 0xff7f; > isn't it? ;-) I realize this is tongue-in-cheek, but & is not universally the "bit-wise and" operator.  In the POSIX shell saying "foo & bar" means to start processing foo asynchronously and then run "bar".  But that also breaks the piping analogy lens is using & for, so hmm... I think |>= and |>~ would just be unfortunate, and lens is likely to be one of the biggest users of this new operator (at least at this point in time). -- John Wiegley FP Complete                         Haskell tools, training and consulting http://fpcomplete.com               johnw on #haskell/irc.freenode.net _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries