derivations do not make certain methods optional

[davidchambers]

Closes #132

Commit message:

Derivations of FL methods are relevant to implementers of data types.

Derivations of FL methods are irrelevant to implementers of functions which operate on values of these types, since the values must provide the relevant methods.

I'm not sure how toArray and traverse fit into the specification.

[joneshf]

I didn't realize this sentence existed in the spec. That makes most of what I said in #132 questionable.

[rpominov]

While we are at it, maybe we should add something like:

If a method can be derived and the type also has a hand written version of that method, derived and hand written methods must be equivalent. And if two derived version of a method can be created (for instance we can derive map using ap or chain), they must be equivalent.

To clarify that matter once and for all.

See Gitter discussion: https://gitter.im/fantasyland/fantasy-land?at=570a28a4c65c9a6f7f284c1c

[rpominov]

I'm not sure how toArray and traverse fit into the specification.

I also don't quite understand why they are here. I think toArray is necessary to define reduce, it restraints how it can be implemented. But traverse seems completely unnecessary.

[davidchambers]

I think toArray is necessary to define reduce, it restraints how it can be implemented.

That may be the case, but the wording can surely be improved. Currently we state:

1. u.reduce is equivalent to u.toArray().reduce

• toArray; derivable as function() { return this.reduce((acc, x) => acc.concat([x]), []); }

Could we remove mention of toArray by inlining?

1. u.reduce is equivalent to u.reduce((acc, x) => acc.concat([x]), []).reduce

[DrBoolean]

I like that toArray illustrates the power of foldable in a nutshell and gives a law associated with the algebra. I agree that traverse is unnecessary. Perhaps if traversable is rewritten in terms of traverse, it will justify deriving sequence for legacy reasons.

[davidchambers]

I added this sentence based on your suggestion, @rpominov.

[rpominov]

Great!

[davidchambers]

The :+1: in #132 (comment) indicates that @puffnfresh is in favour of this change, so let's merge it. :)

I've reverted the removal of toArray based on feedback from @rpominov and @DrBoolean.

[rpominov]

We should also move reduce derivation that was added after this PR was opened.

[rpominov]

I've reverted the removal of toArray based on feedback from @rpominov and @DrBoolean.

I like your idea of replacing it with a law:

1. u.reduce is equivalent to u.reduce((acc, x) => acc.concat([x]), []).reduce

[davidchambers]

Thank you for the feedback, @rpominov. I've made the following changes:

• removed mention of toArray by inlining;
• moved the reduce derivation to the Derivations section; and
• added syntax highlighting to derivations.

[Avaq]

I prefer this version of the spec over the current. 👍

[puffnfresh]

👍

[davidchambers]

Thanks, @puffnfresh! Can we merge this now? @SimonRichardson?

[SimonRichardson]

Sure, do it

On Wed, 15 Jun 2016, 01:34 David Chambers, notifications@github.com wrote:

Thanks, @puffnfresh https://github.com/puffnfresh! Can we merge this
now? @SimonRichardson https://github.com/SimonRichardson?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#134 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACcaGDe1_p1_iJ-WMaxVehe170-ZfrDCks5qL0iJgaJpZM4IFkwJ
.

[davidchambers]

I'm hoping someone with write access will hit the merge button. ;)

[SimonRichardson]

Haha, done!