Closed nikita-volkov closed 4 years ago
I wish I could use >>
, but one of Flow's design goals is to not conflict with the Prelude. I'm aware that it conflict with other things, like semigroupoids
as you point out. Even |>
conflicts with containers
and lens
(and probably lots of others).
Another downside of >>
is that it's taken by syntax. If you enable the RebindableSyntax
extension, >>
is used when desugaring do
notation like do { this; that }
(which becomes this >> that
). This is true even if you also enable ApplicativeDo
, even though it seems like it should use *>
instead.
Another downside of
>>
is that it's taken by syntax. If you enable theRebindableSyntax
extension,>>
is used when desugaringdo
notation likedo { this; that }
(which becomesthis >> that
). This is true even if you also enableApplicativeDo
, even though it seems like it should use*>
instead.
Didn't realise that. That is unfortunate.
Still, I would vote for doing the switch, since I consider RebindableSyntax a misfeature altogether, but then I'm stepping into the dark area of opinions. So I'm only saying that to express a vote for doing the switch. Ideally I'd do a poll across the userbase, but I have no idea on how to arrange it.
In a vacuum, I think >>
is a better choice than .>
. But I don't think I'm going to change this. In addition to what I said above, two main reasons:
Flow has used .>
since the beginning. There needs to be a pretty compelling reason to make a breaking change, and I feel like the motivation here isn't that compelling.
Conflicting with the Prelude. If Flow switched to >>
, you'd have to deal with the conflict, probably by saying import Prelude hiding ((>>))
. I want Flow to have the lowest friction possible, which in my mind is import Flow
.
I understand the motivation of avoiding the conflict with Monad's
>>
, but then it's already completely replaced by*>
since the Monad-Applicative proposal, so it can simply be hidden in the import of Prelude. Also the alternatively chosen.>
still goes in conflict with a common idiom from the "semigroupoids" package". This all makes the conflict avoidance argument weaker than it initially might have been.Using
>>
for function composition, OTOH, would further support the following argument from the documentation, since it is an idiom in the Elm language: