I'm relatively an FP newbie, and I have a few questions.

1. I've never seen the "pipe" notation you talk about in any lang except bash, which is not an FP right? In which languages does "|" denote function application?

2. Aren't dependent types orthogonal to whether a language is functional? Just to make sure we're on the same page on what dependent types mean, I wanna give a example (a contrived one, sorry) of dependent types in Python.

    from typing import overload, Literal

    @overload
    def str_if_zero(num: Literal[0]) -> str: ...
    @overload
    def str_if_zero(num: int) -> int: ...
    @overload
    def str_if_zero(num: int) -> int | str:
        if num == 0:
            return "That's a zero"
        return num

Elixir, Elm, Ocaml, Haskell, and F# all have a pipe like operator for function composition (though the actual operator varies).

There's also a Stage 2 proposal for adding a pipe operator to JS[1]

[1]: https://github.com/tc39/proposal-pipeline-operator

Clojure has the -> macro:

https://clojuredocs.org/clojure.core/-%3E

It does the same thing, but it's much more awkward to use.

As a daily user of -> and ->>, I am curious what you find awkward about them.

You have to plan to use them in advance. With a pipeline operator you can figure out the command you want at one stage and then tack on another part of the pipeline without needing to go back and alter the way you began the line.

R also has it, if you count R as a functional language.

I think libraries are just as relevant as languages, and dplyr’s pipes are wildly popular and (more to the point) even idiomatic R at this point.

Actually base R has a pipe operator now. (I still use the dplyr pipe, just out of familiarity.)

R is a surprisingly functional language!

As does Julia

Got it. Thanks!

> which is not an FP right? > Aren't dependent types orthogonal to whether a language is functional?

You're correct and I think that's kinda the parent's point. I think what the OP is saying is that the much of the syntax ergonomics are orthogonal to FP, which means they don't have to be as weird/frustrating/unusual/insert preference/unergonomic as they are.

A good example is how piping vs nesting are different syntaxes for function composition: x|A|B|C vs C(B(A(x)))

The former might feel more comfortable, familiar, and left-to-right readable for someone new to FP. That said I think a few language do use piping. F# has |> and I think Clojure used >>> maybe? -- signed, humble java programmer.

> piping vs nesting are different syntaxes for function composition: x|A|B|C vs C(B(A(x)))

> The former might feel more comfortable, familiar, and left-to-right readable for someone new to FP.

C(B(A(x))) is the syntax introduced in school, but note that if you continue on in algebra the notation flips from C(B(A(x))) to x_{ABC}. Everyone agrees that it's easier to list the transformations in the order they happen.

Clojure has two primary macros for this, thread-first (->), and thread-last (->>).

They enable you to write pipe transformations and in my opinion make the code much more readable.

F# and Ocaml are good examples from my limited functional experience.

https://stackoverflow.com/questions/2177110/in-f-what-does-p...

Thanks!

Dependent types are not totally orthogonal of FP. They generally require immutability and function purity to work well and become extremely difficult to work with in the absence of those features.

See e.g. https://shuangrimu.com/posts/language-agnostic-intro-to-depe...

Yeah, type checking becomes undecidable otherwise and the compiler can also become vulnerable but Rust says they're going to try, so we'll see.

Well it's luckily a little better than that. Type checking doesn't have to be undecidable and the compiler doesn't have to be vulnerable because you don't have to execute any side effects in the compiler even if the code is meant to execute any side effects at runtime.

It's more that the utility of dependent types is generally restricted to functions that are pure and deal with immutable values, which means one possibility is to specially mark which of your functions are allowed to be used in a dependent type and which aren't. But the fragment of your program that can be used in dependent types is generally going to be a pure FP fragment.

Side effects aren't the only reason the compiler can be undecidable though. It depends on the type system, not just referential transparency. Look at Cayenne or ATS. Also, don't forget it's possible to still possible to DoS the system (although this is already more than possible with C++ and such, so what are we complaining about.)

Yeah, dependent types would be nonsensical for code that isn't functional. Marking which parts are and aren't is a good idea. Idris did something similar for totality checking. I think it'd be nice to have a system which differentiated between functions and procedures though.

> I think it'd be nice to have a system which differentiated between functions and procedures though.

That's essentially what 'IO' types are for (or finer-grained alternatives like 'Eff', etc.). At the value level, we have things like 'do notation', 'for/yield', etc.

  h(x).f().g() 

Is also very common and I would say it counts, especially if the language support something like extension methods.

> especially if the language support something like extension methods

Extension methods are a bit of a hack (although useful!); a cleaner approach is https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax although I've not personally used a language which supports it :(

I'm a big fan of UFC myself.

