For arrays, yes.

How do they differ for other types?

For

`Maybe`

, you could have something like:```
Nothing.prototype.sequence = of => of(Nothing);
Just.prototype.sequence = of => this.value.map(Just);
```

So that will be

`Applicative ap => Maybe (ap a) -> ap (Maybe a)`

Could you explain the Applicative constraint? This isn't yet making sense to me.

The applicative constraint is there to be able to lift a value into functor type contained in the traversable.

So in the example above

`of(Nothing)`

If we don't have a functor instance inside a

`Nothing`

, we don't have anything we can map over.
In the

`this.value.map(Just)`

case, isn't the only constraint that `this.value`

must be a functor?
In that particular case, yep

Another example is applying

`sequence`

/`commute`

to an empty list.
Or any list for that matter, as it is typically implemented as a fold with

`of([])`

as the initial value.
Oh, I see it now. Applicative requires

`of`

. I was thinking that applicative requires `ap`

!
Thanks, @scott-christopher!

No worries :)

Is it accurate to say that

`sequence`

turns a nested structure inside out?
That's the way I typically think of it. It's essentially allowing a sequence of actions to take place in the order of the traversable and collecting the results.

And to clarify, traversables that contain more than one element (like list) will make use of

`ap`

too, in order to build up the traversable inside the applicative.
Is it roughly correct to say that

`sequence`

transforms a B inside an A into an A inside a B?
Yeah, while maintaining the order of the original traversable.

Is it also correct to say that

`R.commute`

is a specialization of `sequence`

, in that A is always List?
Yep

Another opportunity to dispatch, if we feel like it. :)

That's what I was thinking!

Could we provide

`R.sequence`

, have it dispatch, and define `R.commute`

as `R.sequence(R.of)`

? Does this make sense, or have I gone off the rails?
`R.commute`

already takes `of`

as its first argument
So it would be a direct alias of

`R.commute = R.sequence`

or vice versa
So if we really want to introduce

`sequence`

, we should deprecate `commute`

That's what I thought initially, but then I convinced myself we need two "of" functions.

While we've always dispatched to methods of the same name as the function, I don't mind keeping

`commute`

as long as we document that it will dispatch to `sequence`

for FL's sake.
`R.commute`

is hard-coded to use List as one of the types, isn't it?
At the moment, yep

So wouldn't it need to take an extra "of" argument to be equivalent to

`sequence`

?
Not that I'm aware of.

How do you propose removing **src/commuteMap.js**?

`_of`

and `[]`

from
I don't see

`_of`

. Do you mean the `of`

in the function params?
L33:

`return concatF(acc, map(_of, fn(ftor)));`

`_of`

is `x => [x]`

.
Ah, I was looking at the 0.17.1 tag.

Oh, right. The

`_of`

change is very recent.
Perhaps it should use

`lift(append)`

rather than `lift(concat)`

The only reason

`_of`

is needed is to concat a singleton array to the end of the accumulated array (inside the functor).
See ramda/ramda#1409 for the reason we switched from

`append`

to `concat`

.
I don't think I'm conveying my thoughts clearly. Currently we have *two* "of" functions: one provided by the caller, and one fixed to

`x => [x]`

. This is fine for `[f a] -> f [a]`

, but for arbitrary `g (f a) -> f (g a)`

transformations it seems to me we would need to parameterize the second "of" function.
The

`_of`

is specific to the `[]`

traversable implementation.
Other traversables would handle that themselves.

e.g.

`commuteMap`

could also be implemented without `_of`

using `reduceRight`

and `prepend`

instead:```
function commuteMap(fn, of, list) {
function consF(acc, ftor) {
return ap(map(prepend, fn(ftor)), acc);
}
return reduceRight(consF, of([]), list);
}
```

I'd be interested to see what people think in changing the type of the function in the first param of

`commuteMap`

from `f a -> f b`

, to `a -> f b`

I'd love to continue this discussion in a GitHub issue, but I don't yet have a good enough grasp on the situation to write a description. I just have a general sense that

`R.commute`

is a special case of `traverse`

, and Hardy Jones has taught me to love generalizations. :smile:
I've always wondered if it's semantically incorrect to use

`a -> b -> c`

notation if a function is not curried
I wouldn't

I've switched to saying a, b -> c

that almost looks like it takes a tuple

heh, I was wondering why ramda-destruct wouldn't add

`equals`

to my required functions, thought it was bug in its code. turned out I was running v0.14 and that's why it didn't add it