
Combinator Recipes for Working With Objects in JavaScript - raganwald
https://github.com/raganwald/homoiconic/blob/master/2012/12/combinators_1.md#combinator-recipes-for-working-with-objects-in-javascript-part-i
======
ufo
I had some experience using things like these inpractice. Some tips I would
give out

* Make sure you make you library comprehensive. Remember that main benefit of doing something like this instead of explicit functions is conciseness and consistent patterns.

* Partial function application can be tricky. I find it is only really useful if you use it on all most of the standard combinators and you need to pay _very good_ attention to what is the order of arguments you use. I also suggest putting the arguments on the same line if you are doing partial functoins by hand like he did:
    
    
        //This way you don't confuse partial functions
        //and more general closures with inner state.
        function get(attr){ return function(object){
            return object[attr];
        };}
    

* There are _lots_ of way to do partial function application - do you let multiple arguments be passed at once or not? Do you allow for placeholder "hole" arguments or do the arguments have to always be passed in left-to-right order? What do you do with "this"? In the end I ended up having functions for all of the different cases but in general, I'd at least recommend not using null/undefined checks to test if arguments have been passed since that can easily mask dynamic errors. I'd rather check arguments.length explixitly or use a special placeholder object from my library if I need one.

* One of the big downsides of using partial function application and these combinators all over the place is that they make the call stack a lot more complicated. I use the JS debugger _a lot_ and this can make things much more annoying to deal with. In particular, your "real" code gets hidden inside opaque "f" variables, its harder to set useful breakpoints and sometimes its harder to look at closed over variables.

* Another problem I had was that many of my coworkers were not used to the partial application and functional patterns. In the end we ended up using these combinators less and less, and now they are too rarely used to justify the "abstraction cost".

------
wonderzombie
I love these kinds of articles.

I know about partial function application, and I'm already sold on the merits
of higher-order functions, et al. (A one-two punch of Haskell and Clojure sold
me.) Maybe that's why it's nice to see other ways of describing or encoding
these concepts— it was a neat little "aha" moment when we got to pluck.
Immediately it reminded me of how, in Clojure, keywords are functions.

For those of you who aren't familiar, Clojure has symbolic keys like in Ruby
(e.g. :foo), called keywords. So given the 'inventories' variable in the
pluck() example, you could write:

    
    
        (map #(get % :oranges) inventories)
    

The #(get % :oranges) syntax is an anonymous function, invoking get to
retrieve :oranges from each inventory in inventories. But it turns out you
don't even need to do that. You can just do this instead:

    
    
        (map :oranges inventories)
    

Anyway, I guess what's funny to me is that I used JS for a little while, and I
liked it pretty well. It's only in retrospect that I start to see the extent
to which it seeded my brain with these patterns.

~~~
raganwald
I left "compose" out of this excerpt, but in the book:

    
    
      var pluck = compose(splat, get);

~~~
wonderzombie
Compose is another piece I wish more languages had. The functional style of
small, orthogonal functions has changed the way I write code, but in many
imperative languages, function composition as I know it just doesn't exist.
And sometimes that disparity is a real bummer.

You can get close in dynamic languages, as with JS, Ruby, and Python. But if
we're talking about Java or C++, it's just not happening, not without a bunch
of work and not within an existing codebase where the introduction of new
styles might actually be counterproductive.

------
raganwald
There's no need to rush out and buy the book, but if you're interested, here's
a coupon code to get it for $9.99 today: "Hacker_saturday"

<http://leanpub.com/javascript-allonge>

~~~
jan_g
Thanks. I've bought it, because the article was very informative.

------
k3n
Isn't splat() just an implementation of partial application around a specific
function (map)?

~~~
raganwald
Very much so, thanks for pointing that out!

------
wylee
In `maybe`, would it make sense to check the args passed to the wrapper
against the number of args the original function expects? Something like this:

    
    
        function maybe (fn) {
          var expected_number_of_args = fn.length;
          return function () {
            var i, arg;
            for (i = 0; i < expected_number_of_args; ++i) {
              arg = arguments[i];
              if (arg === null || typeof arg === 'undefined') {
                return null;
              }
            }
            return fn.apply(this, arguments)
          }
        }

~~~
jrajav
This would make it unusable for a function that, itself, uses the 'arguments'
variable rather than formal arguments.

Function arity in Javascript is a tricky subject when we touch on partial
application and other functional programming techniques that act on the
arguments passed to a function, but the generally accepted solution is to
avoid Function#length and ignore that formal arguments exist.

~~~
wylee
The `maybe` in the article allows for this ambiguous situation:

    
    
        var fn = function (a, b) { ... };
        var maybe_fn = maybe(fn);
        var obj = {};
        maybe_fn(1);  // calls fn
        maybe_fn(1, null);  // doesn't call fn
        maybe_fn(1, obj.nonexistent_prop);  // also doesn't call fn
    

In my mind, all of these calls to `maybe_fn` should do the same thing. Maybe
not, though?

~~~
jrajav
This is a good point, and may be an argument for having a "formal_maybe" or
perhaps having it check _at least as many_ arguments as there are formal
arguments. However, I don't think that this situation would be as important in
practical use. You would normally use this function to allow for passed
arguments to be null or undefined - not to allow for some arguments not to be
passed.

------
nadaviv
I find higher-order function to be really beautiful with CoffeeScript:

    
    
      partial = (fn, a...) -> (b...) -> fn.apply this, [a..., b...]
      compose = (fns...) -> (a) -> a = fn a for fn in fns; a
      
      splat = (fn) -> (arr) -> arr.map fn
      get = (attr) -> (obj) -> obj[attr]
      
      maybe = (fn) -> (args...) ->
        return unless args.length
        return arg for arg in args when not arg?
        fn.apply this, args

~~~
wonderzombie
Beauty is, of course, subjective, but the use of 'this' stands out to me as
unusual for these particular patterns. Call it a slightly leaky abstraction, I
suppose.

That said, at least the function declaration syntax looks a lot like Haskell's
type signatures. So maybe they're doing something right. :)

------
KeithMajhor
This was a great post. Just a little nitpick. I think this line near the
bottom:

var something = maybe(doesntCheckForSomething(value));

Should actually be:

var something = maybe(doesntCheckForSomething)(value);

If I'm wrong then I likely missed something so please let me know. Thanks.

~~~
raganwald
I think you're right, thanks!!!

------
ville
It is stated that JavaScript doesn't have partial function(al) application.
Isn't it available through the built in Function#bind method?

~~~
jrajav
Function#bind isn't the greatest solution, since it forces you to set 'this'
and only allows left-to-right, flat application.

Many people have written partial application libs to make it easier to work
with (I even have one of my own on github). A good one is substack's:
<https://github.com/substack/node-ap>

------
raganwald
Part II:

[https://github.com/raganwald/homoiconic/blob/master/2012/12/...](https://github.com/raganwald/homoiconic/blob/master/2012/12/combinators_2.md#combinator-
recipes-for-working-with-objects-in-javascript-part-ii)

------
jrajav
The functions covered in the article, if anyone wants to play around with
them: <https://github.com/jrajav/rcombinator>

~~~
raganwald
Everything I write on my blog is covered by the MIT license, so go wild!

~~~
jrajav
Oh, I do see now that there's a license.txt at the top level of your blog
repo. Now I feel silly. :)

(Context: I contacted the author before publishing to see if this was
alright.)

------
bonobo
The link to Part II seems to be broken.