I don’t know if I would say it’s very common(?) but it was introduced as a named concept (“uniform function call syntax”) AFAIK in D and is also a feature of Nim

https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...

(2) No, dependent types are not the same as overloading. Basically it's when the type depends on the values; so like having a type for odd numbers or having an array that knows its length at compile time (for example to avoid array out of bounds exceptions at compile time)

1. Others have answered it well. Tons of languages have pipe operators. I used | in my example because I figured more readers will recognize bash piping than other notations.

2. Yes that's what I mean by dependent types, where types depend on values, like f(0): string and f(1): int. And yes, they totally are orthogonal. However, pure functional programming tends to lean on its type system more than other styles, in my experience. But then without dependent types, something as simple as loading a CSV gets hairy relative to something like pandas's pd.read_csv. Maybe others can go into why pure FP and static typing go so much together, but I gotta get back to work.

The pipeline operator |> exists in Elm[0]. It is available in bash as & and the popular (in my limited experience) package flow[1] also implements it as |> for readability. It is a proposed addendum to Javascript[2] but I have no idea how seriously the JS powers-that-be are taking that.

The example you gave of Python doesn't have tagged union. I really don't know much at all about Python so maybe the type checker can tell you that you're handling all the cases, but with tagged union types you can have to handle every possible output of `str_if_zero` when calling it. That doesn't have to be an FP thing but I only find it when doing Elm and Haskell in my experience.

[0] https://elm-lang.org/docs/syntax#operators

[1] https://hackage.haskell.org/package/flow

[2] https://github.com/tc39/proposal-pipeline-operator

For some reason I wrote "bash" when I meant "Haskell" in the second sentence. Sorry about that.

outside `|` there's the threading macro in lisps (or else)

(-> x f g h ...)

Some languages like OCaml have “pipeline” operator like `|>`, others like D allow you to chain function application `f.g.h()` instead of `h(g(f()))`

[0] https://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/ho...

[1] https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...

That sort of chaining seems a bit like the method chains you have in some languages, like Java streams, C# LINQ and Rust iterators. That sort of "functional constructs when it fits" is getting popular, even if pure functional isn't gaining much popularity.

In D, Flix [0] and Nim you can use UFCS [1] to chain functions.

[0] https://flix.dev/principles/

[1] https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax?w...

D doesn't have pipes, being a C-like (it probably could, but it's untypical), but it has something almost as good: "uniform function call syntax", meaning that a function that takes X as its first parameter can be called as if it was a method of X. `foo(x)` => `x.foo()`. This makes functional programming in D a lot closer to the pipe example, in that you're usually passing a lazy iterator ("range") through a sequence of chained calls.

Every C-like language should copy this idea, imo.

That sounds amazing, but I wonder if it could get unwieldy as well.

Would have absolutely loved it in Go, where over the course of time I had to build up dozens if not hundreds of validators on strings, maps, etc. Ended up resorting to storing them in `companyInitials-dataType` packages, EG `abcStrings.VerifyNameIsCJK()`, but the unified call syntax would be super tidy.

This sounds like https://en.wikipedia.org/wiki/Method_chaining AKA https://en.wikipedia.org/wiki/Fluent_interface

Yep exactly, but without requiring monkeypatching or operator hacks. Basically sorta like what C# does.

edit: The extension method page even links https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax

Nim has this as well, it's lovely.

This is why every time this stuff comes up I plug the haskell flow package. Imo, it should be in the prelude.

https://hackage.haskell.org/package/flow-1.0.22/docs/Flow.ht...

I’ve hacked pipes in python many times just because it’s so much better. And no, “a=f(a);\n b=g(a);\n c=h(b);\n a=i(c)” isn’t “more declarative” or “more expressive” than a | f | g | h, and even in python a |pipe| b |pipe(blah)| c |pipe(blah, blah)| d is so much nicer than nesting the parens.

This sounds like a debugging nightmare. Is it not easier to name each intermediate result so you can inspect it in a debugger?

It's easier, but there are several considerations:

- There's workarounds. Eg. in F# you can redefine the pipe operator in debug mode [0] so it can be stepped into and inspected.

- I think some IDE plugins are also working on allowing pipeline contents to be automatically inspected.

- And of course, there's the good old tee operator for printf debugging. FP style rarely mutates variables, so a few print statements are just as good as a live object inspector.

As for why you actively wouldn't want to have those variables... much like comments, sometimes variable names add precious information and should be typed out, but sometimes they're just unnecessary noise, mental overhead, and scope pollution.

E.g. compare:

    let suppliers = getSuppliers()
    let sortedSuppliers = sortBy getSupplierPriority suppliers
    let bestSupplier = first sortedSupplier

to:

    let bestSupplier =
       getSuppliers()
       |> sortBy getSupplierPriority
       |> first

