Fantasy-land: New library/spec similair to Fantasy Land

[paldepind]

Hello all :smile:

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.

[SimonRichardson]

I'm closing this as i don't know what to do with it, feel free for others to discuss though!

[safareli]

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

It sort of reminds me this meme:

[SimonRichardson]

@safareli you read my mind 😐

[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.

[kwijibo]

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.

Weren't you in favour of prefixed method names in fantasyland @paldepind ?

[kwijibo]

I strongly agree with this point from your blog post @paldepind :

Having a map method that does one thing and a fantasy-land/map method that does another thing is a source of confusion. It creates situations where map(f,foo) might do something different than foo.map(f).

And I hope that Fantasy Land would at least be able to reconsider the prefix decision. Looking over the old discussions about it, agreement was reached with the proviso that "We're semver'd. If it turns out bad we can undo it."

It's regrettable that FL is now in the position of saying "In this specification, we use x.map(f) notation, but if, as a user, you want the behaviour of foo.map(f) you must write map(f, foo)"

[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?