Unified specification

[rpominov]

This proposal unifies Fantasy Land and Static Land. The unified specification is based on modules (simple objects with functions that don't use this) as opposed to putting methods directly to values. Although values still have a single property, reference to a module, which makes the unified specification equivalent in flexibility to Fantasy Land.

I see following advantages of this approach:

1. We need only one property that is subject to name clashes.
2. Sometimes it's impossible to add even a single property to values, but we still can implement a compliant module, which we'll have to pass explicitly everywhere though.
3. Also, we may implement multiple modules for a single type. Although again only one can be referenced from values, and another we'll have to pass explicitly.
4. Since every implementation will have modules, it allows for a whole different programming style where we choose to always pass modules explicitly even though they can be referenced from values. This may have some advantages, for example, types are more explicit in code.

Also, this approach should be easier to works with when we want to use static type systems like TypeScript or Flow. To be honest, I don't know much about this area. But other people did a lot of research. @gcanti works on https://github.com/gcanti/fp-ts and https://github.com/gcanti/flow-static-land . @alexandru works on https://github.com/funfix/funfix and argued that static functions are much easier to work with than method here fantasyland/static-land#45 (comment) . To my shame, I still haven't looked into these projects. But I hope @gcanti and @alexandru can participate in the discussion here.

Previous discussions about this unification approach can be found here: #199 fantasyland/static-land#45

I also want to say a big thank you to @briancavalier who came up with the idea of unification!

This PR comes with a huge diff and comments may become hard to follow if we discuss every single change here. I think it'll be better if we only discuss here whether we want this or not in general, and for particular changes create issues or PRs in the fork https://github.com/rpominov/fantasy-land .

[paldepind]

I'm a big fan of this 👍 Really great work @rpominov.

One additional benefit of this, that I haven't seen mentioned elsewhere, is that implementing the modules (without the method) is fully compatible with tree-shaking.

Here's a question: Since there will only ever be one canonical method can we name the method simply canonical or fantasy-land? To me fantasy-land/canonical feels a bit weird. The prefix with a slash seemed to make more sense when there were many prefixed methods.

[rpominov]

Thanks for the support @paldepind !

I don't have a strong opinion about the property name. You can open issue or PR on the fork and we'll see what other people think.

[briancavalier]

🎉 Thank you, @rpominov and everyone involved, for this amazing work! I think this is a big win for the community ... and somewhat selfishly, as a maintainer of FL and SL compliant libs, I'm also very looking forward to supporting a single unified spec.

[alexandru]

Hi all, hi @rpominov,

I'm very happy to see this.

In addition to Funfix, I also started Funland 🙂 This was extracted from Funfix and represents essentially static types for static-land, the explicit goal being 100% compatibility with it.

When working with a language like TypeScript, providing static-land compatibility first is very natural, because you can describe those type classes with actual types. And having to maintain Fantasy-Land compatibility in addition to static-land is a pain.

[puffnfresh]

Is this method used anywhere anywhere else in JavaScript?

[rpominov]

@puffnfresh You mean the property name that we're reserving?

[puffnfresh]

@rpominov no, I mean defining functions via something like fantasy-land/x. Does this have any prior work elsewhere in JavaScript?

[rpominov]

Ah. I'm not sure, probably not. At least not in a popular project that I know of. But then, there are not so many specifications in JavaScript ecosystem.

The closest thing that comes to mind is Iterable. Where value has a Symbol.iterator property that references a function that returns an object with the next() method. It's not quite the same, but the level of indirection is similar.

Still, I would agree that this approach is not very idiomatic for JavaScript. Usually, interfaces are defined by putting methods directly on prototype — exactly what Fantasy Land does now :)

[alexandru]

Type classes aren't idiomatic JavaScript though. This is new territory.

[paldepind]

I've created a PR rpominov#5 for simplifying the name of the canonical property to just canonical.

[axefrog]

What's the status of this PR?

Added some thoughts to @paldepind's notes in rpominov#5

[Raiondesu]

So, uhm, what's the status of this PR?

Seems like many things pivot around this and rpominov#5. 😅

For example, #177, #315, mostjs/core#239, briancavalier/creed#177, and ReactiveX/rxjs#4674 with ReactiveX/rxjs#34 (as well as many other issues in other different fp projects) seem unresolved due to this PR having no updates (as well as not having #177).

[davidchambers]

I should get back to #315. I believe that proposal will unify the two specifications, @Raiondesu.

[rpominov]

I don’t have plans to work on this, so I will close this PR.

Apologies, if keeping it open all this time with an ambiguous status, might have discouraged other people from working on solutions to some problems that this PR was going to solve.