Make Compose to be a proper Applicative

[rpominov]

@joneshf Pointed out that the Compose type as it currently implemented in the spec doesn't pass the Applicative laws. For instance Compose.of(x => x).ap(Compose.of(1)) will blow up.

I've also changed the letters that are used for variables and types to hopefully a bit more appropriate ones.

Checked that new code works fine in Ramda REPL

[davidchambers]

Where are F and G defined?

[rpominov]

They are "any Applicatives", we can add "... for any Applicatives F and G" to the law, not sure if it necessary though.

[rpominov]

Also notice that the same types are mentioned in the law (Compose.wrap(u.sequence(F.of).map(v => v.sequence(G.of)))) so it all connected.

[davidchambers]

So Compose is specific to (F, G) in this case? Perhaps we should parameterize F and G as @scott-christopher did here.

[rpominov]

I thought about it, but specialized Compose is simpler, and works fine for its purpose in this case (we don't need to define a usable Compose type, but only one that helps to express the law).

With parameterized Compose the law code snippets will become harder to read.

[joneshf]

I am a little unsettled that this would be a runtime error if someone copy/pasted it. And given that we have issues like #128, we should try to be more aware that what seems obvious to one or two of us, isn't necessarily good for the spec. How do you feel about making these variables explicit?

[rpominov]

What if we simply rename Compose to ComposeFG? It will be clear that it works only with F and G, and we won't have to complicate code.

I'm worried that with parameterized Compose the law text will became harder to grasp.

[joneshf]

If the implementation doesn't change, I will still have the same level of unsettledness. I will defer to someone else on the level of easiness/hardness.

@CrossEye, thoughts?

[rpominov]

@SimonRichardson, since you're merging PRs today, do you think this one's also ok to merge? 😅
@joneshf, maybe you could take a look as well?

[SimonRichardson]

I'm not a fan of the word wrap, also should we spec it out, or just leave it?

[rpominov]

I think in this case wrap is a type specific function that can create instances of type differently from of, probably no need to spec it somehow. But we can rename it (any suggestions on a better name?), or make Compose() behave as such function, but this will be more code inlined in spec...

[rpominov]

Maybe we should inline wrap into the law like this:

u.map(x => new Compose(x)).sequence(Compose.of) is equivalent to new Compose(u.sequence(F.of).map(v => v.sequence(G.of)))

?

[rpominov]

• Removed/inlined wrap.
• Also added "and any Applicatives F and G". More clarity can't hurt :)

[SimonRichardson]

Let me know when you're done!

[rpominov]

It's ready to merge!