Monoidal instead of Applicative

[adamkuipers]

The http://github.com/non/cats project has been exploring favoring the just as powerful (Monoidal)[https://wiki.haskell.org/Typeclassopedia#Alternative_formulation] typeclass over Applicative.

Applicative can be cumbersome in languages that don't default to partial function application and I also think it has a more intuitive definition than Applicative since it's symmetrical as well as having much nicer laws (naturality, left and right identity, and associativity).

You can also get apply builders almost for free since map2, map3, map4 just become map on tuple2, tuple3, tuple4.

[CodaFi]

This is awesome and I would love to see it happen, but alongside our current Applicative. Swift does not support tuple extensions, so any generality we could extract would have to be by writing 7 billion overloads again. Basically, until Tuple stops being an amorphous compiler hack I don't think this would work in quite the way you'd expect

[adamkuipers]

Yeah, there would probably have to be a ProductN boilerplate type like Zip2Sequence.

What I like about the ProductN route, though, is that it would only have to be used internally and would be transparent to the client. No longer will the client be required to define a curried initializer create.

Instead of Foo.create <^> fa <*> fb <*> fc we would have map(fa, fb, fc) { Foo($0, $1, $2) }, which looks more natural in Swift land IMO.

[CodaFi]

So, how much boilerplate is enough boilerplate then?

[CodaFi]

Which is to say: I definitely agree that that looks more natural, but am I gonna have to maintain 15 more structs in the near future?

[adamkuipers]

Scala seemed to have made the decision for everyone that Tuple22 was enough 😃

[CodaFi]

Then to 22 we shall go! Would you like to draw up a pull request, or shall I?

[adamkuipers]

I might have time tonight to get something going. Would you want Applicative to be defined in terms of Monoidal, vice versa, or independent of one another?

[CodaFi]

Do whatever is most natural (which probably means separate at first). We'll worry about the nitty-gritty in code review.

[DanielAsher]

I've got TupleOf to TupleOf5 if that helps. Couldn't give up on shrinking in SwiftCheck...

[adamkuipers]

Unrelated, but have you considered opening a gitter channel for this project? I think I remember a talk where @non mentioned that it contributed Cats growing community but maybe I made that part up.

[DanielAsher]

I promoted the creation of a slack channel - typelift.slack.com - but it's pretty lonely there at the mo. Will look into gitter.

[adamkuipers]

What's nice about gitter is that it's discoverable. And you don't need a slack account.

[DanielAsher]

right. slack is cumbersome for unpaid use. discoverability is precious too.

[pthariensflame]

Having read through this thread, I've just created https://gitter.im/typelift and invited @CodaFi. Anyone else want in?

[DanielAsher]

I'd love to give gitter a go.

[adamkuipers]

Is it not going to be a public channel?

[pthariensflame]

I guess we can make it public, but I don't know how to do that!

[adamkuipers]

Isn't it just "Create Room" -> Repository -> Swiftz?

[pthariensflame]

Maybe? I'm on mobile right now, so it'll have to wait for a few hours.

[pthariensflame]

Okay, https://gitter.im/typelift/general has just been created, and it's public!

[DanielAsher]

Hurrah!
On Tue, 27 Oct 2015 at 00:46, Alexander Altman notifications@github.com
wrote:

Okay, https://gitter.im/typelift/general has just been created, and it's
public!

—
Reply to this email directly or view it on GitHub
#260 (comment).

[joamaki]

Btw, regarding the need for the boilerplate curried constructor, in Swift 2 this now works:

struct Foo { let a: Int, let b: String }
curry(Foo.init) <^> 1 <*> "hello"

Of course you'll end up hitting the "expression too complex" pretty quickly...

[CodaFi]

Whatever happened to this proposal? Should I draw up the pull request for this myself?