Partial Application and Lambda Parameter Syntax for JavaScript | Hacker News Reader

Partial Application and Lambda Parameter Syntax for JavaScript

medium.com

52 pointsskellertor24 comments

If you really like the idea of syntactic partial application in your JavaScript, you should check out the stage 1 tc39 proposal for exactly that: https://github.com/rbuckton/proposal-partial-application It's slowly being worked through the committee, so if you care enough about the feature, you should consider voicing your support.

I agree! It's not as powerful as this macro but I really want this in the standard.

Funny, I already kinda use partial application in Javascript, just by using curried functions a lot. I.e.

const add = x => y => x + y

This is definitely non-idiomatic, but the definition syntax itself doesn't look that bad, if you can stomach writing add(1)(2) to use it.

I do agree that using _ would probably be a better solution :-)

Am I missing something? Why not just

const add = (a,b)=>a+b?

You can not use partial application with that. for example const add = x=>y=>x+y

can be partialy applied like the following const add3 = add(3) // this is also a function

> You can not use partial application with that.

You can:

    const add3 = add.bind(null, 3)

I still like currying better, but I just might be weird like that :-)

I only asserted that you could partially apply regular functions. But I don't think currying looks or feels nice in Javascript.

Proper curried languages are definitely better suited for partial application though.

You could use default parameters in this case.

const add = (a, b=0) => {return a+b}

Well usually it would be for something that is useful, like

const greaterThan = x => y => y > x

and then I can do thins like

numbers.filter(greaterThan(10))

because greatherThan(10) is a function (and I hope I did put the correct comparison operator :)

It also works better on languages using free functions than those using method calls e.g. in Haskell you have

    filter :: (a -> Bool) -> [a] -> [a]

so you partially apply to a predicate to get a specific filter condition which you can apply to various contexts e.g.

    over10 = filter (>= 10)

That's why functional languages tend to put the callback first in HoFs, it's usually the more common partial application case.

Right, this is currying not partial application. And it comes with the drawback that you always have to call the function multiple times. You can't provide all the parameters in one list, which rules out things like spread arguments. That's not the case with `param.macro`, depending on how you apply of course.

> In Kotlin specifically, this is a shorthand for anonymous functions where, if you don’t specify an argument, one will automatically exist with the name it

I'm pretty sure Kotlin borrowed this idea from Groovy.

I'm pretty sure that's correct but Kotlin is a more recent reference so I chose it instead.

Hi everyone, I'm the author. Looks like I'm a little late to the party (this post snuck by me) but I'll try to answer any questions you might have.

I'd also like to point out the online playground [0] which allows you to use this directly in your browser and see what it compiles to.

[0]: https://citycide.github.io/param.macro

Nice article. I still prefer arrow functions over positional arguments though, because this approach trades some clarity for syntactic sugar. Until partial application becomes part of JavaScript, the import statement will probably outweigh the informative "boilerplate" it helps obscure anyway (there's rarely more than one use case for partial application inside a well-factored component).

Partial application is a technique, not a language construct. Plus, you can already use partial application in JavaScript and have been able to for years.

Doesn't javascript have enough magic in it to make code difficult to follow? What is the benefit to adding more?

I think the fact that this (and all macros with `babel-plugin-macros`) requires an explicit import helps keep it out of magic territory. You do have to become aware that the symbols transform the function/argument they're a part of, but this is only really new to JS devs. It's familiar in a bunch of other languages.

I documented how they work in this part[0] of the readme.

[0]: https://github.com/citycide/param.macro#differences-between-...

The import tells you that some of the expressions in a file might be functions, but not which ones. For each definition, you have to read the entire expression to tell whether it's a function or evaluated immediately, and what its arity is. No thanks! Reading the entire file just to find out its API is no fun.

I like the direction typescript is going, where you can easily see not only the arity but the type of each parameter, without reading the function body. This is more skimmable.

I upvoted you because I want an honest answer from somebody.

It's like if mountain-climbing caused more mountains to rise up above you. This is great if you love climbing mountains but terrible if you actually want to reach the top.

We keep "improving" our languages but very few of us take the time to measure our real productivity.

What is the business value case for not using Elm-lang?

At some point, if we are "doing it right" the total amount of code in the world (modulus copies) should be contracting.

Are babel plugins the new C preprocessor? and have all the problems associated with that.

babel-plugin-macros allow hygienic macros (https://en.wikipedia.org/wiki/Hygienic_macro) so they don't have the problems associated with C macros.

Not specifically, no. But they can be abused in similar ways.

Reply on news.ycombinator.com