move tests to corresponding structures?

[safareli]

After #197 is merged we will have implementations of structures:

• Identity
• Maybe
• Array
• Compose

This might grove after adding more algebras in future.

Possibly solution is to completely remove test from FL, but in this case fantasy-id, fantasy-maybe ... should be always up to date and if we have a PR to add some spec to FL, before we land it, PRs for fantasy-* should be opened, to ensure PR in FL is correct, then PR in FL could be merged and version bumped. After which PRs in fantasy-* could update FL and be merged as well.

Related discussion

[SimonRichardson]

Now that is an awesome idea

[safareli]

If some Foo spec is added to FL with foo method and the method should be implemented in fantasy-* what shell we do? also fantasy-* have there own tests too. How dependencies will solve it?

[rpominov]

Sorry, I've deleted my comment after realizing that it was invalid :)
Anyway I still don't understand completely how this would work even with multiple PRs to multiple repos. We would add unmerged branches as dependencies and such?

Sounds very complicated.

Edit: duplicating implementations of these structures in FL repo sounds like a lesser evil.

[safareli]

For example someone opens PR to adds Foo spec to FL and adds laws/foo.js
once it looks good and is ready to merge, then the author will also open PR for fl-id or fl-maybe and depend on her development branch of the FL PR temporarily, add tests, and after it's passing then PR in FL could be merged and version bumped, after which the PR in fl-id or fl-maybe could be updated to use published version of FL and be merged. (we just need at least Id Maybe to be up to date with correct FL)

Yeah it's sort of complicated but the way we are doing it is not any better.

[SimonRichardson]

I don't. Duplication is an evil in itself. I can't fathom why we constantly have to duplicate libraries containers over and over again. The point of the spec included the libraries around it, they're a standard for the spec and because people have decided to implement their own (and have worse implementations!!!), they're neglected because of this. I went to rectify this...

Fantasyland has standard libraries with the spec and should have been promoted from the start (which I regret not doing!) and we should strive to do this...

[davidchambers]

people have decided to implement their own (and have worse implementations!!!)

Could you elaborate on this point, @SimonRichardson?

[SimonRichardson]

Invalid functors is a very common one, also checking types on maybes which
leads to all sorts of issues.

If I come across some I'll try to take a note so that we can help the
author to understand the mistakes they've made, but not gotten anything to
hand right now unfortunately.

On Sun, 30 Oct 2016, 21:41 David Chambers, notifications@github.com wrote:

people have decided to implement their own (and have worse
implementations!!!)

Could you elaborate on this point, @SimonRichardson
https://github.com/SimonRichardson?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#200 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACcaGN-Zl5g5s3oPbWbi0YAbwdyA3VTbks5q5Q8KgaJpZM4KkfXo
.

[davidchambers]

Invalid functors is a very common one, also checking types on maybes which leads to all sorts of issues.

Ah, yes. I've seen this sort of thing several times. Thanks for the clarification.

[syaiful6]

@SimonRichardson maybe we should provide standard library for basic data structure? Maybe, Either are basic data structure i think. Haskell provide this on Prelude and Purescript community only use one implementation. But on Fantasy Land, many library provides their own implementations, which make difficult to integrate them (hence the need for spec).

Maybe we should introspec, our implementations on Fantasy-Land repo doesn't have good documentation, and even it doesn't transpile it (it will create problem on browser, as we don't have it). Then we can make other library authors to depend our implementations.