search

haskell / core-libraries-committee

95 stars 15 forks source link

Add the '|>' pipe operator #78

Closed chshersh closed 2 years ago

chshersh commented 2 years ago

Proposal

Add the |> pipe operator to the Data.Function module, similar to the already existing &:

infixl 0 |>
(|>) :: forall r a (b :: TYPE r). a -> (a -> b) -> b
x |> f = f x
{-# INLINE (|>) #-}

⚠️ There's a difference between |> and &: & has fixity infixl 1 while I propose for |> to have fixity infixl 0 (same priority as $). Having the same priority results in a compilation error when using both $ and |> together in a single expression. This is intentional because the flow can be extremely confusing. For example, when writing f $ x |> g (or f $ x & g currently) it's not immediately clear from just looking at the code whether it's g (f x) or f (g x).

ℹ️ I'm proposing to add this operator only to the Data.Function module and not Prelude to avoid massive breaking changes which are not justified at this point.

Motivation

Haskell is one of the oldest Functional Programming languages that are still actively used nowadays. It inspired multiple features in many other programming languages. And I believe it's time for Haskell to take expiration from more modern FP langs.

Specifically, the pipe application operator |> (and sometimes <|) is popular in other FP languages while Haskell remains almost the only language that uses $ and &.

These are quite popular languages that use or want to add <| or |> (the list might not be exhaustive):

In fact, Haskell itself has several libraries that reimplement these operators:

And some libraries reimplement |> in their internals:

Here are some people on Twitter who like using the flow library or forward style of application:

According to the Haskell2010 report, one of the Haskell goals is:

  1. It should reduce unnecessary diversity in functional programming languages.

I strongly believe that having $ and & while the rest of the world uses <| and |> is exactly that unnecessary diversity, so adding these two operators to base will help to reduce this while not conflicting with other goals (and, in fact, it might even help! Lots of people find $ and & confusing for various reasons, having <| and |> can improve Haskell teaching and learning experience).

JakobBruenker commented 2 years ago

typo:

already existing & and &

probably should be "$ and &".

chshersh commented 2 years ago

@JakobBruenker Thanks! Fixed 🤗

tomjaguarpaw commented 2 years ago

& is a much more recent addition to base than $. Does anyone know why |> wasn't chosen instead of &? I think that information is important to take into consideration.

chshersh commented 2 years ago

@tomjaguarpaw The (&) operator was added in this commit 8 years ago. There's also a discussion on the issue GHC tracker.

The discussion contains a link to the libraries mailing list archive that discusses adding (&):

Everyone is welcome to read it. This is a really long thread with lots of bikeshedding 🚲 🖌️

I've read through the thread and below are the points against |> I've found:

There were arguments for other operators and many people were against adding the reverse application operator in that thread but I'm highlighting only |>-related arguments here.

The above thread contains only the opinions of various people. Apparently, the decision was made by vote of the previous CLC boards but it wasn't public.

tomjaguarpaw commented 2 years ago

Fantastic summary, thank you.

Kleidukos commented 2 years ago

Thank you for opening this proposal, @chshersh !

I remember when I switched from Elixir to Haskell, and tried to keep my idiom of using (|>) for data pipelines. I tried to re-use (|>) while writing this comment to remind me of what had failed in terms of ergonomics (I do recall that the order of the arguments declared by HoFs could prove problematic), but actually I can't seem to hit problematic cases.

It would indeed be worth integrating (|>) in base, and maybe (|>>) for the functorial version. :)

alt-romes commented 2 years ago

Funnily enough, I just came across |> in GHC.Data.TrieMap https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Data/TrieMap.hs#L105

(|>) :: a -> (a->b) -> b     -- Reverse application
x |> f = f x
mixphix commented 2 years ago

Regarding the Data.Sequence clash, most of the containers modules are imported with some sort of qualification. To me, it wouldn’t seem out-of-place to qualify its (|>) if the need for the one from this proposal should arise in the same module. And since it’s not an outright replacement for (&), the latter would remain an option.

This helps new-to-Haskell users as well as providing slightly-more-intuitive symbols for these operators than the existing ones. Thanks for the proposal, I’m excited for the MR!

dsyme commented 2 years ago

For those into history giggles, the origins of |> via Tobias Nipkow and Larry Paulson are documented in the paper at https://fsharp.org/history and in the blog post at https://docs.microsoft.com/en-us/archive/blogs/dsyme/archeological-semiotics-the-birth-of-the-pipeline-symbol-1994

