Scott Sauyet - 1 year ago 73

Javascript Question

I've been working for some time on a Javascript FP library called **Ramda**, and I'm having a slight problem with naming things. (You've heard the old line, right? "There are only two hard problems in Computer Science: cache invalidation, naming things, and off-by-one errors.")

In this library, (almost) every function of more than one parameter is automatically curried. And this works well for most use-cases. But there are some issues with a few functions which are non-commutative binary operators. The issue is that the English names often tend to imply something different than what happens when currying is applied. For example,

`var div10 = divide(10);`

`var divide = curry(function(a, b) {`

return a / b;

});

So instead the expected:

`div10(50); //=> 5 // NO!!`

In fact, you get

`div10(50); //=> 0.2 // Correct, but surprising!`

We handle this by documenting the difference from people's possible expectations, and creating

`divideBy`

`flip(divide)`

`subtractN`

`flip(subtract)`

`lt`

`R.lt = curry(function(a, b) {`

return a < b;

});

or its cousins

`lte`

`gt`

`gte`

My own intuition would be that

`map(lt(5), [8, 6, 7, 5, 3, 0, 9]);`

//=> [false, false, false, false, true, true, false]

But of course, it actually returns

`//=> [true, true, true, false, false, false, true]`

So I'd like to do the same document-and-point-to-alternate-name routine for

`lt`

`ltVal`

Have others dealt with this and come up with good solutions? Or even if not, any good suggestions for a name for the flipped versions of these functions?

Someone suggested that this be closed because 'unclear what you were asking', and I guess the question really

What would be a good, intuitive name for a flipped version of

`lt`

Recommended for you: Get network issues from **WhatsUp Gold**. **Not end users.**

Answer Source

First of all, kudos on the functional programming library that you are maintaining. I've always wanted to write one myself, but I've never found the time to do so.

Considering the fact that you are writing a functional programming library I'm going to assume that you know about Haskell. In Haskell we have functions and operators. Functions are always prefix. Operators are always infix.

Functions in Haskell can be converted into operators using backticks. For example `div 6 3`

can be written as `6 `div` 3`

. Similarly operators can be converted into functions using parentheses. For example `2 < 3`

can be written as `(<) 2 3`

.

Operators can also be partially applied using sections. There are two types of sections: left sections (e.g. `(2 <)`

and `(6 `div`)`

) and right sections (e.g. `(< 3)`

and `(`div` 3)`

). Left sections are translated as follows: `(2 <)`

becomes `(<) 2`

. Right sections: `(< 3)`

becomes `flip (<) 3`

.

In JavaScript we only have functions. There is no *“good”* way to create operators in JavaScript. You can write code like `(2).lt(3)`

, but in my humble opinion it is uncouth and I would strongly advise against writing code like that.

So trivially we can write normal functions and operators as functions:

```
div(6, 3) // normal function: div 6 3
lt(2, 3) // operator as a function: (<) 2 3
```

Writing and implementing infix operators in JavaScript is a pain. Hence we won't have the following:

```
(6).div(3) // function as an operator: 6 `div` 3
(2).lt(3) // normal operator: 2 < 3
```

However sections are important. Let's start with the right section:

```
div(3) // right section: (`div` 3)
lt(3) // right section: (< 3)
```

When I see `div(3)`

I would expect it to be a right section (i.e. it should behave as `(`div` 3)`

). Hence, according to the principle of least astonishment, this is the way it should be implemented.

Now comes the question of left sections. If `div(3)`

is a right section then what should a left section look like? In my humble opinion it should look like this:

```
div(6, _) // left section: (6 `div`)
lt(2, _) // left section: (2 <)
```

To me this reads as *“divide 6 by something”* and *“is 2 lesser than something?”* I prefer this way because it is explicit. According to The Zen of Python, *“Explicit is better than implicit.”*

So how does this affect existing code? For example, consider the `filter`

function. To filter the odd numbers in a list we would write `filter(odd, list)`

. For such a function does currying work as expected? For example, how would we write a `filterOdd`

