Fix id_test and argument order in laws

[safareli]

related to #173 #171

[davidchambers]

Could you change the path to './'? '.' has always worked for me, but I've seen it fail for other people.

[davidchambers]

It's pretty clear no one is using these at the moment. ;)

[safareli]

i'm using it but just updated from v1 to v2 :p

[rpominov]

I wonder if maybe these should live in a separate project. Here are couple benefits:

• No extra deps Move unnecessary normal dependencies to devDependencies #168
• The version number of fantasy-land package will only track changes in the spec itself.

[davidchambers]

The version number of fantasy-land package will only track changes in the spec itself.

I find this compelling. It'd be a shame to keep incrementing the spec's version in order to release fixes such as these, but it'd be unreasonable to force such fixes to wait until a new version of the spec is released. Allowing the two projects to be released independently strikes me as a good idea.

[safareli]

I think changes like this should bump patch version for now.

[davidchambers]

🌳

[SimonRichardson]

I still think the laws should be in this repo, but I think they should be dramatically improved (or reworked, refactored, re-written). They're very old, but are worth their gold when they did work. Personally we should go one step further and make them links in the spec, so people are more likely to know about them.

[rpominov]

I think laws should look like this:

// `u.map(a => a)` is equivalent to `u` (identity)
const identity = (u) => {
  return {
    left: u[map](x => x),
    right: u,
  }
}

// `u.map(x => f(g(x)))` is equivalent to `u.map(g).map(f)` (composition)
const composition = (u, f, g) => {
  return {
    left: u[map](x => f(g(x))),
    right: u[map](g)[map](f),
  }
}

When we're trying to make them smarter, they just end up incomplete or hard to use with certain types.

Also this simple laws implementations will be easy to keep up to date because it's basically copy-paste of the snippets from spec.

I can make a PR that simplifies laws like this if this sounds like a good idea.

[safareli]

const identity = (u) => {
  return {
    left: u[map](x => x),
    right: u,
  }
}
{left,right} = identity(Maybe.Just(1))
maybeEquals(left,right)

i don't see a big difference with this

const identity = (eq, u) => eq(u[map](x => x), u)
identity(maybeEquals, Maybe.Just(1))

and imo the last one is better, instead of getting some object and extracting left, right parts you give a function and get the result (and also the eq function you pass does not have to return bool you can return promise for example it's up to user, so this is not "limiting" us)

[rpominov]

This refactoring will be a breaking change strictly speaking though.

[safareli]

yeh :/ that's true.

What if we state in readme that we might have some braking changes in laws, but still do patch releases if there is no change in actual spec.

[rjmk]

Automated tools don't read READMEs. I think we need to stick to incrementing the major version for a breaking change

[rpominov]

Let's move this discussion to #195

[safareli]

despite the #195 can we merge this PR?