Proposal: Add (&) to Data.Function

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Proposal: Add (&) to Data.Function

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

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

Dan Burton
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 Burton


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

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

Johan Tibell-2
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 =>@@@@#$>. ;)

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

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

Andreas Abel
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.ML

Andreas

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

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

Andreas Abel
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]
> <mailto:[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] <mailto:[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
Reply | Threaded
Open this post in threaded view
|

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

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

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

Andreas Abel
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]
> <mailto:[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
Reply | Threaded
Open this post in threaded view
|

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

Bryan O'Sullivan
In reply to this post by Johan Tibell-2
On Tue, Nov 20, 2012 at 9:25 AM, Johan Tibell <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Michael Sloan
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Michael Sloan
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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Johan Tibell-2
& 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
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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.

-Edward

On Tue, Nov 20, 2012 at 1:27 PM, Michael Sloan <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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. =P

On Tue, Nov 20, 2012 at 1:37 PM, Johan Tibell <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Bryan O'Sullivan
In reply to this post by Edward Kmett-2
On Tue, Nov 20, 2012 at 10:39 AM, Edward Kmett <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

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

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

Edward Kmett-2
In reply to this post by Bryan O'Sullivan

On Tue, Nov 20, 2012 at 1:44 PM, Bryan O'Sullivan <[hidden email]> wrote:
On Tue, Nov 20, 2012 at 10:39 AM, Edward Kmett <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

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

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

Johan Tibell-2
In reply to this post by John Wiegley-3
On Tue, Nov 20, 2012 at 10:46 AM, John Wiegley <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

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

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

Edward Kmett-2
In reply to this post by Johan Tibell-2
My major point was originally that code written with & 'reads' well if the person reads the operator as 'and' or 'and then', but with '|>' you have to mix metaphors involving pipes that don't quite exactly hold and further exacerbate the common complaint that Haskell has a ton of complex multicharacter operators that nobody knows how to pronounce.

On Tue, Nov 20, 2012 at 1:59 PM, Johan Tibell <[hidden email]> wrote:
On Tue, Nov 20, 2012 at 10:46 AM, John Wiegley <[hidden email]> 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



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