Pipes: Currying vs. Hack Pipes

[OAGr]

From Slava,

I recently looked up the proposals for adding pipeline operators to JS (btw, turns out I miss pipes in our Typescript rewrite even more than I miss pattern-matching), and its... complicated.

Short summary: initially they had the proposal for F# pipes (similar to Rescript pipes), but couldn't reach the consensus and the current proposal if for Hack pipes, which require explicit argument passing (value |> func(%)).

The reason for this, as far as I understand, is that JS lacks currying, and it's hard to do pipes without it in a principled way.

And now we have to add special cases to the Squiggle parser for similar reasons. These special cases will always be incomplete with our current approach and users will notice it as a wart/quirk in Squiggle semantics.

For example, this won't be possible:

plusN = {|n|
{|x|x+n}
}

5->plusN(2)

I think it's better to figure this out earlier rather than later, or at least plan how we'll fix this eventually, and we should either:

decide that we want to add currying to Squiggle

should be possible, with several consequences
consequences are mostly positive (clear pipes implementation)
but also a slight performance hit for all function calls, and slightly more obscure error messages for users who're not comfortable with FP (when partial application is allowed, it's possible to do this by accident and the language won't report this as an error)
it also might collide with our standard library, e.g. if we have a polymorphic function that behaves differently on 1 vs 2 arguments
mx will definitely cause problems, and maybe some other functions too

Or we can switch to explicit Hack pipes

those are uglier/more verbose
but when you don't have currying they make more sense

Relevant blog post: https://jamesdigioia.com/hack-pipe-for-functional-programmers-how-i-learned-to-stop-worrying-and-love-the-placeholder/

Functional programming in JavaScript has long adopted techniques and tools from other functional languages; this is why currying & point-free programming have become so popular in functional JavaScript. But JavaScript isn’t Haskell, and currying isn’t built-in to JavaScript, so its adoption will always be a bit unnatural by comparison. We should adopt a pipe operator that feels native to JavaScript, and adapt our techniques for more natural functional JavaScript for the masses.

[OAGr]

Thanks @berekuk for bringing this issue up and documenting it so well.

From my angle, I don't want us to get very complicated with Squiggle. Getting a solid numeric+JS support is enough work.

I'd expect currying to make things more complicated for users, plus make the interpreter substantially more complicated.

The pipe operator is nice, but I really don't see it as an essential part of the language.

My inclination here would be to minimize complexity, and I think hack pipes are the best way to get there.

Another thing we could totally do is just to remove all pipe functionality now, and add it later(when we have capacity to do it well). It very much seems like a nice-to-have to me.

[umuro]

Some notes

plusN = {|n|
{|x|x+n}
}

You have to write
plusN(5)(2)
to evaluate the answered function (because there is currying).

If you use pipes then this would be equivalent to
5->plusN()(2)
Not using any paranthesis when using a pipe (e.g. 5->plusN) is a shortcut when there are more arguments or function applications.

If we were imitating ReScript then the next feature would be to allow writing
2->div(4,_)
to indicate which argument to substitute

Of course, this does not apply to plusN as there is no currying.
I think currying is a strict No No because of the performance penalty. We would go back into the slowness of my prototype!

PS. On a strictly typed language currying can be optimized and be converted into normal function calls when possible.

[OAGr]

We have pipes now, closing.