I would really like to be able to have point-free composed functions, it’s something that’s been really bugging me ever since the early days of reasonml. I’m sure this has been thought about/questioned before, has there ever been a discussion on this?
ie. all these functions should behave the same (the third one currently invalid)
let fn1 = (x, y) => x->foo(y)->bar->baz
let fn2 = (x, y) => foo(x, y)->bar->baz
let fn3 = foo->bar->baz
Perhaps it’s to do with the question of ‘where’ should the arguments be applied - on the first function or the ‘final’ composition Perhaps that’s where placeholders could come to the rescue!
let fn1 = foo(_, _)->bar->baz
let fn2 = foo->bar->baz(_, _)
Point-free composition makes the life of a coder a bit easier by passing the technical debt on anyone who reads the code.
The original tread makes a perfect example:
List.map [1,2,3] (((+)5)>>String.fromInt)
vs
List.map(n => String.fromInt(n + 5), [1, 2, 3])
Since Rescript is a pragmatic alternative to Elm and other functional languages I really admire the fact that it does not have point-free composition. Easy to read code really does matter when dealing with large teams of JS developers.
I think that’s a fairly convoluted example, you could argue that the (+) infix operator is partly to blame in terms of readability. Also we already have point free composition thanks to pipes, with the caveat of assigning to another function requires exposed arguments.
Considering this is valid syntax in Rescript: let foo = 10->\"+"(10)
I don’t see something like this as particularly unreadable:
let foo = x => x + 1
let bar = x => x + 2
let baz = x => x + 3
let fn = foo -> bar -> baz
I also think the ‘easy to read’ argument is heavily subjective - for example some JS developers may so happen to deem partial application as ‘technical debt’.
For the sake of discussion, are there any negatives to this other than argument of readability?
I have worked on a codebase that used composition (we had our own << operator and other similar composition operators that our Haskell developers showed us how to create). I’m pretty good at FP, but I found the project much easier to work on after we were forced to remove these complex operators (although I admit I do miss some of the simpler operators).
The problem I see is that composition doesn’t fit well into JavaScript. ReScript is aimed at JavaScript developers wanting to write better code, not FP developers wanting to compile to JavaScript. For the latter ReasonML/OCaml + js_of_ocaml is a far better fit.
Perhaps that’s where placeholders could come to the rescue!