[0] https://stackoverflow.com/a/4966892

Elixir includes IO.inspect[1], which prints a value and then returns it. It makes it easy to insert this function into a pipeline without disrupting the existing logic[2].

[1] https://hexdocs.pm/elixir/1.12/IO.html#inspect/2

[2] https://elixir-lang.org/getting-started/debugging.html

In terms of debugging inconvenience for intermediate values, `->(x) | a | b | c` is the same as `c(b(a(x)))`.

I find debugging /w a REPL using functional-esque code much easier. You can play around and exec/inspect lines/snippets at will without changing state & "breaking" the debug session.

Agreed they are pretty much the same inconvenience level, but for me that level is too much either way. Maybe it's just my workflow, but I always preffered step-by-step debugging compared to REPL which is why I like to see many intermediate results being named.

when I hack it into python, it’s slightly annoying. when done properly, no, it’s no worse than f(a+g(b+c())), which is everywhere in code already. And debuggers / error messages should indicate what sub expression caused it, which would clean that up

> ‘Take the pan out of the over once it’s been in for 30min, where the pan contains a folded together eggs and previously mixed flour and sugar’ isn’t more FP than ‘Mix the flour with the sugar, then combine with eggs, then fold together, then put it into the oven, then take out after 30min.’

Oddly enough, the language that put the most thought into this problem is Perl, which provided the pronoun variables to represent "whatever I just computed".

Natural languages always offer multiple strategies for ordering the various parts of a sentence, because the order in which things are mentioned is critical for several purposes, from making it easier for the listener to follow a chain of thoughts to building or defusing tension or correctly positioning the punchline of a joke.

I'm always surprised how unpopular perl (and even more, its spiritual successor raku) is with the HN crowd. It does not square with my experience of various languages' ergonomics.

It's not at all surprising that perl put thought into things like this, the entire language concept optimises for elegance of expression.

I can't speak for Perl's general usefulness, but pronoun variables are just not terribly useful, because you can make them up on the spot. For example,

    result = input
    result = transform(result)
    result = transform2(result)
    return result

Perhaps I misunderstood the idea of pronoun variables. A related idea is the idea of `self` or `this`, in that computation is viewed from the perspective of an agent (which is ironically called an object when it is typically a grammatical subject).

Perhaps this is why we like OOP and CSP patterns so much, it meshes well with our social abilities.

> Perhaps I misunderstood the idea of pronoun variables.

Their point is the same as the one in human language. You can't make them up on the spot -- they already exist, with predetermined reference logic that we learn as part of learning a language. All you can do is mention them. This means they often reduce both the reading and comprehension load in comparison with inventing a new name and binding it to some referent.

For example, in this sentence:

> I can't speak for Perl's general usefulness, but pronoun variables are just not terribly useful, because you can make them up on the spot.

Who's "I"? And "you"? What's "them"? These are all obvious. Compare that with:

