If I were implementing it, I would make the previous result and stack contents read-only so that it's conceptually the same as the pipeline operator except that it allows inspecting the intermediate value.
Haskell has $ operator (simple application operator but with low precedence—think open bracket that closes implicitly at the end of expression). While it makes your example a bit more verbose:
> f $ g $ h x
it also allows one to pass multiple arguments in an intermediate function call, e.g.
Ruby doesn't _ that way (IRB, the bundled Ruby REPL, does)—Ruby actually does have special handling for _ as a variable, but that's to suppress duplicate definitions n warnings to allow it to be used as a don't-care argument.
I think Python is similar, where it is special-cased in the REPL, not a general language feature.
There's also ReasonML for those looking to scratch the itch sooner.
Also, don't be turned off by the sea of comments. Pick one, they are all great. but yes ML language enthusiasts can be a bit overenthusiastic, but I don't fault them for that. They are all anxious to spread the gospel of ML. The Reason community on discord is excellent, one of the best I have had the pleasure to be a part of.
Can't us ML language enthusiasts just all get along? We're all aware of how vastly superior ML languages are for domain modeling and language readability :).
The person you're responding to has it out for Elm. I recognize their username from an Elm thread where they spent their afternoon hating on it with punchlines like "it's designed for stupid people" and "nobody can take Elm seriously."
For the record, this doesn't exist in PureScript by default (the default is the symbol `#`, which I don't find as pleasing on the eye). You need to define it:
import Data.Function as F
infixl 1 F.applyFlipped as |>
Wow, Purescript lets you define new operators and specify their type? (I assume infixl 1 is infix-left, what is the 1 for though)
That is really cool. I wish Haskell & Purescript weren't so difficult to grok, trying them has been on my todo-list for ages but they're so different than any other language.
Why do people credit the pipe operator to F#? OCaml has it too, and F# is based on OCaml. Did the pipe operator get added to F# first? (The OCaml docs say that the pipe operator first appeared in OCaml 4.01 [1], and I can't find out when it got added to F#.)
Attribution in most cases is given to where the person first learned of the concept, not per se, the historical accuracy of who came first with the concept.
After all, it should rightfully be attributed to the Isabelle/ML programming lanaguage[0][1]
I was thinking the same thing, although it would be useful to have a pipeline operator in Javascript. My first thought would be UNIX when I think of pipes, not F#.
It's times like these that make me realize how spoiled I am by ClojureScript...the -> and ->> macros basically give me a pipe operator, and have been in the language from its inception :)
I'm actually glad that this kind of composition is growing in popularity. Back when I did F# for a living, I loved that by using the pipe operator, you could get something more or less akin to a fluent interface, without any direct coupling between the two composed functions, and without any gross intermediate variables. I have nothing against "regular" point-free composition or anything like that, but I do think that these pipe operators are easier to digest for a lot of purposes.
Those macros are just that, macros. Implementing them in any sexp-based language is trivial.
I think people are stuck in the "C MACROS ARE BAD" thinking. It is a really powerful feature. CLOS, the world's most flexible oo system, was conceived as a bunch of macros. Racket's pattern matching is really just a macro (that could almost be called a compiler). Useful things that can be syntactically integrated into a language as an afterthought, yet still look and feel first class.
No argument here; I'm a pretty big supporter of Lisps as a whole; most of my personal projects are done with Clojure (or ClojureScript) in no small part due to the power afforded to me by macros.
In fairness to a lot of people, I think that most of the folks in the "MACROS ARE BAD!!!" crowd are under the impression that C macros are the only way people do them, and assume that even Lisp macros are just are also just glorified text-expansion. I would be against macros too if that were the case.
I suspect that most of "MACROS ARE BAD!" folks only know Python or Java, and have never used a macro preprocessor, just like the "COBOL IS BAD!!" people of the past who had zero experience with Cobol.
> I would be against macros too if that were the case.
I wouldn't; even text expansion macros are useful, and can be done better than what is in C.
Using C preprocessing as an example criticize only textual/token macro expansion is still a strawman.
I had created a solution to scratch my itch while waiting for the pipe operator which even got a logo when it got more than a hundred stars, for anyone interested: https://github.com/egeozcan/ppipe (needs ts typings though)
This is a neat one. In my current project, I created a (non-lazy) pipe function that take a value and a bunch of functions, composes the functions, and applies the value.
pipe(2, add(2), square, n => n + 7) // -> 23
Nothing fancy but comes in handy at times.
What I really miss is something like the |> from Elixir. Maybe it's the same as F#, I don't know, but it automatically performs partial application, so that:
Enum.filter([1, 2, 3, 4], fn n -> n % 2 == 0 end)
also works like:
[1, 2, 3, 4] |> Enum.filter(fn n -> n % 2 == 0 end)
This is nice syntax, but since there are two competing proposals and they're collectively at stage 1, this isn't something anyone should really be using for nontrivial code, since there's a good chance either way that you'll be writing JavaScript that will never be valid.
I know this proposal has been sitting around forever, but it really can't come fast enough imho. I don't know how to help show my support for its inclusion, however. Can anyone help elucidate?
I decided to answer my own question and visit the tc39 website. The lazy answer is that you must be part of a company that is willing to pay ~$70000 to have a voice, and have access to your companies representative to tc39. There are other categories of members (like Mozilla), but here's the short list of "Ordinary members." More info at https://www.ecma-international.org/memento/members.htm
If you are part of one of these companies and interested in this proposal, it'd be super cool to see who you need to talk to to influence this decision.
It's worth reflecting on why the most popular language in the world has syntax so inflexible that a simple operator like this requires begging some ubercorp for a compiler change. Smalltalk had user-definable binary/infix operators in 1980. They didn't require you to muck around with the compiler at all.
Ironically, JavaScript has the extensibility mechanisms and object-oriented features inspired by Smalltalk that could allow for pretty much the same thing. However, most of the community doesn't seem to even realize that this is a possibility.
Yeah! As a hobbyI much around with scheme (mostly), Smalltalk (a couple of times a year) and factor (maintaining some old tools I wrote in it).
The result is that if I whine, I whine about the choice of language, not about how a particular part of a language sucks. Extensibility like that should be built in, and then probably mostly discouraged. If you really need to scratch an itch, you will be able to do so without resorting to what usually ends up as ugly, non-composable hacks.
Really? If you would try to do an effective Smalltalk implementation in WebAssembly, you would immediately see that WebAssembly is making things even much worse.
You can go talk to TC39 delegates in #tc39 on freenode right now (it will be kind of quiet for the next few days though since there is an in-person plenary and people are not looking at IRC as much). We also use https://es.discourse.group/ for async communication.
Also, many entities listed on Ecma's membership page are not there for TC39, and talking to people working for them will not get you anywhere.
Now, I understand how it might be desirable to NOT having to use Babel to run code, especially on Node. On the other hand, some amount of transpilation has become inevitable for js in the browser and I don't see this need going away soon, as JS evolves much quicker than browser adoption.
Yes, I know...but I live in TypeScript world where functional styles and types go together especially wonderfully. Babel solutions to TypeScript are messy and in some cases break the things I like about TypeScript. At least last I checked. But getting native TypeScript support is dependent on the feature actually making it into the official spec.
Been through that here, trying to get my whole dev env working nicely with both pipes and types. Very painful. I was surprised and a bit disappointed that pipelines seemed to be progressing years ago, then suddenly stalled. Nullish and optional chains are in ts already but pipelines aren't even on the horizon.
From what I hear from tc39 people, method extraction is one of the biggest must-haves holding this thing up. They want a nice way to bind contexts to an entry in the pipe. Ironically the difficulty of figuring this out for JS is keeping pipes out of TS, but it wouldn't be that hard a problem in TS which has ways to treat `this` as special already.
That, and the many competing proposals we already have. I'm fine doing an incremental rollout that doesn't need the placeholder `?` right now.
If I recall correctly, it's because the proposal[1] was last presented to committee in March 2018[2], and since then it's been essentially deadlocked as the committee members can't agree upon an "f#" style operator vs a "hack" style operator vs a "smart mix" of the two. Personally, I hate placeholder sigils and magic "context" variables (and hope they have no place in JS), so a simple "left operand becomes first argument in call to right operand" is all I'd really want.
Same - the context variables are really for method extractions (e.g. the many times people used to call Array.prototype.slice on something). It's be easy in TS since `this` is already treated as special in function-arg contexts.
I loved it, but came to an impasse when I had to decide between pipeline and TS. For a while I was running both a babel and TSC watch, where my babel build dir fed into the TSC watch. Dealing with two daemons when one/both screwed up, and needing to read errors in transpiled code, was annoying. What decided it was being unable to run prettier, since I could either use the babel parser for pipelines, or the tsc parser for the types. I'd be very happy if we could put pipelines back in and not break our tools and tax the two cores on my MacBook Air to the limit.
I always wondered why does it take such a long time to formalize this in Babel's specs. It seems something fairly unequivocally useful, but I guess its implementation has some major hurdles in JS.
Babel doesn't have a spec per se. They try to be compliant with the ECMAScript spec, but implement popular proposals behind presets or plugins. You can read about their relationship to ECMAScript and the TC39 committee on their blog: https://babeljs.io/blog/2018/08/27/7.0.0#babels-role.
Value of your comment being? It does not matter where it comes from, just that is cool, useful, readable and it might be a great idea to add it to JS, same as it is already in f#, oCaml, Elixir, etc etc etc.
Well, I'd say that "mass adoption" means it's in one of:
Javascript, Java, Python, C, C++, C#, PHP, Swift†, Ruby†, SQL†, Go†, VBA†, TypeScript†, Kotlin† and that's about it.
The languages with a dagger (†) are either niche languages or tied to a very specific (albeit very popular) platform.
Which one of them has the pipeline operator, especially in widespread use in libraries in its ecosystem? Personally, I don't know of any.
I'm not saying that what this blog post presents has achieved mass adoption, I'm just arguing that the pipeline operator for standard programming languages hasn't reached mass adoption, anywhere. I don't count Unix pipes as being the same thing as the pipeline operator, in this context ;-)
Probably the only mainstream language with mass pipeline usage is elixir. (And before you call it niche, pagerduty uses elixir, so your stack probably depends on it right now). Almost every significant code file of mine uses the pipe operator, and it's absolutely invaluable for debugging.
That's not really a good argument against calling it niche. A lot of numerical computing done from Python is actually run through Fortran and some of your OS is almost certainly written in raw assembly language. That doesn't mean that they aren't niche.
I enjoy the utility of this operator in Elixir but I'm not sure how I feel about including it in JS.
My fear is that JS is trying to be all things to all developers- it feels like we just added the `class` keyword for the OO inclined and now we're moving towards functional programming? Do we really want to move further away from the idea of idiomatic JS?
But who knows, maybe it will open the door to massive productivity and enjoyability gains with the language...
Classes require tons of work under the hood to work. In exchange, they add a confusing new concept of fields alongside protypes while also hiding the actual prototype inheritance to ensure future confusion.
The pipe operator is a super-basic transformation of the AST. In exchange, you get much easier to read "nested" functions. `foo(bar(baz(x))) --> x |> baz |> bar |> foo` is very easy to teach and very easy to understand.
Can't help but wonder about the maintainability of JS codebases with all this additional stuff, particularly with things that aren't part of the language spec like the pipe operator.
Oh my god, we should never allow people to have a little fun on their own blog and if they do, let’s call them childish and unworthy of finding work. /s
It’s just a meme, used correctly, what’s the problem? This isn’t the White House’s blog.
To me, that image was superfluous and likely to perpetuate the "boys club" appearance of tech.
Sure, the author can put whatever they want on their site. But why go to the trouble of writing something and then tossing in a Piss Off message to some of the readership?
I wrote something similar for Scheme - https://cons.io/reference/sugar.html#chain. It's interesting to see that other people came up with a quite similar solution, providing two modes: pass-directly, pass-by-variable. Does the JS version supports destructuring?
Your version is interesting too. For a while I also thought about the stop-when-false idea, but came to the conclusion that it should probably be another macro. Building an enough powerful, but easy macro, isn't that simple.
For those of you who work with Node, highland.js is another great route for composable programming. It has excellent support for Node streams, which has made it quite handy with Gulp especially!
What happens when you need to debug and see how the data looks at each stage of the transformation pipeline? Won't the debugger show this as a single step if you use the pipeline operator? It does look cleaner and means you don't have to spend time coming up with names for the intermediate results though.
The pipeline is still a set of function calls, despite the syntax sugar. You can think of x |> f |> g as g(f(x)). Even when written as a single line, a good debugger will let step through each function one at a time (as that is effectively how the system operates), and a great debugger will help you set breakpoints even "inside the line" to a specific point.
(Many debuggers already support that last bit of inserting breakpoints inside of lines instead of "at" lines, it's just not as obvious as the usual "click the spot to the far left gutter of the line you want". Sometimes it is something like a Right-Click on the specific part of the line and look for a command such as "Insert Breakpoint Here". It's something to learn if your chosen debugger supports today.)
The obvious tangent here, of course, is that many times when you might want to heavily use something like a pipeline operator you are likely working with something more abstract between function calls like an Iterator/Generator pattern (or an Observable pattern), and debugging those require different habits/tools as the "intermediate results" aren't directly interesting (an Iterator is "just" an object with a next() function, it's not an array of intermediately processed data). Learning to debug those patterns is its own skillset (whether or not you are using a pipeline function or a pipeline operator or old-fashioned function call syntax), but one common example is a function you'd add inside the pipeline often called something like a "tap". In that case you might "tap" in to the middle of a pipeline to log intermediate results. Something like:
https://stackoverflow.com/questions/3326826/language-history...
If we had that, then we could write: Which reminds me of PostScript, which lets you examine and manipulate the program's stack directly (the top of the stack is the previous result):http://www.ugrad.math.ubc.ca/Flat/intro.html
http://www.ugrad.math.ubc.ca/Flat/stack.html
If I were implementing it, I would make the previous result and stack contents read-only so that it's conceptually the same as the pipeline operator except that it allows inspecting the intermediate value.