New library/spec similair to Fantasy Land

Hello all 😄

I’d like to share a library/specification that I’ve been working on. It’s called Jabz and is highly inspired by Fantasy Land—but with a number of differences that I think are beneficial.

Some of the differences are:

• Foldable supports a short-circuiting fold that gives the same benefits as Haskell’s lazy foldr. This means that a number of functions for foldable can be made more performant. It also means that infinite data structures can meaningfully implement foldable.
• I’ve made lift part of the Applicative spec which gives a very substantial performance improvement. Similar to the idea in #56.
• I’ve tweaked the monad spec so that do-notation as is Fantasy Do can be implemented without exposing the nasty “multi mode”.
• Some derived methods are part of the spec so that implementations can bring their own implementations. In some cases these can have much better performance.

I’ve written more about these ideas in a blog post here. The library can be found here.

I’d love to hear what you all think about it.

[paldepind]

@safareli

Why not create Issues/PRs to fix problems discussed in your article, instead of creating new spec?

Well, this started out as an experiment. It was a lot easier for me to just go ahead, experiment and implement all of my ideas rather than try to get Fantasy Land to adopt each of them one by one. You can consider the entire library as a proof of concept for proposals to Fantasy Land. That is also why I posted it here.

But do notice that a major incompatibility is that Jabz doesn’t use prefixed method names. I’m not sure if Fantasy Land is willing to backtrack on that decision.

Regarding the xkcd. I didn’t create Jabz to “develop one universal standard that covers everyone’s use cases”. I created it to get something that is suitable for my own use case.

[paldepind]

@kwijibo

Thank you for the feedback.

Weren’t you in favor of prefixed method names in fantasyland @paldepind?

Yes. Back then I was. Part of the reason was from my experience with creating the library Flyd. I didn’t want Flyd to have an object oriented API but to support FL I had to partly add one. And then users started using the methods directly—which I didn’t like. I thought that if the methods were prefixed users would realize that they were “internal” and not for end-user consumption.

Today I think that my opinion back then came from an irrational distaste for methods. But Fantasy Land relies fundamentally on methods. And when you have to add methods anyway why not do so in a way that is easy to use instead of cumbersome to use?

It is my impression that @SimonRichardson still prefers non-prefixed methods?

Maybe the issue should be rediscussed?