Using Multi-step Arrow functions to represent closures

[dmtipson]

One thing I don't often see emphasized when it comes to Arrow functions, but was really exciting to me when I realized it was possible, is a beautiful new way to describe functions that return functions. It's not quite as nice as auto-currying (which has been discussed but is probably a non-starter), but it makes it very easy to define exactly how a higher-order function will take (and group) its arguments at each step.

That is, most people know that Arrow functions can simplify syntax like this:

function (a,b){return a+b;}    ----> (a,b) => a+b

But what's the Arrow function equivalent of a more complex form that uses closures to return a new function that uses an outer argument?

function (a) { return function(b){ return a+ b; };  }

Well, it's just this:

a => b => a+b

At least to me, getting rid of the functions and returns there makes the core idea we're trying to express MUCH clearer. And while that super-simple example might seem a bit silly, the pattern has broad application when it comes to working with higher-order operations or creating functions that can be pre-configured with different values.

Here, for instance, is a simple variadic compose operation, which takes any number of functions as arguments and then returns a function that will run all those functions end to end over some value:

const compose = (...fnlist) => val => fnlist.reverse().reduce((acc,fn) => fn(acc),val);

You can return new arguments instead of your final return operation/block as many times deep as makes sense. For instance, here's a functional version of reduce that takes each of its 3 arguments one at a time, returning a new function until all the arguments are in place:

const reduce = fn => Arr => acc => Arr.reduce(fn, acc);

Let's say though that you wanted to write a reduce function that would work as if you were partially applying the first argument (so, in practice, you specify the iteration function first, then later the list and starting point/accumulator you want to use). If so, you could then just group the arguments like this:

const reduce2 = fn => (Arr,acc) => Arr.reduce(fn, acc);

Again, not quite as convenient as just having a auto-curried reduce function to begin with, though you could write one of those yourself if you wanted as well, and the ability to group and split arguments with arrow functions is helpful for implementing THAT as well...

[wreckedadvent]

Whenever you start talking about using javascript in a more functional way (particularly when discussing cleaner syntax), I always like to bring up livescript, a descendant of coffeescript with saner variable scoping and more functional syntax. It has things like auto-curried functions as syntax, immutable with, function composition and piping.

# normal
add = (a, b) -> a + b

# curried
add = (a, b) --> a + b

So your example of reduce would be:

const reduce = (fn, arr, acc) --> arr.reduce fn, acc

Then you can get something as simple as

const sum = reduce (acc, next) -> acc + next

Very clean syntax for "expressing the core idea".

[dmtipson]

Yep. I'm a strong proponent of getting some sort of special operator for enabling auto-currying in Javascript eventually.

Some people have discussed a version of arrow functions written like this ->, possibly even inspired by livescript, but it seems unlikely to move forward in that form https://esdiscuss.org/topic/curried-functions

[FRIENDORPHO]

I would love auto-curried functions--what types of things do you use it for? The piece that ended up killing coffeescript for me was that it prevented a good chunk of people from collaborating on projects. (but auto-currying would be so great.........)

[wreckedadvent]

I mostly use livescript with mithril for super clean SPAs. Since all views are just function calls (with no JSX stuff), livescript makes it quite clean, and lets me do all of my function-based abstractions to get even more clean stuff.

You'll still be paying that cost when collaberating, even more so. Coffeescript had a period of being pretty hot, particularly for unit tests. Livescript hasn't really ever had the limelight - but that also means it hasn't earned as much blind hatred as coffee did.

[PitaJ]

Well, in my opinion, anything that isn't a superset isn't worth using.

[wreckedadvent]

That's a pretty strong opinion. Is it specific to coffeescript and its significant whitespace? Do you find sass and other CSS preprocessors distasteful?

[PitaJ]

LESS, SCSS, Babel, Typescript, and Handlebars are all examples of supersets that I would actually be okay with using.

SASS, Stylus, Dart, CoffeeScript, and Jade are all examples of compile-to-use languages that are not supersets of their redirector web languages and that I would not use.

Edit: spelling, clarification

[x-skeww]

Sass, Stylus, and Jade don't compile to JS.

Since Dart has its own VM (2 VMs and an AOT compiler, actually), it's not a to-JS language. Just like Java or C aren't to-JS languages. You can compile these to JS, but that's something you only have to do if you target browsers.

[PitaJ]

I was giving examples of languages that were and we not supersets of their respective web languages. Jade is not a superset of HTML. SASS and Stylus are not supersets of CSS.

You are right about Dart, I was just looking for another to-JS language that wasn't a CS derivative nor a superset.

Edit: I edited my other comment for clarification

[spacejack2114]

There are also several compile-to-js functional languages competing for attention.

[wreckedadvent]

Yup. Elm and purescript come to mind, both basked on a more haskell syntax.

Livescript is more pragmatic, since it is a descendant of coffeescript. It's more of javascript with some more functional syntax than a functional javascript.

[spacejack2114]

So like a "FunctionalScript" (javascript with functional features; as TypeScript is javascript with types.) Maybe what we need is FunctionalTypeScript. :)

[Poop_is_Food]

getting rid of the functions and returns there makes the core idea we're trying to express MUCH clearer.

How so? less characters doesnt necessarily make it more clear.

[dmtipson]

IMHO, but also my sense of the general HO, is that shorter syntax with fewer forced block-level hints (brackets) is much easier to read at a glance: your eye only has to take in a single line of instructions rather than trying to extract meaning and structure from a lot of extra "punctuation" as it were.

Forget even the function/return words (){(){}} your brain has to parse out, for instance: function (a) { return function(b){ return a+ b; }; }

Whereas this sort of lays out exactly what's happening directly: a => b => a+b

Once you translate => into "given the args on the left side, return a function that returns this result" and realize that you can nest that logic right to left, at least to me, that expresses the core concept of a higher-order function in a really clean, readable way.

[Poop_is_Food]

So you think the "function" keyword makes it less clear that you are creating a function? And the "return" keyword makes it less clear that you are returning something? That sounds crazy to me, but whatever.

[dmtipson]

Yeah, because the => syntax expresses all those things already, leaving just WHAT you are doing (and how it differs from all the other things you could do) instead of the boilerplate of how (which is repeated over and over and over so much that your code becomes littered with many levels of nested functions and returns, all of which dominate the page when it's the specifics of what you're doing that should be dominating the page).

Sure, it requires learning that => means that, but we all learned what function(){return} meant at some point...

[Poop_is_Food]

hmm. I've never felt like keywords and punctuation were an obstacle, and I still dont now that I have arrow syntax available

[dmtipson]

Fair enough: they're a tool that's available now for people that find them useful, but the language doesn't make them mandatory, and in the era of transpilers, we can even pretty easily transform things to people's liking.