> I = the person writing this. This = the writing you are reading. You = the person reading this. I can't speak for Perl's general usefulness, but pronoun variables are just not terribly useful, because you... [You = someone writing code] can make them [Them = pronoun variables (though, as noted, you can't make them)] up on the spot.

Consider what it would take to write code displaying the first 10 numbers in the fibonacci sequence in some PL.

Here it is in Raku using pronouns:

    say .[^10] given 0, 1, *+* ... Inf # (0 1 1 2 3 5 8 13 21 34)

I grant that you have to learn this aspect of Raku to be able to read and write the above code. But it only takes a few seconds to learn that:

* `.foo` means applying `foo` to "it".

* `[^10]` means up to the 10th element. That's got nothing to do with pronouns, but whatever.

* The `*` in `*+*` is the pronoun "whatever" and, when used in combination with an unary or binary operator forms a lambda for that operation. So `*+*` reads as "whatever plus whatever" and represents a two argument lambda that adds its arguments.

* `...` is Raku's "sequence" operator, which uses the preceding function/lambda as the generator (which in turn uses the preceding N arguments per the generator's arity). Again, nothing to do with pronouns, and yet more you have to learn, but that's how PLs are.

It will no doubt look awfully weird, almost as weird as, say, Chinese (presuming you don't know Chinese). But that (it looking weird) is something completely distinct from whether it (using it) is extremely pleasant once you just accept it.

With a sufficiently open mind it (accepting using a "whatever" pronoun) can take literally a few seconds. (Thus kids tend to find this notion of "whatever" in Raku easy to grok, whereas adults sometimes struggle.)

I think maybe part of it is that most people are introduced to FP through haskell, if I had to guess. And haskell (at least the tutorials) is IMO guilty of the top-down approach where the final value is written first, referencing variables that haven't appeared yet. ocaml, on the other hand, has you define your components before the final value which is more familiar to most programmers

I think haskell doesn't always look super readable, but I can appreciate it at least because it reminds me of math papers where the final theorem is introduced first, and then it's broken into lemmas, and each of those lemmas is proved etc

I concur, in Haskell you have to import the pipe operator (&) before using it, kinda second class, no snark intended.

A lot of the difficulty in learning FP is in unlearning imperative programming. I hypothesise that for someone whom has never programmed before, FP and declarative paradigms are easier to reason about.

> FP has enough great ideas that I’d recommend everyone learn pure functional solutions just to put into their tool belt

Completely agree! I got my first taste of FP writing unreadable nests of python list comprehensions and it's shaped my Java tremendously. I've never spent much time in FP dedicated languages, but it's as good a frame to understand as OOP. I find they even mix and match well.

I’ve “drunk the koolaid” and I mostly went the opposite direction on left-to-right pipes vs. right-to-left compose: with a(b(c(d))), order of evaluation will always be arguments->function call (in most languages) and, so d is the first thing evaluated. Pipes make it seem more consistent, but it also introduces an inconsistency.

isn’t the first thing you are being the first thing evaluated just better? we read ltr, so having to see and remember a before c(d) but then having some of a’s arguments at the very end is just annoying vs pipes

It's hard for me to verbalize, but the rtl composition just sort of makes sense. For one thing, it's the way functions already sort of work:

    a(b(c(d))) === (a • b • c)(d) // the functions are in the same order

And, when you think about the typical order of evaluation, a(b(c(d, e, f))) is evaluated:

    - look up the value of d, e and f
    - evaluate c(d, e, f) (call it g)
    - evaluate b(g) (call it h)
    - evaluate a(h) (call it i)
    - return i

Pipes add an inconsistency between the order of evaluation of arguments vs. function calls and the order of evaluation of functions. (Also, completely separately, I've mostly come around to disliking operators and thinking Lisps are right here: precedence and associativity are "intuitive" for basic math operators because we've spent years studying math and getting used to PEMDAS, but anything beyond this is just asking for trouble: aside, maybe, from APL/J's strict right-associativity without precedence)

I have an algebra book on my shelf* that puts function arguments on the left, as in (x)f instead of the usual f(x). It is definitely more “natural”, as functions compose in the normal reading direction. But even so, it is increadibly hard to read, because the break with the usual convention is so radical. Needless to say, it didn’t catch on.

* In my office, but I am at home. Don’t remember the author; sorry. But it was written back in the ‘60s, I think.

What I like about pipes it that it allows two ways to write chains of function calls. For calls that are more branch-like, the nested structure of standard function calls makes the most sense to me:

    article = create(author("John"), Page.article())

For cases where you're modifying data sequentially, the pipe structure makes it really easy to read:

    5th_prime = 0.. | filter(is_prime) | nth(5)

Having a way to write function calls forwards and backwards lets you choose whatever syntax feels most appropriate for the job.

that same logic works for reversed-compose - a|b|c|d = (a)|(b~c~d). It is inconsistent with the normal kind but I think it’s worth it just for the ability to write list |map| func |filter| predicate |group-by| keyfunc |map| .values() |map| sum, which is so nice because you start with the value and as you read the thing that’s happening is precisely the thing you’re reading, and everything’s in one place - it’s

This is only true if your stages don't have arguments: with a | b(something) | c | d, `something` is now evaluated before b(something)

true, although argument evaluation order in a(x,b(y,c(d),z),w) is already somewhat hard to rely on

Java streams are a (limited) version of what you propose. Something like this is very idiomatic:

    myhashmap.entrySet()
        .stream()
        .map(Map.Entry::getValue)
        .sorted()
        .distinct()
        .toList()

Difference with pipe operator would be

1. can't be extended.

    myhashmap.entrySet()
       .stream()
       .flattenBars()
       .toFoo()

2. (As a result of 1) - applies only to streams

> can't be extended

They can be extended arbitrarily by defining collectors. The Stream interface is very well designed. For example your "toFoo" would be .collect(Collector(<foo-provider>, <foo-accept>, <foo-merge>, <foo-finisher>)). All of them can be arbitrary functions working on arbitrary types. That's the standard library implementation of "toList", in fact!

> applies only to streams

You're exactly correct here, but for legacy reasons Java did not have a choice. I'm the first to admit mylist.stream().map(f).toList() is dumb. A list is a functor, dammit!

It's the best possible solution given the existing constraints, but it's definitely limited in what it can do.

I was going to say C# LINQ, too!

For the order of fn composition, I found the pipe operator found in e.g. Elm really nice.

Most FP-heavy languages also have good support for metaprogramming, and have macros that imitate pipes (e.g., all lisps and Julia).