function?

```
var filterOdd = filter(odd); // expected solution
var filterOdd = filter(odd, _); // left section, astonished?
```

According to the principle of least astonishment it should simply be `filter(odd)`

. The `filter`

function is not meant to be used as an operator. Hence the programmer should not be forced to use it as a left section. There should be a clear distinction between functions and *“function operators”*.

Fortunately distinguishing between functions and function operators is pretty intuitive. For example, the `filter`

function is clearly not a function operator:

```
filter odd list -- filter the odd numbers from the list; makes sense
odd `filter` list -- odd filter of list? huh?
```

On the other hand the `elem`

function is clearly a function operator:

```
list `elem` n -- element n of the list; makes sense
elem list n -- element list, n? huh?
```

It's important to note that this distinction is only possible because functions and function operators are mutually exclusive. It stands to reason that given a function it may either be a normal function or else a function operator, but not both.

It's interesting to note that given a binary function if you `flip`

its arguments then it becomes a binary operator and vice versa. For example consider the flipped variants of `filter`

and `elem`

:

```
list `filter` odd -- now filter makes sense an an operator
elem n list -- now elem makes sense as a function
```

In fact this could be generalized for any n-arity function were n is greater than 1. You see, every function has a primary argument. Trivially, for unary functions this distinction is irrelevant. However for non-unary functions this distinction is important.

- If the primary argument of the function comes at the end of the argument list then the function is a normal function (e.g.
`filter odd list`

where`list`

is the primary argument). Having the primary argument at the end of the list is necessary for function composition. - If the primary argument of the function comes at the beginning of the argument list then the function is a function operator (e.g.
`list `elem` n`

where`list`

is the primary argument). - Operators are analogous to methods in OOP and the primary argument is analogous to the object of the method. For example
`list `elem` n`

would be written as`list.elem(n)`

in OOP. Chaining methods in OOP is analogous to function composition chains in FP^{[1]}. - The primary argument of the function may only be either at the beginning or at the end of the argument list. It wouldn't make sense for it to be anywhere else. This property is vacuously true for binary functions. Hence flipping binary functions makes them operators and vice-versa.
- The rest of the arguments along with the function form an indivisible atom called the stem of the argument list. For example in
`filter odd list`

the stem is`filter odd`

. In`list `elem` n`

the stem is`(`elem` n)`

. - The order and the elements of the stem must remain unchanged for the expression to make sense. This is why
`odd `filter` list`

and`elem list n`

don't make any sense. However`list `filter` odd`

and`elem n list`

make sense because the stem is unchanged.

Coming back to the main topic, since functions and function operators are mutually exclusive you could simply treat function operators differently than the way you treat normal functions.

We want operators to have the following behavior:

```
div(6, 3) // normal operator: 6 `div` 3
div(6, _) // left section: (6 `div`)
div(3) // right section: (`div` 3)
```

We want to define operators as follows:

```
var div = op(function (a, b) {
return a / b;
});
```

The definition of the `op`

function is simple:

```
function op(f) {
var length = f.length, _; // we want underscore to be undefined
if (length < 2) throw new Error("Expected binary function.");
var left = R.curry(f), right = R.curry(R.flip(f));
return function (a, b) {
switch (arguments.length) {
case 0: throw new Error("No arguments.");
case 1: return right(a);
case 2: if (b === _) return left(a);
default: return left.apply(null, arguments);
}
};
}
```

The `op`

function is similar to using backticks to convert a function into a operator in Haskell. Hence you could add it as a standard library function for Ramda. Also mention in the docs that the primary argument of an operator should be the first argument (i.e. it should look like OOP, not FP).

^{[1]} On a side note it would be awesome if Ramda allowed you to compose functions as though it was chaining methods in regular JavaScript (e.g. `foo(a, b).bar(c)`

instead of `compose(bar(c), foo(a, b))`

). It's difficult, but doable.

Recommended from our users: **Dynamic Network Monitoring from WhatsUp Gold from IPSwitch**. ** Free Download**