int-index commented 2 years ago

As much as I dislike $, it is used so pervasively in Haskell that you’re not going to phase it out. And having both $ and <| (and neither of them deprecated) sounds worse than having just one of those.

mixphix commented 2 years ago

I remember there being some curfuffle around GHC 7 about special compilation rules for ($). Have those become “naturalized” in the compiler?

JakobBruenker commented 2 years ago

I remember there being some curfuffle around GHC 7 about special compilation rules for ($). Have those become “naturalized” in the compiler?

The accepted & implemented [Quick Look Impredicativity]() proposal says

Currently, GHC contains a hard-coded typing rule for ($) which ensures that f $ e works even when ($) would need to be impredicatively instantiated. The million dollar question is: can we drop this special case from the compiler?

Yes, we can. This also means that other combinators such as (&) or (.) no longer are second-class with respect to impredicativity.

However, to maintain backward compatibility, we propose to retain the special behaviour of ($) in one respect: applications of ($) will always be treated as if -XImpredicativeTypes is on. Why? Because if not, many existing program (which rely on the magical treatment of ($), without any extension flags) would suddenly fail to typecheck. For example, this code compiles today without extensions:

> import Control.Monad.ST
> runST $ return 0
0

If it is to continue to typecheck without extensions, we must switch on Quick Look for applications of ($). However, rather than a magical ad-hoc rule, the new treatment of ($) will be fully covered by the Quick Look specification.

I would also note that this special behavior becomes less critical when you consider that -XBlockArguments with do can usually be used instead.

emilypi commented 2 years ago

It's relatively harmless to add these, and I wouldn't block their addition to base.

However, just to set expectations, as much as I can appreciate wanting conformity with other languages for onboarding's sake, the pipe operators are never going to enjoy the same level of adoption as the existing operators. The fact that there exists an old and pervasive hierarchy of useful $ and &-based mnemonics (see: $>, <$, <$>, <$$>, $$, <&>) that the pipe operators have no hope of fitting into due to clashes with Alternative means the buck stops at the relatively inconsequential use case of "apply function to thing". That in and of itself doesn't quite meet my personal Fairbarn threshold.

A library flow implements these operators in Haskell.

You should evangelize flow and have people use that? I see 9 packages that use it in the wild, of which, half are Taylor's. That doesn't strike me as a pervasive need.

treeowl commented 2 years ago

The fact that $ is infixr has always been kind of weird. Adding another right associative application operator ... why?

KristianBalaj commented 2 years ago

I like the idea of giving Haskell this touch. However, I agree with @int-index

Having both $ and <| (and neither of them deprecated) sounds worse than having just one of those.

I think that this would come with even more diversity in Haskell's code bases. So I would be for deprecating/removing those 2 older alternatives i.e. $, & to NOT give developers the choice of selecting what they like more in these cases.

tomjaguarpaw commented 2 years ago

The fact that $ is infixr has always been kind of weird

Why is it weird? You couldn't write f $ g $ h x for f (g (h x)) otherwise, so infixr seems to be the whole point of $!

nomeata commented 2 years ago

Maybe it might have been nice to start with |> and <|. But $ is used pervasively, so deprecating it for some other symbol is, it seems to me, far too much churn for little gain. Plus there is the the added value from the whole <$, $> and <$> algebra, so we'd be losing something in the process.

Overall it's a nice thought experiment and makes for a fun discussion of what-ifs, but I can't see it being practical.

treeowl commented 2 years ago

The fact that $ is infixr has always been kind of weird

Why is it weird? You couldn't write f $ g $ h x for f (g (h x)) otherwise, so infixr seems to be the whole point of $!

As someone once told me, the point of $ is its low precedence. The above is just f . g . h $ x. Of course, the typing magic of $ wouldn't work for that idiom, but $ Is older than such things.

chshersh commented 2 years ago

having both $ and <| (and neither of them deprecated) sounds worse than having just one of those.

Doesn't sound worse to me.

You should evangelize flow and have people use that? I see 9 packages that use it in the wild, of which, half are Taylor's. That doesn't strike me as a pervasive need.

I'm not evangelizing flow. But I want to add that having these operators in a separate non-standard package makes them more difficult to use.

Maybe it might have been nice to start with |> and <|. But $ is used pervasively, so deprecating it for some other symbol is, it seems to me, far too much churn for little gain.

I'm not proposing to deprecate $ and & and replace this. I'm proposing to add new operators in addition to existing ones. If anyone wants to deprecate the existing ones, they are free to open a new proposal in the future 🍀

When teaching Haskell, I found that people are struggling a lot with $. Therefore, I'm not even teaching & in my latest Haskell course for beginners and this worked out quite well.

Having both <| and |> gives an option to people to use these new operators instead of $ and &.

chreekat commented 2 years ago

Suggestion for modified proposal. All I've done is add Haddocks. :)

I have not attempted to double-check my Haddock markup. ;)


infixr 0 |>
-- | @x |> f = f x@.
--
-- @|>@ is a pipe operator, similar to @'(&)'@ but with different fixity to avoid
-- confusing mixing of @|>@ and @'(<|)'@ in the same expression.
-- 
-- While @|>@ and @'(<|)'@ are familiar in other languages, Haskell has a long
-- history of use of @'(&)'@ and @'($)'@ instead. Their use is currently
-- considered idiomatic. See also 'Data.Functor.(<$>)', 'Data.Functor.(<&>)',
-- pervasive use of @&@ in lens code, etc.
(|>) :: forall r a (b :: TYPE r). a -> (a -> b) -> b
x |> f = f x
{-# INLINE (|>) #-}

infixr 0 <|
-- | @f <| x = f x@.
--
-- @<|@ is a function application operator. It is a synonym for @'($)'@, which
-- is considered idiomatic. See @'(|>)'@ for more details.
(<|) :: forall r a (b :: TYPE r). (a -> b) -> a -> b
f <| x =  f x
{-# INLINE (<|) #-}
```haskell
gallais commented 2 years ago

@philipschwarz The whole argument in these slides is based on the fact that code written using |> is (I quote) "more understandable" but that statement is not backed by any study AFAICT from the slides. I suspect it's mostly a matter of education (I doubt most people with a maths background find outer-first expressions troubling) and practice.

int-index commented 2 years ago

Doesn't sound worse to me.

How come you are citing “unnecessary diversity” (i.e. variation) across functional languages as motivation, yet you’re perfectly fine with unnecessary variation within a single language? If base provides both $ and <|, you must be prepared to answer: which one is idiomatic Haskell? And when you have the answer, the other option must be phased out. Otherwise it’s just unnecessary variation.

People can write tutorials with the help of pipe operators instead and such tutorials will be more helpful to other developers already familiar with these operators from other languages

No. Those tutorials will be less helpful, because by the time someone completes this tutorial, they will be unaware of $ (or at least not used to it), which is what the majority of Haskell code uses, and they will have a harder time reading actual code that is out there on GitHub, Hackage, etc. The only way you could change that is to have a deprecation plan for $.

I'm proposing to add new operators in addition to existing ones. If anyone wants to deprecate the existing ones, they are free to open a new proposal in the future

Well, thank you for the permission. But it has to be a single proposal or we’d end up in a place that is worse than what we started with.

JakobBruenker commented 2 years ago

I doubt most people with a maths background finds outer-first expressions troubling

I don't find outer-first expressions hard to understand, but I find that going in the opposite way is usually easier to read and faster to write, because we read and write the rest of Haskell from left to right: If code is written as an outer-first expression, I have to read from left-to-right until I get to the expression, find its end, read backwards (while reading each subexpression still from left to right), and then jump to its end again.

If you think about data being processed in a pipeline-style fashion while writing code this often means writing the argument first, going back, writing the first function that will be applied, going back again, writing the second function, and so on.

I haven't noticed this becoming better with practice.

nomeata commented 2 years ago

Sometimes outer-first is easier to read:

when (some conditions) $ this >> that >> even more code

is “clearly” better than

this >> that >> even more code & when (some conditions)

I do agree that for some function applications, those with a data-pipeline-style feel to them, argument-first can be easier to read.

But I don’t think we need to discuss whether function first or value first is better, as we do have both $ and &. The question here is merely whether <| and |> are better names for these operators, and if they are, if they are so much better to warrant a change.

tomjaguarpaw commented 2 years ago

People can write tutorials with the help of pipe operators instead and such tutorials will be more helpful to other developers already familiar with these operators from other languages

How useful to tutorial writers is it to have these pipe operators in Data.Function, compared to having them (also) in Prelude?

I'm not proposing to deprecate $ and & and replace this. I'm proposing to add new operators in addition to existing ones. If anyone wants to deprecate the existing ones, they are free to open a new proposal in the future

Sure, but we must consider whether the proposal is stronger if it also proposes deprecating $ and &. Deprecating long-standing operators has huge downsides, of course, but the fragmentation introduced by having two ways to get exactly the same functionality also has huge downsides.

Qqwy commented 2 years ago

This is quite the interesting proposal!

As someone who is switching frequently between Haskell, Elm and Elixir, I find myself adding |> to my Haskell projects to increase readability and consistency between codebases. I think that the indication of direction which |> and <| have (and & and $ lack) should not be understated. IMHO this might be more important than existing mnemonics for the family of $ and &-like operators which already exist in the Haskell ecosystem.

Personally I am in favour of phasing out $ and &, even though this might be a very difficult task.

I have some interesting counter-arguments for some things which were said above. Hopefully without too much :bike::hut::paintbrush: :

Is code more natural understood left-to-right or right-to-left (data-first or function-first)?

Discussing that is a bit of sidetrack, as it is about the difference between $/<| and &/|> rather than the difference between $/& and <|/|>. But really briefly, I think a more important underlying point is:

But now to the real stuff:

Functorial versions: $ and & are lifted as <$> and <&> which look better than <<|> and <|>>

Maybe? This is of course quite subjective. I would not be averse to adding <<|> and <|>> but I understand people being divided on this.

<| and |> however definitely (i.e. this is less subjective) do align (more) nicely with

which I would value stronger.

<| and |> clash with <|> from Alternative

I do not agree. Personally I like/prefer the similarity between the operators. One could say that <|> 'works like <| and |> except that there is no direction'.

The mnemonic of $ and <$> extends to <$$>, $$, $>, <$

Where do we decide as a community that something should be given a function name and not an operator? Names convey some meaning of their own, and can more easily be searched for online. Since Haskell allows to make any arity-2 function infix by surrounding it with backticks, maybe we could recommend doing this more often?

chshersh commented 2 years ago

How useful to tutorial writers is it to have these pipe operators in Data.Function, compared to having them (also) in Prelude?

As a tutorial writer, I can say having them in Prelude is more useful but having <| and |> in Data.Function is significantly more useful than in e.g. external package because you can just add a single import to bring these operators in scope.

Usually, it makes sense to explain imports quite early in a Haskell course (e.g. by using sort as an example). But explaining external packages requires readers to focus on the infrastructure side of things more when they want to focus on actually learning the language. We shouldn't underestimate learning advantages of things being in base or even core libraries. Being able to just import and use stuff without learning about packages makes things so much easier!

gbaz commented 2 years ago

I confess the motivation for tutorials leaves me cold. This is because it is not idiomatic haskell to write long chains of "$" nor should it be idiomatic to write long chains of "|>" or "<|". It is idiomatic to use "$" very sparingly and to write long chains using function composition, which is dot. As I recall, writing chains with application rather than composition makes a certain degree more sense in languages with strict evaluation. But we are not in such a language, we are in Haskell! And I have always learned, coded, and seen "mature" code from others that prefers dot, since it is more equational and compositional.

So the idea of having operators that more naturally lend themselves to be used in long chains of applications doesn't make sense to me to go in base for educational purposes, when for educational purposes classical practice has been "avoid long chains of application and instead use chains of composition (perhaps terminated with a single application)".

parsonsmatt commented 2 years ago

I'm weakly :-1: - I'd use hlint to ban them in all of my projects (like many other things in base), and overall I think "blessing" these is a Bad Idea, but I don't care enough to make a stink about it, and base is mostly a trashfire anyway.

These functions already exist in flow and anyone that wants them is free to depend on flow.

As a tutorial writer, I can say having them in Prelude is more useful but having <| and |> in Data.Function is significantly more useful than in e.g. external package because you can just add a single import to bring these operators in scope.

The pedagogical advantage of incorporating directly into base seems Bad to me, and here's why: Haskell pedagogy should be about learning to write and read idiomatic Haskell. |> and <| are not idiomatic Haskell, and tutorials should not cover them, except as analogy - something like,

If you're familiar with <| and |> in other languages, then Haskell has them too. But they are not widely used, and instead we use $ and & to mean the same thing.

But any discussion of $ should also talk about how it's a Mostly Regular Operator, and how you can define it yourself. So if you're in the business of defining operators, then you can just define |> directly in your tutorial, and it's fine - in fact, it may even be more illustrative to have the definitions of these functions in the tutorial.

You could easily write a tutorial on finding |>, which would cover Hoogle type search and then adding dependencies to a project. This would have real pedagogical value in actually working with Haskell-as-Haskell, and not "Trying to write Haskell-as-Elixir."

So given all the downsides and alternatives to |> in base, I don't think it's worth the tiny upside.

ocharles commented 2 years ago

|> and <| are not idiomatic Haskell

This seems to suggest that was is idiomatic is immutable - should it be? We certainly can't change it if we don't add things to decide that we want to exist in a different space.

parsonsmatt commented 2 years ago

This seems to suggest that was is idiomatic is immutable - should it be?

I didn't intend any suggestion to that effect. I'm simply stating that, as of now, $ is idiomatic and |> is not.

If that changes, and |> becomes idiomatic Haskell, then I wouldn't mind putting it in base.

We certainly can't change it if we don't add things to decide that we want to exist in a different space.

I'm having a hard time parsing this. Do you mean, "We certainly can't change [what is considered idiomatic Haskell] if we don't add things [to the base library] to [try out the new space so that we can] decide that we want to exist in a different space." ?

I would disagree with that claim. Many Haskell idioms are not in Prelude or base at all. And many of the idioms in base or Prelude were devised outside of it, and included in base when they reached sufficient saturation.

The IHP Project uses |> pervasively instead of $. If that project grows in scope and prominence in the greater Haskell community, then |> will become idiomatic Haskell without ever being included in base.

I think that idioms should flow from the community into base. I do not think we should be putting things in base to "trial" how well they'd work as potential idioms. If we wanted to go down that road, we'd be opening the door for many other things to attempt to get into base.

According to Hackage, flow has 58 downloads in the last 30 days. Let's use that as a proxy for "Should a thing be incorporated into base for trial idiom inclusion?" Well, then we'd need to strongly consider accepting rio, which has 303 downloads in the last 30 days, or mtl, which has 246 downloads in the last 30 days. But then, heck, why not persistent, with 1,556 downloads in the last 30 days?

Well, clearly, persistent is not a "style" thing, so it makes sense that it doesn't get included in base. But rio and mtl are both a "style" for structuring applications. mtl is widely considered idiomatic Haskell, and rio is rapidly gaining mindshare.

emilypi commented 2 years ago

@philipschwarz Kindly requesting you stop posting gigantic images of your tutorials when just a link would suffice. It's disruptive.

philipschwarz commented 2 years ago

@emilypi sure, in fact I suspect even the posts might prove disruptive to some, so I just deleted them

ocharles commented 2 years ago

Sorry @parsonsmatt, that was a very wishy-washy sentence I posted from my phone. However, your interpretation is correct, and I appreciate your response!

Greg8128 commented 2 years ago

& is a much more recent addition to base than $. Does anyone know why |> wasn't chosen instead of &? I think that information is important to take into consideration.

As pointed out by @chshersh , one reason is that it was already used by lens. My best guess as to why the lens authors chose & is that it sort of looks like a horizontally flipped $.

permeakra commented 2 years ago

What's wrong with already existing >>> and <<< from Control.Category that serve same purpose but are more generic?

tomjaguarpaw commented 2 years ago

They are composition, not application.

JakobBruenker commented 2 years ago

right, (>>>) is to (|>) what (.) is to ($)

niekvandepas commented 2 years ago

Having come to Haskell from Elixir, I do find myself frequently reaching for |>. I'd say that the improved readability/understandability of piping plus the consistency with other languages outweigh the (IMO minimal) downside of adding another operator for people to 'learn'. From what I've seen, many codebases are full of custom operators and infix functions anyway, and many operators are much less readable/intuitive than this proposal (looking at you, <$>).

permeakra commented 2 years ago

They are composition, not application.

Ah. Then I will point that this adds more operators to an already rather diverse zoo of related operators. We already have a limited form of left-to-right application in the form of dot syntax for records. Furthermore, there are multiple left-to-right applications in optics implementations packages and in particular a ^. to f ≡ f a syntax in lens package. Shouldn't base aim for a more generic and unified approach?

blackheaven commented 2 years ago

I'm in not in favor of this proposal.

As a code maintainer, having many options of doing the same thing reduce coherence of a code base (ie. having a mix up of $ and & already make the code reader's work harder).

As a teacher, I have noticed that >>= is far harder for my students to grasp (it's easier for then to use it as flatMap).

I don't find unreasonable for a(n old) language to have naming specificities.

I would find it more idiomatic to have a custom Prelude (many projects have), rather than overloading base or Prelude.

ParetoOptimalDev commented 2 years ago

It's not what programming languages do, it's what they shepherd you to.

I urge everyone to ask themselves:

What does |> Shepherd us to?

Left to right Unix style pipe operators and thinking in a bottom up fashion. This is the reverse of the typical top down approach of . and $ status quo.

I see this less as "just add two simple operators to help newbies" and more "lets use the more commonly understood piping mental model and bottom up design style that goes with it.

If |> becomes idiomatic I believe that will mean less usage of and thinking in terms of composition with ..

People may not write f $ g $ x over f . g $ x, but they probably would write f |> g |> x over using composition, especially newcomers.

Aside: I bet that most would never even use <|.

Overall I feel like the mental model that goes along with |> will be:

I'm skeptical of things more approachable by familiarity being added to Haskell, especially when the cost is a much worse mental model to think with.

mulderr commented 2 years ago

I was initially rather against because including something new in base is a kind of statement to end users and in this case it's not quite clear what that statement is - the proposal doesn't really discuss consequences of having both sets of operators in base. But after some thought I'd be weakly for, under the condition that it is clearly communicated both in the proposal and in the documentation that $ and &:

The last point being a soft suggestion from the powers that be that curate base, nothing more. If anyone wants to use alternatives for whatever reasons, then they are of course free to do so, as they always were.

My point is to cater to new people who, as is often the case, have too many options on the table and no guidance. When learning Haskell this is the thing I struggled with. Definitely not with $ or & - those are not even on the list. The ease of learning argument is kind of mute to me because it pales in comparison to other issues a new person will have to tackle.

As additional motivation, it was stated that in the context of learning materials "having these operators in a separate non-standard package makes them more difficult to use". I would hazard a guess this is because no one wants to touch the subject of package installation with a ten foot pole during the first few hours precisely because there are too many options with very non-obvious pros and cons and none of them are considered a safe default or standard across the community. We should be weary of introducing more dilemmas of this sort.

On the other hand, I can get behind this:

  • People who use several languages in a project (e.g. Elm for frontend and Haskell for backend) will have an option of having a more consistent multi-lingual setup and smoother onboarding curves.

Where "smoother onboarding" is unfortunately somewhat questionable for the reasons outlined above, but I do buy consistency with other languages - if we can have that cheaply then why not. Seems like a small thing we can do and I'm fine with that as long as it's clearly communicated this it is not "blessed" in the same way as $ and &. It's merely a convenience measure that you may want to use, YMMV.

Let's give people the options they expect but also safe defaults and basic guidance.

endgame commented 2 years ago

I am against, because |> and <| are a dead end for newcomers. Newbies who do not move off |> and <| will miss the consistent visual language which has grown up around $ (and to a lesser extent &), and that limits their expressive power:

It seems reasonable for a package on hackage to provide |> and <| for people who really want them (e.g., people writing Elmish Haskell for interop).

schuelermine commented 2 years ago

I find |> as a fixity alternative good. I don't like the idea of a redundant <|.

Since $ is a special case for type checking without impredicative polymorphism, should <| and |> be, too? Or has that special case been removed since Quick Look was implemented in GHC?

emilypi commented 2 years ago

I would argue the utility of |> and <| would be severely limited unless they were special cased in a similar way.

schuelermine commented 2 years ago

The intuition behind |> in most languages seems to be the UNIX pipe operator |. It seems to me this is not a good fit for Haskell because the correctest representation of that I can think of would actually be >>=.

tfausak commented 2 years ago

I am the author of the Flow library, which provides these operators and was mentioned in the proposal. When I released that library seven years ago, I announced it with a blog post. There was plenty of discussion on Reddit at the time, which prompted me to write another blog post. Both of my posts and the community's discussion are relevant here since nothing has fundamentally changed in the meantime.

As you might expect, I am in favor of this proposal.

chreekat commented 2 years ago

... which prompted me to write another blog post.

Hi @tfausak, I just noticed you quoted me in that followup post. After seven years, I can't remember if what I wrote was intended as a personal attack or not, but I apologize in any case!

To expand on my cryptic suggestion earlier on the thread, I'm in favor of this proposal, but I do think the documentation for the operators should point to the current widespread alternatives, and call them out as such. It can be a teachable moment. Newcomers can decide for themselves which style they prefer, and why.

arybczak commented 2 years ago

I'm strongly against this proposal, for reasons that @int-index and @parsonsmatt already highlighted.

If anyone wants to deprecate the existing ones, they are free to open a new proposal in the future

You know full well that such proposal is never going to be accepted, because deprecation of $ and & would mean breaking pretty much every piece of Haskell code already written.